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
