well i can see why nwc is so flake now, since you must use it with a free relay with no access control (at least with amethysts implementation). not even the last of the free relays will let you use that many reply tags from rando keys. and even if they did, the response is too big.
what a mess.
ah, i wasn't aware of that, i hadn't got that far into implementation yet
it has to support auth
i will make it support auth, because the whole point is to enable zapping the relay to pay for subscriptions
i'm not sure how auth has any effect on limiting spam though, since you end up with a chicken and egg situation then, i want to subscribe to relay, but i'm not whitelisted, what then?
surely if i zap to the relay wallet, and then it has the npub in it, it adds the npub and relevant expiry for the subscription, and then after that it will let zaps be published
this part about how big zaps are, they are damn big alright lol, second in line after follow lists for their sheer mass
yeah, i dont know how to unwind the mess of supposed 'privacy' that devs have glommed onto (its not even providing privacy). they dont mind that its spammy, and just expect there to be free relays with no controls.
with auth, you could have the client and nwc server auth with one key and then use random keys, but they wont like that either cause 'muh relay operator can see my keys'. well, thats why you would run your own relay. "but nobody does that". yeah, its endless cycle of chicken.
I can see the appeal of random keys, but you're right that it might be best to make this optional
yeah, random keys is useless though if you keep sending them from the same damn ip address that is your home router lol
Well... yes, unless your client "home router" is a major corporation's AWS gateway, and your wallets "home router" is tor.
whats it successfully hiding tho? you still have to tag those pubkeys, and if you can see the events you know the same amount of stuff as the random keys. because tagging. each user will have their own nwc daemon pubkey theyre talking to..
Haven't looked at the spec in a while, but IIRC each pairing had a stable key. You could see the activity for a pairing, but you wouldn't know what the endpoints were
the pairing keys are just for connecting up wallets to nwc capable clients, right?
as far as i can recall, these are ephemeral events and the relay essentially acts as a proxy between them, for reasons of stupid internet protocol NAT bullcrap
being that the events, albeit big, are not supposed to be stored anyway, i don't think this is a problem... i may be misremembering the spec though, as i said i am only in the process of building out a #golang codec for the protocol at this point, not to the level of actually writing a client or server side of it
also, yeah, it really should include auth but unless i'm mistaken, that is entirely the responsibility of the client side to implement correctly, as far as i can tell, otherwise it's just a matter of having a side channel to negotiate the connection key
i think that the issue of privacy in this is best resolved by using nip-44 encryption, giftwrapping the messages, and, you know, not putting anything but the wallet/client connection details outside of the giftwrap
it's something i want to work on, in the future, my relay project is ready to deploy for this kind of use already, just that the part involving managing subscriptions has not been implemented, this can be entirely separate, running on a separate server because it is managed by follow lists, not some extra protocol
well, the lnbits nwc plugin doesnt do auth, so i would have to write some python. or figure out if i can run just the nwc from alby without the rest of the hub parts 🤔
yeah, the absence of a #golang implementation of NWC is a real problem for me, and i know it would help you if it was done
i have it on my todo list, and i have done most of the message codec so far, just haven't finished it yet because it's quite extensive
also, i hate all these other things... fucking python, rust, c++, javascript, utter shit languages to work with, what is wrong with these people?
yeah they are truly insane
i will be implementing it how i think it should be, especially if i do get a grant to do so... it's on my list of things to do but it's currently behind nip-79 nostr relay chat because i think that is probably more important (this means relays bouncing ephemeral messages carrying instant messages, including ones to other users using nip-44 encryption, but the relay doesn't store them, so clients have to do something else for that, i haven't thought about how to do it but first priority is live messaging
i'm totally ripping off the interface design of telegram for it as well, since i think that nostr devs like telegram, and it is a very neat, minimalistic design
