Skip to content
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

Invite links for groupActivityOf sessions #1411

Open
cdsmith opened this issue Aug 7, 2020 · 2 comments
Open

Invite links for groupActivityOf sessions #1411

cdsmith opened this issue Aug 7, 2020 · 2 comments

Comments

@cdsmith
Copy link
Collaborator

cdsmith commented Aug 7, 2020

Came up in discussion with @jbash in #1409

Currently, getting a multi-user session going with groupActivityOf is a two-step process:

  1. Get everyone running the same code (identified by a hash or dhash).
  2. Someone creates a session, and everyone else joins the session using the four-letter code.

This is more complex than it needs to be. Instead, what could happen is:

  1. ONE player runs the program and creates a new session.
  2. They get an invite link, which they send to everyone else, who uses it to run the same program AND automatically join the session.

Basically, the invite link should have both the program hash/dhash and the session code embedded into it.

@cdsmith
Copy link
Collaborator Author

cdsmith commented Aug 7, 2020

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.

@cdsmith cdsmith closed this as completed Aug 10, 2020
@cdsmith cdsmith reopened this Aug 10, 2020
@cdsmith
Copy link
Collaborator Author

cdsmith commented Aug 10, 2020

Implementation notes:

  1. Accepting invite links can be implemented entirely in Haskell.
  2. 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant