Collaborative WebRTC disconnects with big enough update

Description

Collaborative WebRTC silently disconnects with too big display data being transferred.

Reproduce

from IPython.display import display
payload = "a" * 1024 * 256
display({"text/html": f"OK<!--{payload}-->"}, raw=True)

y-webrtc logging enabled with

// enable logging for all modules
localStorage.log = 'true'

Expected behavior

WebRTC would not disconnect silently. Either support large payloads or gracefully degrades.

Context

RobotKernel injects execution logs into notebook by displaying HTML links with large inline data URIs. Not beautiful, but has been working too well so far:

https://robotkernel.readthedocs.io/en/latest/_/lab/index.html?path=Example.ipynb&room=demo

/cc @bollwyvl

[bollwyvl]

So over on https://github.com/jupyterlite/jupyterlab-webrtc-docprovider/pull/3, I’ve hit many of the things from #241… probably would be ready to release that fairly soon. As it imports only @jupyterlab (and not @jupyterlite) APIs, and works just fine with main-line lab and retro, I think it wouldn’t even have to be marked beta.

Once that happens, I feel like replacing the existing provider in lite core with the nullprovider, and removing the y-webrtc dependency altogether is our best play: at worst, the few pages the reference it could say, _please ensure jupyterlite_webrtc_docprovider is installed, but otherwise wouldn’t have to change.

We could add a jupyterlite[webrtc] extra that also grabbed it, but it could just as easily be ignore-sys-prefix which might not be the intended behavior… I suppose we could add an entry_point that extended the jupyter lite build, but that seems unsatisifying.

Anyhow, what I haven’t explored yet is a simple, self-hosted signaling server to recommend, e.g. as a jupyterhub service: relying on unmirrorable, public/free services at runtime is always shady, I think it would be a good solution for many use cases, already, over a user sharing the jupyter_server instance 😱 .

[bollwyvl]

To sum up the progress on demonstrating this over on #600:

• this works,
• windows is weird
• we should try to hoist the whole thing to a separate package, e.g. jupyterlab-webrtc-docprovider.
  • stock lite would not provide any yjs-related features (even behind a flag)
  • we can start it in this org, but then should consider moving it to jupyterlab-contrib: it would presumably work with stock JupyterLab, and an off-the-shelf singaling server could be hosted as a JupyterHub service, which sounds more robust than sharing jupyter servers.