Excalidraw: Persisted rooms

[vjeux]

Right now rooms are purely peer to peer and ephemeral. This was the easiest to implement but in practice it is a bit awkward as the links you send "die" after a while. Most collaboration tools those days live forward.

I believe we can create a better user experience within the current system and constraints.

• Instead of having the client generate a random room key, we ask the server for one. This is going to create an entry in json.excalidraw.com
• When somebody connects to the room, the server will query json.excalidraw.com and send it to the client. In addition of clients broadcasting the current server. We don't care about conflicts due to the version mechanism.
• We make the full sync updates visible to the server. When one happens, the server sends the encrypted payload to the json server. We need to ensure that the room server has a secret key that allows doing mutations to the json server. Note: we need to figure out how to avoid overriding with wrong data.

From the end-user experience, nothing changes except that they're able to go back to the room anytime in the future.
None of the servers see any user data, only encrypted one. The two things that changed are: 1) the room server knows that some messages are full updates. 2) the room server and json server share a way to know about each others for committing updates.

I'd love thoughts on this setup. cc @petehunt @dwelle @lipis

[dwelle]

The mechanism should be the same we'll use for updating existing singleplayer scenes, and thus should be a subset of that problem (can't find a tracking issue for this).

Furthermore, we might want readonly mode (https://github.com/excalidraw/excalidraw/issues/1866) to use the same mechanism as well, to reduce complexity.

We need to ensure that the room server has a secret key that allows doing mutations to the json server.

Don't think we need to make server stateful. If clients possess a private key, they will send it along which the server will use to verify it can update the scene data on json.excalidraw.com.

[vjeux]

I like the public/private key idea for handling this.

[petehunt]

With some small changes we have the room server run reconciliation in a full e2e-encrypted manner. All it will know is how many shapes there are and how many are edited.

1. Split room id into two parts /room/db_id#client_secret.
2. Share id / version / versionNonce with the server as part of an unencrypted envelope wrapping the rest of the fields of the element which are encrypted.
3. Server can run reconciliation and store it permanently.

This will also let us solve backpressure since the server can now mediate the message flow.

I like this solution better because we don't need public/private crypto and we don't need to share a secret with the server. Also, asking the server to generate the secret key for you effectively introduces a back door which I'd like to avoid. What do you think?

I think we should share read-only copies of the drawing by creating a new room with a new key and re-uploading the drawing with a read-only bit set, or perhaps keyed by the SHA hash of the encrypted data.