You were the one calling it "gaslighting". Gaslighting is gaslighting, regardless of the stack.
I don't know exactly what you want solved since many of the things you cited in this thread are indeed solvable by the simple solutions I cited. I not only looked at them, but I actually coded and tested some of them. And they do it just fine. They just add more complexity for minimum gains, IMO.
Which solution specifically?
The "remember to hit reply" solution doesn't work, clearly.
The "hidden reply to last-seen message at time of compose" does not either.
Your bloom filter one, if you’re saying every new message can include tags for every ID of every message the client/user has received, in the whole history of that group (or to some length back), and bloom filters on top, not sure where to start (also not sure that's what you're suggesting).
What are the other simple solutions?
Again, I don't really know what you are actually trying to solve. If the goal is to just highlight to users that a person is the group is fucking them over in the last messages, all you need is a quick check on the last messages. You can add the e tags for as many messages are need to fix for the time wanted. Or you can do bloom filters. There are new kinds that were proposed to mark as seen each message, like a NIP25 reaction would be. There are other proposals that "summarize" things because really only the current messages matter. There are proposals that build a full chain of event IDs from the beginning to end of the chat. There were summary events discussed in the past. There were even MuSig and even ring signature authentications for everyone in the group. There are dozens of options for the things you mentioned. All of them have pros and cons. The more complex ones solve the most amount of issues related to this that you didn't even mentioned, but they all come at a cost of complexity.
Trying to solve is this:
Reduce the chance that normies, thinking this works like Signal, WhatsApp, everything else they've ever used, get scammed here. By way of a gaslighting attack that is unique to NIP17 groups, and, if undertaken with skill, could be very effective. Assuming there comes a time when normies start to use this, which I'm hoping there will.
This kind of gaslighting risk in closed-group ultra-private messengers is not normal, you have to admit that. Name me any other messenger in the category of ultra-private messaging that carries this risk? I'm open to the fact that one might exist out there, and if so curious what the UX is for this, but I haven't found any.
For solutions, what I'm saying is the only solutions you're touching on that actually have wheels are really complex. It's a solved problem and all existing solutions are really complex too, so that only stands to reason. There are no simple fixes that don't end up as security theatre in some way.
Can you define what you mean by gaslighting? Gaslighting can be a lot of stuff (the word is VERY broad) and it does happen in signal and what's app too. So, if you want to keep debating this, you will need to define it better. Just "protecting normies from scammers" won't work because scammers don't need this flaw to scam people. Even if you fix it, they will still get scammed. You need to define what exactly you want solved.
I think you are just dismissing actual solutions because they are not perfect. Nothing will ever be perfect. They can only help solve the things that were more appropriately specified. If they are specified then we can measure how well each solution works to solve it for the cost of implementing and pick the best one.
Sure happy to define it.
- Person A, Person B and Person C are all “up to date” (seeing the same most recent message).
- The history of Person A can contain one or more messages that are not in the history of Person B *in any form*, not a deleted-message tombstone, nothing, no trace whatsoever. And the reverse. And the same for Person A-C, B-C.
- Additionally the history of Person A can be missing messages that appear in the history of Person B, again with no tombstone, no trace, no indication whatsoever that something is missing.
-These "He sees it, she doesn't" messages can be sent simultaneously, so at the same time (and with a malicious client) Person D can send a separate message to Person A, a separate message to Person B, and a separate message to Person C. (or send to all but A at the same time).
Also I'd add that any detection method cannot result in a false positive and is therefore explicitly trusted.
The above combination of factors enables a level of social engineering that you can't really compare with what an attacker could achieve on Signal, WhatsApp, Telegram, etc. Yes of course people will get scammed anyway. Scammers love Telegram, and Telegram's serer ensures the above can't happen. What I'm arguing is that after getting scammed on Telegram it's fair to say (if cruel) that they have themselves to blame. For this case, if you game theory it out, I don't think we can say that they do fully have themselves to blame. It's a very unique attack vector.
