Whoβs sliding into your DMs?
Now everyone knows, LOL. π
Discussion
π
Like I said, weak encryption...
Those are Nip04 DMs, we are using nip 17 which is much stronger.
Can I ask if there are any nip17 complaint clients for iPhone?
YakiHonne, Nostur, 0xChat, Flotilla, Coracle, Chachi, pretty much all of them but Damus and Primal.
Weβre even building it into nostr:npub1xxdd8eusvdxmaph3fkuu9x2mymhrcc3ghe2l38zv0l4f4nqp659qskkt7a.
Gotta specify nip04 DMS otherwise this is just trashing nip 17
nah, specify by client. here ill make it easy, damus and primal. singlehandedly holding back DMs since 2023
Well, you could propose a fork to my note, but it would only work on Amethyst.
oh, I thought you meant on the website..
nah, im trying not to care, the hours I put into helping nostr ecosystem launch nip17 only to have this still happening 3 years later is just, hurts at this point.
Man... 3 fucking years...
the utter clown show of DMs on nostr is painful indeed.
i am quite sure that the nostr relay connect - a rendezvous connection like NWC or bunkers, is the way to go. enable synchronous, peer to peer connections between any nodes.
go look at https://smesh.mleku.dev - run it on firefox and on chrome in another window, logged in, go to the settings in them and you can set up the rendezvous, then copy the URI over to the "client" client and voila, one connects to the relay and waits, the other when it connects it gets a subscription that receives the messages from the other side, and then they synchronise their event stores (it's a cut down relay mapped to the smesh indexedDB cache as well as some small extensions, i forget what exactly.
anyway, same thing can be done between any two nodes. like... direct messaging, synchronously.
then the mailboxes are not on relays, they are in the clients.
also, who the FUCK thought 64kb was a reasonable maximal size for an encrypted blob... exactly
the number of ways that nip-44 encryption is a joke is a list about 10 items long at least. you don't want me to remind you, also, that the giftwraps have to be sent to the destination and also to yourself. which means that though it's very slightly obfuscated, metadata is still there. especially if both halves get on the same relay, their timestamp is almost certainly going to be the same timestamp. still narrows down pretty far even if the relay had a few thousand regular users, the analysis to identify chat partners would not take that long.
that's why. auth. that's why synchronous via bunker style rendezvous connection to enable inboxes IN clients.
why does it take an unbelievable amount of time?
you're not even showing me ads while I wait
missed opportunity
All processing is done client-side. Maybe you have a slow computer?