You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I don't think we should break the existing flow, though. That is: when you join using an invite URL, it should automatically join the session embedded in the link. But if you run the program without an invite link, you should still get a choice between creating a new session, or manually joining an existing session using the four-letter code.
Accepting invite links can be implemented entirely in Haskell.
Generating invite links is trickier. If it's implemented in the canvas-based UI, then we don't get copy-and-paste, which is a fatal flaw. So it needs to be built with the DOM.
Option 2a: Send a message to the parent using window.postMessage, and let the parent frame (in JavaScript) show the invite link in a popup. The huge disadvantage is that it becomes impossible to show an invite link without a parent frame. One could imagine workarounds, but they aren't nice.
Option 2b: Reimplement the lobby UI in the DOM instead of a canvas. This actually earns us lots of benefits, like better accessibility, easier and more native UI controls if we wanted to add more lobby features in the futures, and so on. One of those benefits is that copy-and-paste of the invite link is possible within the running program.
I think we should go with 2b, even if it's a lot of work.
Came up in discussion with @jbash in #1409
Currently, getting a multi-user session going with
groupActivityOf
is a two-step process:This is more complex than it needs to be. Instead, what could happen is:
Basically, the invite link should have both the program hash/dhash and the session code embedded into it.
The text was updated successfully, but these errors were encountered: