With the current implementation you get out of the box: you don’t. It’s all working on MyBinder, but everybody’s anonymous, and you have to trust everybody (and the MyBinder federation), but an in-house Binder is probably going to Just Work today, if you’ve already figured out the other abstractions.
As mentioned over here, some classes of solutions to connecting the UI of n spawned servers:
- a matched pair of…
- a Hub service that implements/wraps “the other end” of…
- a
labextensionthatprovidesIDocumentProviderFactory pointing at something other than/lab/api/yjsinstalled in every spawned server
- a matched pair of…
- some backing store which can store the stuff, and can be found/connected to/authenticated by the environment variables/request headers available to…
- a
serverextensionthat replaces the as-shipped YjsEchoWebSocket on/lab/api/yjsinstalled in every spawned server
While the latter option is attractive as it might not require any custom JS/TS/WebPack, the user experience might be rather lacking from what people would expect.
My gut feel is doing this without also offering out-of-document, searchable, in-Lab chat is probably not going to feel very good… as mentioned over there, being able to back yjs with an embeddable XMPP web client and known-good XMPP server (e.g. the MMORPG/telecon-grade ejabberd… your NIC will give up before it does) would be a very strong play. Oh, and look, if done right, you’d get self-hosted video chat, too, with jupyterlab-videochat (once the rooms there are also extensible, a WIP) given a self-hosted Jitsi, which could then (weirdly) power your own private virtual world.
Even given those, this is not going to magically solve the rest of the problems that sysadmins will have to deal with at scale, e.g. role-based, fine-grained permissions at the folder/document/cell/line, integration with DVCS/CI, logging/auditing, data spill remediation, but having a demonstration of a way this could work is important for getting to those next steps.