An example of a protocol (and not client) concern is that if someone has your nsec you generally have no way of knowing. I could have your nsec right now, I could be reading your DMs (unless MLS), and I could continue to do for the next months or years, you'd have no real way of knowing I'm doing this unless I slip up and publish something with your nsec and you see that (which, if I was using a special client, would be unlikely) or some elaborate relay sting.
This sucks because the moment you suspect your nsec mave have been exposed, even if just a small chance, you then have to assume it has been and start on a new one, since there's no way to check the history as you can do with other platforms.
The more Nostr moves to Web of Trust the more it benefits the attacker (the knower of the exposed nsec) to just wait and let you build trust on your compromised account, over months or years, because that trust will be useful to cash out as some point in future.
Login to reply
Replies (1)
You do have a way of knowing: if your DMs are going to a semi-trusted relay and you have to AUTH to it in order to read them (as you should under NIP-17) that relay may inform you about who has read them, when and from what IP address.
If we implement
that will also kill the attacker ability's to read anything in the first place unless he wants to reveal himself by registering his bogus device or publishing new encryption keys.
GitHub
nip4e: decoupling encryption from identity by fiatjaf · Pull Request #1647 · nostr-protocol/nips
this is inspired by MLS, but much simpler, and definitely not trying to be a group communication system, but only a way for users to encrypt things...