I have some concerns about the Marmot protocol / whitenoise.chat @JeffG
> Messages in White Noise are encrypted end-to-end and temporarily relayed through several Nostr servers, which cannot read them and don’t permanently store them. Relays act as transient delivery points, discarding data after transmission.
How can we guarantee that they don’t permanently store them? If they do, this is a clear “Harvest Now, Decrypt Later” attack.
> Users can further prioritize privacy by selecting trusted relays or hosting their own,
Messages are designed to be propagated on Nostr. It’s a gossip protocol. It’s not designed to have access control lists at the foundation. So how does running our own server actually help us?
> ensuring no single entity retains control over their communications.
See, this statement frames the concern as being about “my communication is being blocked”. But the real concern is “my communication is being harvested and decrypted by 3 letter agencies”.
Login to reply
Replies (3)
> If you're in a situation that requires that level of caution
My thinking is basically that the “harvest now, decrypt later” thing is something everyone should be concerned with. Because it requires way less effort than something like an actual directed attack. Normal people should primarily be concerned with this type of attack (if you could even call it an attack).
> then you should run your own relays.
How does running my own relay solve that problem exactly? How would I then ensure that my messages are not being stored by any other relay? Because doesn’t the protocol assume that messages propagate to other relays as well?
> Because doesn’t the protocol assume that messages propagate to other relays as well?
There's at least a mention of NIP-70 (protected events) in the MIP-00. Perhaps NIP-70 could be a requirement for all Marmot events?
I also find it scary that Marmot allows usage of relays that don't require NIP-42 auth.
Almost all events should be private IMO; the auth should be required whenever possible.
> or controlling the whole stack (incl relays).
> How does running my own relay solve that problem exactly? How would I then ensure that my messages are not being stored by any other relay?
If you're using NIP-42 auth whenever possible, control your client and relay (you're sure the relay and your client won't propagate events to unexpected relays, and the client will actually remove the events)—only your DM buddy with their unexpected relay list or broken client would be able to propagate the events to unexpected relays.
The broken client is not something controllable in the FOSS world. An immutable list of relays that all sides of communication explicitly chose to use for the conversation still could be possible. But at some point these relays will be outdated for example, so a new conversation would need to be created. Feels like a wrong complication. Any better ideas?