Thread
Login to reply
Replies (1)
I don't think it's practical to be honest. This is a flat messaging space, that's more email logic. It would only catch out an attack if (a) everyone who makes mission-critical replies goes through the UI motions to actually select the message they're replying to and choose "reply", and (b) if the thing being replied to is split across multiple messages and amongst those are dirty and clean messages then people don't reply to a clean message, and (c) the fact that false positives are appearing all the time doesn't just cause everyone to turn these gap warnings off. And other things.
And then you have variant attacks which involve purposely not sending messages to certain people, and these attacks can't be caught out like that (selective omission attacks), there is no gap to detect.
The main thing though is that this is not a case of general protocol inconsistency. This is a case of deliberate and potentially high-cost attacks, depending on the chat context. It's based on legitimate user expectations in 2025.
With WhatsApp, Signal, Telegram, Slack, etc., the guarantee is that anyone else that has ‘loaded’ to the same point in the conversation as you will see the same history as you. If they are not at that point yet (have been offline, etc.) when they get there they’ll see the same history. This is deeply ingrained.
With NIP17 groups, it’s entirely possible that a group of x people all loaded up to the same point (all seeing the same most recent message) each have very different (and in these cases *purposefully* different) histories as a result of this.
In Kind 1, a missing parent is an annoyance. But we're not talking missing parent annoyances here, we're talking con jobs. You could in theory pull of a con like this in Kind1, but given the full transparency of kind1 it'd be orders of magnitude harder, if possible at all. In Kind 1, the source of truth is the relay's public feed. In NIP-17, it's a collection of individual envelopes addressed to specific people and with no exposed metadata beyond the recipient pubkey.
So yeah, it's the deliberate attack risk vs. general protocol inconsistency risk.
I just don't think NIP17 groups are feasible in 2025 outside of small clusters of trusted friends with developer backgrounds. NIP17 one-to-one is fine though, it fills a genuine gap and is elegant in its way.