NWC is a pairing protocol, so every key should be random. Weird that the response was too big though? I haven't used Amethyst
Discussion
i was reading the spec it doesnt say you have to use random. i wanted to use my relay and i added the nwc daemon to the list. but if i open to random keys tagging, then ill get spam. (and then i did that anyway). i dont understand the gravitating toward 'free for all relays' for everything..
and then yah, the response from the nwc daemon was huge so i guess, im screwed. the relay is already maxxed out on size settings. 😭
i just am in disbelief sometimes when i go to see how shit works. i wanted to like nwc.
i have started work on implementing NWC support in #realy but so far just implementing the actual Go RPC API actually, then i got excited about the idea of the NIP-79 (proposed) nostr relay chat protocol, which i have now got the beginnings of a telegram-style UI started
anyway, i've applied to opensats, for funding to build out three features:
- full NWC support including supporting paying for subscriptions by zapping teh relay npub
- full text search indexing so you can put a query in the "search" field of a filter and it will return events with partial matches, sorted by relevance (more matches = more relevant)
- full support and client for an instant messaging client that runs on ephemeral events
i hope i get it, though i'm not in a rush, i want to at least finish the current task i have with my paid gig for their gamer play partner recommendation engine and user database cache
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
Maybe you can limit unauthenticated notes to the NWC types? I don't know what the current relay authorization methods look like
true, ill prob switch to that now that i can see what its doing.. it could be used to fill up a relay with noise, but at least you wouldnt see comment spam..
you could also add special filters with auth, im unsure the nwc daemon can do auth but i will find out.. at least then, rando snoopers wouldnt see ALL the nwc calls.
i already have read-only access available to any query for profile metadata, follow, mute, delete, report and relay lists for #realy it would be simple for me to add an opening to allow publishing NWC events... if they are ephemeral, which i think they are, then the only really hard problem will be i will need to add a rate limiter on the socket when these kinds of connections are made
Is there a gateway where every operation costs sats? Then every post could be 1,000 sats, every search 5,000 sats, paid by your wallet to ... also your wallet. It would cost you fees, but if you kept getting spam you'd be making Bank.
usually youd have to write a client too, but, that reminds me, amethyst might be able to do things like this with the fancy notice 🤔
per-operation payment is a lot more complex to build than subscription based schemes... plus, the latency, i mean, ok, LN is fast but imagine waiting for an LN payment for every. fucking. event. and. query.
oo what if auth with lightning. so it doesnt know your pubkey, its per connection
yeah that would work too but how do you rate limit then? also isn't the lightning identity still like ... a pubkey?
just a thought, it wouldnt help make DMs secure, it wouldnt care about your lightning pubkey, it would just wait for a payment to open the connection. subsequent connections also would have to pay.
rate limits inside the websocket connection, still would need to build..
i kinda like it better than pay per message or etc.. all these things are fun to think about till you realize you have to also write a client for anything to matter.