Lots of shoulds.
Discussion
I have another question. Who is going to pay? Relays can't work for free with all the load they handle. And what will happen if we start paying for website access. But at least there won't be DNS issues 🤭
Idk, who's paying for your post right now?
I'm going to use this for Cashu which is very low-bandwith so none of this will matter.
using a relay for mostly small notes as a network tranport is a dumb idea unless you can make people pay for this use case in which case specialist nodes will be made just for doing this
creating a websocket based for-pay relay scheme could actually work for short messages though, just need to wrap the events in three layers for each hop and a payment nut in each one for the relaying service and no spam problem and anonymous relaying
> NWC has entered the chat
it must use micro accounts, you can't pay as you go without revealing yourself
https://github.com/indra-labs/indra has a heap of code around accounting and the layered encryption required
the sender provides the keys as the payment preimage over lightning
ah yes, it does require you to run somewhat unconventionally configured lightning nodes that can receive keysend/AMP payments, this isolates the payment from the user's location via TLV onions of LN
it's a mostly complete implementation, there's nothing really stopping you scooping out parts of it, it was designed as a full blown network transport but anonymised relaying is a subset of what it is capable
at that point use i2p no?
if you have lightning nodes attached to the relay that can receive keysend/AMP payments you can pay anonymously and load credit on a special pair of keys (you create and provide two secret keys to the sender that identify your messages as being associated with the account
then you construct 3 hop chains (or more) based on this and each goes to a different relay, the message is encrypted using the account key recognisable by its matching pubkey in the header and the relay then knows it can forward it as it's paid for, no spam problem
this is a perfect use case for it as a way to enable nostr relays to act as VPNs for paying users
anyway, just check out what i invented, of course i hope it gets used, i spent almost a whole year working on that, but didn't get to the actual testing phase, it's just a heap of unit tests with virtual relays and an encryption protocol and session payment protocol all written and tested
https://github.com/indra-labs/indranet - this is what i'm referring to
"Should" is bound to my own expressed opinions, I'm not in charge.
I've had those shoulds all my life.
Then you "shouldn't" get so triggered over an opinion
Hardly triggered. This is boring, let's be constructive.
Nostr sucks because it's jsons on websockets. Nothing you can do about it. We work with what we have, and we have a specific low-bandwodth use case so the inefficiency doesn't matter to me.
Speaking your mind is being construtive. I don't think I'm engaging in bad faith and I'm ready to be proven wrong, as I did before.
Nostr is not the ONLY thing we have, it's not like we have to make it work for absolutely everything. If you like it and want tcp over a nosyt proxy bridge, by all means go for it.
I’m fascinated by the potential for this.
I don’t see the full picture yet, but normally that means it’s waaay more significant than I first thought.