Ah 😅, gotcha. MLS indeed sounds like the best way to go, though I wonder how good it will work out with nostr relays 🤔. From what I know about the protocol, it highly depends on the ability to delete the key content on the transport service, which usually isn't guaranteed with nostr relays 🙈. I think it's best to use it with self-hosted relays that you know 100% will delete the notes. Thing is, this again largely negates nostr's decentralization qualities 🫠. Also afaik the other tradeoff about MLS is that users who join the chat late, will not see old chat messages, which not always is desired.
My app has a very specific use case (shareable, short-lived chat rooms for quickly finding answers/solutions in your social graph, including for questions that are big-brother incompatible). So my summarized approach is:
- Have multi-tenant dbs on the server, per chatroom. Delete the chat room db including all messages after the chat room expires (7 or 30 days).
- Create an openpgp key-pair on the client, save the public key and 50% of the secret on the server, save the private key and 50% of the secret in the chat room url after the hash/anchor. Create a qrcode of that url that can be shared with trusted friends.
- Have an optional extra secret that is neither stored on the server nor url. This optional secret has to be shared with friends on a separate channel for extra security.
- All chat room messages are encrypted client side and stored on the chatroom db.
- Ideally the server should be behind TLS with perfect forward secrecy enabled.
- Users who join can send messages anonymized or signed with their nostr key. The note is encrypted and the server never sees the plain content.
Users who join the chat room also have the option to send private messages to the chat room creator, encrypted with a separate public key, only readable by the chat room creator.
I am also playing with the thought to have an MLS option on chat room creation - basically the feature choice between MLS and message history.
