<oembed><type>rich</type><version>1.0</version><title>VitorPamplona wrote</title><author_name>VitorPamplona (npub1gc…fnj5z)</author_name><author_url>https://nostr.now/npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z</author_url><provider_name>njump</provider_name><provider_url>https://nostr.now</provider_url><html>There is a proposal by nostr:nprofile1qqsf03c2gsmx5ef4c9zmxvlew04gdh7u94afnknp33qvv3c94kvwxgsppemhxue69uhkummn9ekx7mp0qyvhwumn8ghj76rzwghxxmmjv93kcefwwdhkx6tpdshsz9thwden5te0wfjkccte9ejxzmt4wvhxjme0sadgdk to simplify NIP-17 in exchange for less metadata privacy and safety for all users.&#xA;&#xA;These are real gains by have real tradeoffs, so we need your help.&#xA;&#xA;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. &#xA;&#xA;Because of that privacy by design feature, relays also cannot filter messages: there is no way for them to only accept your friend&#39;s DMs because they don&#39;t know. They cannot know. There is no way for relays to filter spam. In NIP-17, that&#39;s the work of the receiving client. The relay is absolutely powerless on purpose.&#xA;&#xA;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. &#xA;&#xA;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.&#xA;&#xA;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.&#xA;&#xA;So, less privacy and less censorship resistance in exchange for easier time for devs + less bandwidth used + gains in spam control. &#xA;&#xA;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. &#xA;&#xA;In the original NIP-17, once the sender sends you a message, the message is yours. They cannot delete it anymore. If your friend&#39;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.&#xA;&#xA;So, less historical safety in exchange for easier time for devs + less bandwidth used + spam control by relays. &#xA;&#xA;What do you think about this trade-off? Acceptable? not acceptable? Was I clear? It&#39;s hard to simplify these things... But we try: &#xA;https://github.com/nostr-protocol/nips/pull/2396</html></oembed>