I am using a TLJH for a class and I want to setup some collaborative group exercises. Basically I want groups of 5-6 people to work on a notebook to collaboratively develop solutions to problems in them. We have videochat/zoom/discord for communication during the exercise.
I have the hub set up so it is collaborative by default and I can share with my students by sending them a link with the token in it. It is a side issue that it is tricky to get this token, the usual jupyterlab-link-share package does not work in our tljh as there is no token in the url. I have to get it from an environment variable.
The issue I have is I use my account as an instructor account, so it has solutions and other things the students should not have access to, but with the current sharing, they have access to everything in it.
My current solution is to use another account that is basically empty except for the group work. It doesn’t feel totally right though; the account only exists because we made it before switching to oauth authentication; so I can only access it by logging in to the oauth account now via the admin panel. Anyway, I wondered how others do this, and if there are other solutions for this.
Yeah, this is a real problem with the current collaborative settings.
A semi-weird approach is using an alternate yjs collaboration backend, such as jupyterlab-webrtc-docprovider. This uses a dedicated service (likely could be stood up as a jupyterhub service) that would limit how much access you have to give folk, but could still have pointy edges.
It was built for public demos, so is rather permissive by default, and I wouldn’t recommend just running it without getting a feel for what information it’s leaking to a public server.
I think the best production solution would be getting a y-xmpp-based provider backed by a self-hosted ejabberd client… and probably an in-lab XMPP chat client, to boot. Going further, with a self-hosted jitsi one could also have video and ephemeral chat in-lab with jupyter-videochat.
But even still, there are still a lot of pointy edges on things like identity and permissions.
1 Like
Thanks for the ideas. Seems like it is a ways off from permissions like Colab or Deepnote has. A solution like chroot that would limit access to a specific folder would probably be sufficient, although one might like view/execute permission too. Ideally that would be possible in an existing session, so you don’t have to know in advance when you want to share something. one day maybe…
Right. “Share Everything” is kind of a weird place to be stuck… a provider that offered “Open As Shared…” would make a lot more sense.
But at the end of the day, I don’t really think that specific UI can be a jupyterlab core decision, as it runs aground so squarely on identity, etc. that are entirely dependent on the deployment… the two proprietary vendors mentioned get to tell you how you’re going to use their software with your data and their users, while Lab can’t predict any of those things.
Hub potentially could make some of these claims… but has been so far skittish from integrating much with the JupyterLab UX, which kinda hurts everybody. As mentioned, there is some upcoming work that will unify certain things.