cfcosta on Nostr: I've specified something like this before, worked almost full time just thinking ...
I've specified something like this before, worked almost full time just thinking about this problem for 3 months or so. In a short answer: Double Ratchet/X3DH for messaging, zero-knowledge proofs so the server doesn't know the sender or the receiver.
Keep the merkle root of a Merkle Search Tree, derive the next key based on the root of the current chat tree. Tree is self-balancing and automatically ordered to keep causality in check.
Inside each message, keep an encrypted Hybrid Logical Clock id on each message, to keep both causal and wall clock synchrony, even in case of clock drifts.
For each destination (like a group), publish a single entry, and multiple public keys, one for each destination. Add a random number of other public keys to obfuscate which are real and which are not.
When fetching, user sends a proof that, given the sender public key, they have ownership of the proof. Proof is consumed on the relay. User updates their own Merkle Search Tree on the client with each proof they consumed.
User then publishes new proofs for the same content they received, but with their own "backup key". These are kept in the relay for user device backup.
All keys are ephemeral, except the backup key, which can be the user nsec key. User publishes public one-time-use keys (either by publishing to relays or NIP-05).
Basically the chat conversation is a CRDT, and the same relay mechanism that nostr uses guarantees delivery without the need for consistency (which are also not required for crdts).
A little bit stream of counciousness, but I can give detailed explanations about everything I talked about here, and even wrote most of it down, just ping me if you need.
Keep the merkle root of a Merkle Search Tree, derive the next key based on the root of the current chat tree. Tree is self-balancing and automatically ordered to keep causality in check.
Inside each message, keep an encrypted Hybrid Logical Clock id on each message, to keep both causal and wall clock synchrony, even in case of clock drifts.
For each destination (like a group), publish a single entry, and multiple public keys, one for each destination. Add a random number of other public keys to obfuscate which are real and which are not.
When fetching, user sends a proof that, given the sender public key, they have ownership of the proof. Proof is consumed on the relay. User updates their own Merkle Search Tree on the client with each proof they consumed.
User then publishes new proofs for the same content they received, but with their own "backup key". These are kept in the relay for user device backup.
All keys are ephemeral, except the backup key, which can be the user nsec key. User publishes public one-time-use keys (either by publishing to relays or NIP-05).
Basically the chat conversation is a CRDT, and the same relay mechanism that nostr uses guarantees delivery without the need for consistency (which are also not required for crdts).
A little bit stream of counciousness, but I can give detailed explanations about everything I talked about here, and even wrote most of it down, just ping me if you need.