It is certainly a benefit that the server only ever sees encrypted data. I have also worked on E2EE for multi-device shared spaces, and the trickiest bugs weren't in the encryption itself, but in edge cases related to key distribution. I have two questions regarding this:

1. When a new client joins but fails to retrieve the workspace key (due to temporary network issues or a 404 error from the server, for example), does it ever generate a new key locally? We encountered exactly this scenario: a device "helpfully" created its own key and encrypted data with it, rendering the message unreadable to other members (without any error notification). We ended up changing the server behavior so that instead of returning a "key missing" response, it signals that the key exists and the client should wait for it.

2. How do you handle key revocation? If you invite someone and later remove them, do you rotate (update) the workspace key and re-wrap it for the remaining members, or does the old key still allow access to past content?

Great questions!

1a. a joining client never generates or fetches a key, so there is no "failed to fetch" error path. The client needs a key to join, and it's wrapped as part of the invite. Keys are never generated server side, and only the workspace creator can create one for that workspace.

1b - All read and write attempts are fingerprinted against the encryption key, and if they don't match, the request is rejected. So it's not possible for an agent with a mismatched key to overwrite or change data.

2. A workspace owner can revoke a key and generate a new one in the browser dashboard (may add a terminal version of this soon). The contents of the workspace will be decrypted client-side with the old key, then re-encrypted with the new one. None of this ever hits the servers.

If a key is revoked, users with the old key won't be able to read from or write to the space anymore (but they will, of course, still have locally any content they had previously fetched). In other words, there is one shared encryption key per workspace. If the workspace owner wants other users to continue using the same space, they'll need to share the new encryption key / invite, and the other users will need to re-add the space to their agent.

I am currently looking at per-user key wrapping and revocation. Let me know if this is a feature you're looking for!

Hope this helps clear things up. If you have any more feedback or questions, please let me know!