There is a proposal by @hodlbod to simplify NIP-17 in exchange for less metadata privacy and safety for all users.
These are real gains by have real tradeoffs, so we need your help.
Today, NIP-17 is so private that the spec does not allow clients to download only a specific chat room. If you are talking to me in a DM, your client is downloading all the other chats you received just to discard most of it to display our chat.
Because of that privacy by design feature, relays also cannot filter messages: there is no way for them to only accept your friend's DMs because they don't know. They cannot know. There is no way for relays to filter spam. In NIP-17, that's the work of the receiving client. The relay is absolutely powerless on purpose.
The new proposal creates a public code for each 2 people messaging each other so clients can filter events by that code, simplifying and saving bandwidth.
The issue is that this code is also visible to all other users and relays, who can now track a chatroom you participate on. Today, they already know one side of the conversation — your pubkey is visible. They know you are receiving. With this change, they can also cluster all messages from the same unknown sender into a single timeline, without decrypting anything.
This means that they can also filter spam, but also means they can censor you by blocking messages from given senders they do not like.
So, less privacy and less censorship resistance in exchange for easier time for devs + less bandwidth used + gains in spam control.
On top of that, the new code works in such a way that the sender can now delete their messages to you and recreate them in the past or future.
In the original NIP-17, once the sender sends you a message, the message is yours. They cannot delete it anymore. If your friend's key leaks in NIP-17, the attacker cannot change the history of DMs. But with this new change, they can. They can delete and rewrite the past.
So, less historical safety in exchange for easier time for devs + less bandwidth used + spam control by relays.
What do you think about this trade-off? Acceptable? not acceptable? Was I clear? It's hard to simplify these things... But we try:
https://github.com/nostr-protocol/nips/pull/2396
These are real gains by have real tradeoffs, so we need your help.
Today, NIP-17 is so private that the spec does not allow clients to download only a specific chat room. If you are talking to me in a DM, your client is downloading all the other chats you received just to discard most of it to display our chat.
Because of that privacy by design feature, relays also cannot filter messages: there is no way for them to only accept your friend's DMs because they don't know. They cannot know. There is no way for relays to filter spam. In NIP-17, that's the work of the receiving client. The relay is absolutely powerless on purpose.
The new proposal creates a public code for each 2 people messaging each other so clients can filter events by that code, simplifying and saving bandwidth.
The issue is that this code is also visible to all other users and relays, who can now track a chatroom you participate on. Today, they already know one side of the conversation — your pubkey is visible. They know you are receiving. With this change, they can also cluster all messages from the same unknown sender into a single timeline, without decrypting anything.
This means that they can also filter spam, but also means they can censor you by blocking messages from given senders they do not like.
So, less privacy and less censorship resistance in exchange for easier time for devs + less bandwidth used + gains in spam control.
On top of that, the new code works in such a way that the sender can now delete their messages to you and recreate them in the past or future.
In the original NIP-17, once the sender sends you a message, the message is yours. They cannot delete it anymore. If your friend's key leaks in NIP-17, the attacker cannot change the history of DMs. But with this new change, they can. They can delete and rewrite the past.
So, less historical safety in exchange for easier time for devs + less bandwidth used + spam control by relays.
What do you think about this trade-off? Acceptable? not acceptable? Was I clear? It's hard to simplify these things... But we try:
https://github.com/nostr-protocol/nips/pull/2396
3910❤️10🤔3❤️2👀2👍2🫂2
