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
So I think the handling of user_ids will still be handled by the server but via separate REST endpoint.
Given instantiating the Websocket is on top of a GET can't really send a payload so don't think we can do it within our jamService.handleP2P handler.
I think instead we should use a separate endpoint to deal with creating and getting users usernames, and then before establishing a connection, make a authorized get request to make sure this user with username is allowed.
Then after the connection is established can send that detail via the messages payload with a sender field.
Yeah, I think that makes sense. Can you link your diagram?
Sidenote: not to say we should go with WS over REST, but we can send messages via websocket after the connection is
established. It wouldn't be through a GET body anyway
Previously, the server generated an ID for each client when they joined a room. This was done by sending back a
CONNECT
message on room join.https://github.com/Rapidmidiex/rmx/pull/28/files#diff-0225d3aae6312632c69937171e2ac0767228028ca0ffac566ec39847ab020ea6R79-R105
The message looked something like this
We've since removed that logic, as it was just a placeholder until we added something more robust.
The text was updated successfully, but these errors were encountered: