-
Notifications
You must be signed in to change notification settings - Fork 304
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Initial support for real time collaboration #109
Conversation
constructor(options: IDocumentProviderFactory.IOptions) { | ||
super(YJS_WEBSOCKET_URL, options.guid, options.ymodel.ydoc); | ||
super(options.guid, options.ymodel.ydoc); | ||
this.awareness = options.ymodel.awareness; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could also make the signaling server(s) configurable via the settings / overrides.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did this happen? I think we should add this configuration sprocket before merging.
A simple "room" support a la Whereby. So folks can share links that look like the following: https://jupyterlite.readthedocs.io/en/latest/_static/lab/?room=the-coolest-room |
RTC between lab and retro: rtc-retro-lab.mp4 |
6918651
to
77902dc
Compare
As mentioned on #207: it looks like there is some new behavior on the yjs connector that needs to be accounted for.
Not sure which of these we'd be most likely to land first... |
This PR still need a couple of fixes (sync when opening the documents), so probably we can get #207 in first and then rebase here. |
From https://readthedocs.org/projects/jupyterlite/builds/14201215/:
Maybe a sign that we are starting to reach the limits? Will restart the build to double check. |
Also adding some docs about RTC: https://jupyterlite--109.org.readthedocs.build/en/109/rtc/index.html |
Pushed a couple of improvements to fix the issue with duplicated content when a document is opened. Now hitting that one when creating a new notebook that is already opened and edited by a peer (they need to choose Overwrite): But it looks like it's fine when opening a existing example notebook, so maybe something to check in the jupyterlite contents manager. |
Since RTC is opt-in and also requires setting the |
@bollwyvl would you like to give it a try on the RTD demo? https://jupyterlite--109.org.readthedocs.build/en/109/_static/lab/index.html?room=the-coolest-room Thinking we could ship as is if it works ok, and we can address the contents manager issue in follow-up PRs. |
For that we might want to start using |
Yeah, Some band-aids until we really go after #118 (almost started trying to make some part of core federated, but worked on #238, because users can use it)
sounds like another issue... i don't understand fully the ramifications, but localForage is just nice, not criticial, as if a user's browser doesn't have indexeddb, they're likely going to have... other problems with this site. |
docs/rtc/index.md
Outdated
In addition to the `collaborative` flag, end users must specify the `room` query | ||
parameter in the URL. An example of such URL is as follows: | ||
|
||
[https://jupyterlite.readthedocs.io/en/latest/\_static/lab/index.html?room=my-custom-room](https://jupyterlite.readthedocs.io/en/latest/_static/lab/index.html?room=my-custom-room) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i wouldn't even make this a clickable link... and frankly, we shouldn't even suggest a room name, as we basically don't want people going to The One Room because it will get filled up with spam.
A nice approach might be to offer an RTC link generator with an in-page widget... though StringConcatenate
isn't a thing, and wxyz
doesn't work with requirejs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point. We can still show to specify the room
parameter, but it could be something else or just a random string.
A nice approach might be to offer an RTC link generator with an in-page widget
Yes that would make it much more convenient to share a link.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
An in-app one would be clutch, too, but could be a federated extension (let's not make webpack any worse until we make it better).
In this specific instance, I mean a link generator on the docs page, akin to the binder one, where we can hoist all of the bits and bobs.
|
||
- the host, for example `jupyterlite.example.com` or `myserver:5000` | ||
- the name of the room parsed from the query string parameter, for example | ||
`my-custom-room` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if the actual key that gets used in the code on the public server could at least be obfuscated, e.g. by taking the hash of the appName
, appVersion
and the user-provided key. My confidence is very low in any of these things working between different deployments... and see spam.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes there is still the risk of folks "seeing" each other. So having some kind of seed per deployment would greatly reduce the collisions.
It indeed works (between browsers) on RTD, quite magical ✨ I feel like the presence indicator on the cursors Overall (and i've raised this in core, too, somewhere) I feel like we need something that says, Hey buddy, you're broadcasting to everyone with this same room, and there's 800 people listening to your Some ideas (not mutually exclusive):
So, technically I see no issues to merging, but there are a lot of social and perceptual issues that make this complicated. |
In punching it a few different ways, i was able to get to a state where one of the windows (the second launched) couldn't make a new file. After the first started a new file, then the second window could make a new file. |
editing |
Definitely something else for later. |
Nice set of ideas 👍 We can definitely track them in separate issues, and many of these might actually be about reusing existing plugins or extensions made for "normal" RTC.
Right I've also seen these. Not sure how frequent they happen but probably something to do the with the |
let's not, like ever, until the sharing feature upstream isn't entirely opaque to the user. Like, a different IDrive. with lots of indicators of who can see it. And identity. |
Yeah this will also be definitely relevant in lab and hub. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, we can figure other stuff out in follow-ons.
References
#88
To try it out
https://jupyterlite--109.org.readthedocs.build/en/109/_static/lab/index.html?room=the-coolest-room
rtc-rtd.mp4
Code changes
WebrtcProvider
collaborative
totrue
on the demo siteExtra URL parameter to enable RTC? For example-> not needed?rtc=1
to enable, disabled otherwiseUser-facing changes
Add options to enable RTC to end users.
Backwards-incompatible changes