Ya I'm trying not to confuse everyone too much with the DMs .. that horse has been beaten to death. And I agree though and auth, is important for many uses. What's really important though is paid relays /acls. Auth just adds the read acls to what currently is write acls. Nothing is free, or you're the product, etc. posting spam and annoying people's inboxes, is certainly not free.
Discussion
it has been beaten but that horse is not dead
the complacent attitude about this is disgusting, and all the devs who are complacent about auth should be ashamed of themselves for not promoting the easiest solution: auth
clients can then give users the option to refuse to send DMs to non-auth relays and problem solved
or else, if you don't see the sense in that, you are clearly in the employ of the deep state, if you ask me
and as for quality control, how hard would it be to write a battery of tests that you can run and publish the results, that prove that a relay is not complying with the confidentiality expected of it?
all the problems are solvable, if not directly, then indirectly, just that asshats are chasing after glory because they are virile young men with something to prove and borderline personality disorder
😂
I actually have to virile young men with something to prove writing code, but I got lucky and they're both also total QA Nazis.
I guess it is kinda clients.. I keep thinking it's relays cause I wasn't able to implement auth yet. But there are relays that do, so I see your point.. DMs have been broken a long time, but not for lack of them trying to come to a consensus.. just they haven't come to a consensus. Lol
because they are too busy getting their egos stroked for solving less important, more glamorous problems
I think they decided it should never have been created. Gossip was the only client, didn't implement DMs. Then compromised and now shows them, but you can't use them. (Gossip protocol prob never was meant to work with DMs, because DMs are DOA). Now that I'm saying this I doubly realize why I shouldn't bring it up in gossip discussions.. but I still want gossip to work with acl based public events.
as my boss said when i said "we'll get nostrudel nip-42 auth working" - no, we need to get damus and amethyst they are the biggest user base
i say chip away one at a time, don't go straight for the hard part of the structure, always find the weakest parts and the pressure eventually makes gravity itself do the work for you
i think they are wrong, without DMs it's not a social network protocol, they are just too dim to understand authentication flows and so they are trying to get everyone to ignore the elephant in the room
the majority of nostr devs don't have any real grasp on cryptography or security, and it shows in the lack of support for DMs
Wouldn't it have to work the other way around?
I'd want to limit my inbox to a couple of relays (Franny's and the one I own) and people would have to contact me exclusively over those. She runs her own and charges for its use, and I pay for one and limit access over a whitelist/blocklist.
We have busy, spam-free, family-friendly relays, as it were. I bet they'd be good onboarding relays, for English-readers.
Clearly have been gossip too much and I'm no longer sure if by inbox, you mean the nostr DMs or just public comments/events, or both 😂
Many problems with nostr DMs, is why even with auth, most people agree that they suck in current form. There is no key rotation or 'forward secrecy', and a compromise for either parties key, means leak of all messages. Auth is barely a bandaid. Some clients trying to innovate with giftwraps, but I haven't seen this working despite claims it's implemented in coracle and amethyst for 'advanced dms', also not sure about the rotation there. Private groups, those do have key rotation, just in coracle only and unaudited by a security team afaik.
this is why i'm ranting about how idiotic it is to call it gossip
giftwraps are just DMs where the sender is hidden, another somewhat vague term to use
yes, the key rotation protocol is a problem, in my work with colby a long way back he was all about MLS key exchange protocol, which is used by... i forget, it's basically a multi-user scheme like signal protocol double ratchet but has a key derivation path that forms a tree with each user at the end of the branches
That sounds awesome, maybe Colby can figure out all new DMs after the gitnestr 😎
key rotation requires an interactive protocol, which is outside of the pubsub model of nostr
there is the potential for some kind of key rotation by sending a return address with each forward message, that only fails if the reply is not seen, this is still better than what we have
i was using "send reply address" in a more advanced form - send return PATH - in the indranet project
indeed, this could be even done here, but it then adds an extra layer of turning relays into ... proxies... and raises the spectre of spammy dummy content being used to jam up the channel, which again comes back to auth - in this case, a passive form that is simpler "accept event based on pubkey" and then you just need anon payments for these relaying accounts
but this is all a lot more complicated than neccesary for the simple task of making most relays respect FUCKING CONFIDENTIALITY
i don't accept the "band-aid" perjorative
if it's not worse than trusting google, then it's fine, shut the fuck up and take my money
note that "return addresses" protocol gets complicated because you are gonna be tying a request IP address to the keys when you use them, so there's not really much point in adding this complication
I have no idea, sometimes I think down these scenarios and run into a solid wall... Then back out and think some more. Lot goin' on w this stuff.
For the auth, yea, it's clear it needs implemented. That's all I really know at this point. 😁🦀
yep, solve the harder problems tomorrow, easy problems should not remain unsolved this long
I use SimpleX.
Ok cool, so then yes, for the public events, your plan is a good idea, it's what I would think everyone would want..
and I am simply trying to ask around to see if client devs lives could be made easier by a field in the nip-65 relay list, that clients can show their users "hey, if you wanna message the inbox of this person, here's a link/payment/etc". For some reason they're really stuck on these free access relays for inboxes.. might have to habla.
free access to relays for pulling only DMs and only ones that have your pubkey on them still needs auth and solves most of the spam problem
just account the accesses to the paid user npub also on them, or add a database record alongside them that identifies the sender so they are billed to them either way
honestly, giftwraps solve no problem at all
You're sorta talking over my head, I'm afraid. I can't figure out the auth thingy. Who authorizes who when? I need a diagram, or something.
Auth is for controlling reads. Without it currently, anything can be read.
Ah, yes. Yes, there's no way to limit reads. No way to be private.
auth is just asking you to prove ownership of a public key
this acts as at least a temporary identity for a session
at best a way to prove you deserve to access privileged data (your DMs)
it is identical in every respect except algorithms to how all password authentication systems work - it's not the password that is stored, it is the hash of the password...
NIP-42 is like CHAP, which is used for dialup and ADSL internet, it sends you a random string, you generate a response, and only teh valid password produces a valid response
Ah okay.
My current approach is, do what it does now for writes (whitelist/payments) with the addition of auth in the coming months, it can also control reads with these same rules. I will also add fine grain acls for kind lists. This should cover everything I can think of. (DM circus and all).
yep, that's what i'm in the process of building... i also have already got a failover for auth to use it as a secure CLI via DMs, which is part of where my irritation with the lack of NIP-42 comes from - if no NIP-42, then i have to build out a whole second channel to enable secure administration functions and i just refuse to duplicate things for no reason
I'd like to be able to select whatever I want to limit, really.