Oddbean

as an amateur cryptographer, this anti-nip-04 thing is completely nonsensical chacha-poly-1080 in not stronger than AES 256 ... what is it CBC? ... no, AEAD... with no actual extra data btw, so it was pointless making it that anyway the giftwrapping enables some degree of forward privacy but it also makes it complicated for clients to see messages the user wrote, and i notice this all the time clients are not seeing the messages after making my relay really nice and easy to extend and work with one of my first priorities is making messaging work properly like, seriously, do people not get it the reason why i am always talking about nip-42 auth all the time is so you can prevent access to these messages in the first place? the right way to do things is to test and certify that relays are not allowing access to events they don't have proof of being in the conversation it also applies to application specific data events too, which are encrypted, by some clients, but not by others (looking at you #nostrudel )

seriously, has anyone actually thought through the problem of implementing clients to pull messages that contain no reference to a user without leaving them wide open for anyone to read? first rule of signals intelligence is don't send a signal you don't want to be noticed for its mere existence, or at worst, exposing you to a potential plaintext attack if the encryption has a flaw i honestly don't think that anyone else in nostr dev really understands the problems they are trying to solve with nip-04, nip-44, and the rest

The main issue is that nip-04 leaks way too much data not only to the relay, but to the public in general. On top of that, the encryption procedures of NIP-04 are laughable. The lack of padding alone is a major problem. Imagine saying "Hi" on a DM and that gets converted to 4 encrypted chars. Besides letting everyone know your message is small, how hard is to break the encryption of a 4 char cipher text? Not that hard. If you repeat GMs around, now you have 100s or 1000s of 4 char encrypted messages. How hard would it be to recover your shared key knowing all those little messages? Not that hard. With enough shared keys, how hard would it be to figure out somebody's nsec? It gets in the realm of "possible" with today's available computing power.

it won't be that way forever... something i want to do with my relay is have it actually propagate delete events when it receives them so everyone who might actually do it can find out it is requested

This sounds very useful, i also imagine part of the problem is just getting the delete event distributed. For now I used a blaster relay but they also only send to the X biggest relays. Would be cool if clients would rebroadcast important events like delete too.

it's that kind of "everything must be permanent" blockchain mindset that held me back from even trying nostr for a long time it makes sense for public declarations and publishing, but not for day to day private life social media stuff, and even less so for DMs

some relays literally don't have it implemented it requires some extra pieces to work, you have to keep tombstones of the event id to prevent it coming back, and that necessarily implies an eventual need for garbage collection in general and yeah... expiry... i'd implement that on my relay if i knew of a client that i want to use that has it, because that's a cool feature, especially for DMs... it can also function like a dead-man switch too, as part of a system to enable stale follow npubs to be removed (because those damn follow lists seem to be like ratchets, only going in one direction, bigger, because if people don't post they don't see and don't think of deleting

the leak to the public is because of relays not implementing auth at minimum, they should implement auth to access DMs if everyone's relay did this, that problem goes away it's never a better solution to use obfuscation when you can instead simply not send out the signal