Thread

Issues with potential mitigations that don’t expose metadata on the relays. [Forcing every new message to be a reply to an older message and then hashing the in-reply-to message and putting the hash in the rumor, then having the client display some warning like “this person may be responding to a message you haven't received” if the message corresponding to the in-reply hash is not known to the client.] Doesn’t work because it’s a flat space. You cannot force every new message to be a reply to an older message. If people want to explicitly reply to an older message they can, if not then not. (Mostly they won’t.) Also a malicious actor can selectively omit the "parent" message for one specific user. [As above, but hash of the last-seen message for that sender instead.] You’ll be drowning in false positives. People talk over each other all the time. And then there’s latency issues, drafts composed offline, etc., messages will arrive to clients out of order constantly. Security warnings are useless if there are 1,000 false positives for every genuine case of detection. Not only that but the context injection attack still works, the attacker just needs to have one “clean” message before the elicited response. So they drop a clean emoji right after the dirty message and done. (And then it’s even more dangerous as the lack of a warning gives an explicitly false sense of security.) [As above, but a previous-hashes array going back quite far, so vector-clock ish] Many of the same (or similar) issues as above and now every event has a map of the conversation history. Also, you're well on the way to Marmot here. TLDR, keep it in the rumor, relays stays blind, good for privacy, but relays cannot enforce the order and so the attacker is always free to lie to different people simultaneously. As for potential mitigations that do expose metadata on the relays, not sure those are worth exploring, given that the slightest toe-hold always leads to the next toe hold.