RTC sync for workspace / layouts

[jasonm]

Problem

When multiple users collaborate via RTC, the workspace layout is not shared.

For example, when one user makes a change to the workspace like adding a split or a tab, then other users who are looking at the same workspace currently do not see those changes.

I think it would be useful if it were possible to synchronize the workspace layouts that each user sees. It probably should be opt-in or configurable, since it's also probably useful to have independent workspaces.

Would others find this valuable? Is there intent/interest in working on this? Would maintainers be open to contribution along these lines? How tractable might this be for a new contributor to tackle?

It's probably easy to imagine :) but here's a brief example video of the layouts being independent, not synchronized, with two users connecting to the same JupyterLab instance in two browsers:

https://www.loom.com/share/625578e60fed4ec9ac163b93466b4ee2

Proposed Solution

From a high level, we could use Y.js to synchronize some layout data structure. I don't know enough about the details of JupyterLab RTC and that workspace/layout data structure to propose in much detail.

Here are my notes from a brief code dive for areas that might be relevant. My general guiding question here: Is there a data structure in JupyterLab that represents a workspace/layout and could be "wired up" to Yjs for realtime synchronization? I think that things aren't currently written in such a way to easily add that — that is, workspace/layout data isn't structured as a reactive/observable and instead there are some imperative load/change/save lifecycle methods. In that case, how might we design a binding between some Yjs replicated data structure and these lifecycle methods?

LayoutRestorer may be the highest-level entrypoint into layout/workspace loading and saving. There are also saveLayout and restoreLayout methods on LabShell but it's not immediately clear how these methods are related to the LayoutRestorer calls.

In any case, per comments in LayoutRestorer, it seems like restoring a whole layout is quite a delicate operation. Perhaps Lumino's DockLayout methods saveLayout and restoreLayout are more narrowly scoped and would be a better target for synchronizing? I think I'm using terminology pretty imprecisely here, and perhaps there are several concepts of "layout save/restore" in JupyterLab with subtle-but-important differences.

Additional context

Presumably this would involve introducing some new shared models:

https://github.com/jupyterlab/jupyterlab/tree/master/packages/shared-models/src

[welcome[bot]]

Thank you for opening your first issue in this project! Engagement like this is essential for open source projects! :hugs:
If you haven't done so already, check out Jupyter's Code of Conduct. Also, please try to follow the issue template as it helps other other community members to contribute more effectively. You can meet the other Jovyans by joining our Discourse forum. There is also an intro thread there where you can stop by and say Hi! :wave:
Welcome to the Jupyter community! :tada:

[jasonm]

Also possibly related, other mechanisms for managing workspace data via a GUI https://github.com/jupyterlab/jupyterlab/pull/7913

[meeseeksmachine]

This issue has been mentioned on Jupyter Community Forum. There might be relevant details there:

https://discourse.jupyter.org/t/rtc-sync-for-workspace-layouts/12378/1

[echarles]

Thx for opening this discussion @jasonm.

For now, the RTC sync is thighed to modelling and syncing changes of the notebook (specified by nbformat) with that shared-models API (with the

The shared-models API could for sure be extended to handle structures other than the pure nbformat, for example the layout. A side question will be "do we want to persist in some way the layout and where?".

Other mechanisms/protocols could be discussed as vehicule to the workspace (and other) case, like e.g. GraphQL subscriptions as highlighted recently in this discussion https://github.com/jupyter-server/jupyter_server/issues/653#issuecomment-1006329004

Multiple sync systems have some trade-off, but different case may deserve different options.