Replies (43)
Lots of shoulds.
Oh also you can just add an I2P address in your kind 0 or whatever
I've started a few mini projects similar to this and then thought, what's the point. Remember VOIP on the lightning network?
Exploring the capabilities of nostr is very useful and it will be how other things are figured out. These sandboxes are fun but don't have to become fully fledged projects.
I'm also worried I'm becoming a grumpy old man like nyms I used to eye roll about when reading their tweets bitd.
This is NOT gonna age well at all 😂
Big brain cycle is to complain about things because they aren't done the way you know they should be done because I'M AN EXPKRT IN THESE THINGS, but not actually doing anything.
I do agree experimentation is useful, but some things will never produce useful results.
Sending data over Nostr is known to be inefficient: it has a lot of overhead for everyone involved.
While nostr identities as websites may be useful, this can be achieved in simpler ways like a replaceable event that has hostnames and have actual utility for things like relays with public key identities. (DNS/IP/I2P/Tor/etc addresses)
responding with ad hominem attacks doesn’t change the fact that this is a horrible idea
Exactly, this is why experimentation is valuable. Big brains have blind spots too and often big brains tend to have arrogance associated with them.
It's not.
That's not a bad idea. It just won't work in the browser without additional software.
You could also just as well host your own bridge in that case. You may claim “privacy” but they could also send you code stealing your nuts either way.
The browser is made to execute interactive applications from a source in a limited context. Not allow you to do anything and everything.
I said "without additional software". Running your own bridge is additional software.
- it has no benefits over competing solutions
- it has large bandwidth overhead
- it misuses existing infrastructure designed for storage of small notes for data transfer
What I’m trying to say is the additional software part does not matter and you can use a bridge hosted by the dev or a public one in a way that doesn’t worsen the risk model (the client dev can backdoor and steal nuts anyway)
yeah all that works here as well with https or some other transport encryption but it also works without a bridge, directly from your browser.
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 🤭
I still don't fully understand this, I would like to see a POC in the wild, i think new ideas like this are cool but this seems a bit complex, i was expecting something simpler for the cashu mints use case tbh.
I still love these hacker things, they're fun. Useless? Probably. But that's not a problem. If you don't do stuff like this, life would be boring.
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.
the NUT is in the packet!
Me 🤣 I can even tell you how much. Nostr is worth $120 a year to me. That's spending on mine and other people's relay. And the price is only going to go up.
X is cheaper.
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
if you can pay for relaying and it's only used for broadcasting notes without leaking origin information then it's awesome
only way to do that is with micro accounts bootstrapped through multiple hops, then you "spend" your credit with your traffic, and the payment and traffic are isolated and the origin and destination of notes is obfuscated
ecash isn't suitable for this because the mint sees the buyer and seller of tokens location, has to be done using microaccounts
"Should" is bound to my own expressed opinions, I'm not in charge.
it must use micro accounts, you can't pay as you go without revealing yourself
Experiments is valuable, so is not being afraid to call out bad ideas. Otherwise this place just becomes a massive circlejerk
GitHub
GitHub - indra-labs/indra: Distributed Virtual Private Network Powered By Bitcoin Lightning
Distributed Virtual Private Network Powered By Bitcoin Lightning - 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
I agree it's fun an interesting just like messaging apps using LN.
I've had those shoulds all my life.
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
Then you "shouldn't" get so triggered over an opinion
at that point use i2p no?
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.
It’s a shitty transport protocol that you should not implement and instead use I2P or Tor
💯
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.
group think is the enemy of innovation.
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
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.
100%
Another science project
