pull down to refresh
199 sats \ 7 replies \ @justin_shocknet 9 Oct \ parent \ on: Could you run lightning on top of nostr? If so, would you? nostr
Nostr can be used in a p2p like fashion and has much lower latency than Tor because no onions are required, you choose your relay, and can natively deliver data to the web where it's used
It solves NAT, and unlike Tor isn't a privacy nightmare getting your IP monitored by ISPs and Intel agencies, blocked by UTM, and so on... Nostr blends in with generic SSL traffic
There's also kind ranges for non- persistence like packets, basically everything you said is a complete reversal of the facts
You would get better responses if you were respectful. If you think I have “reversed facts”. let’s explore this rather then saying I’m wrong.
I fail to see how picking a relay, that fact no onions are required (?) and native web data delivery (whatever that is) has any effect on latency.
Nostr is a relay based protocol. It has clients and relays. How is this peer to peer? How do I address another node and have it route?
It’s not a routing protocol. It’s a caching messaging protocol.
reply
Responses from people who state things without having a clue what they're talking about aren't a KPI I optimize for, not conceding anything I said was disrespectful before. If you'll project that anyway I'll consider being disrespectful explicitly
Tor is literally chaining anonymous relays, without any optimization. Nostr is singular, already clearnet, and geo/performance easily optimized.
Each encryption layer is work that takes time, time is latency. Geography also impacts latency.
I said p2p like, peers don't need to trust the relay, it achieves NAT traversal and discovery. P2p sucks, it's fragile and doesn't work ... Torrents for ex still use trackers because of this despite decades of p2p DHT larp
Routing is a separate concern independent of the base communication layer, the lightning graph is also a cache
... You ignorant Muppet (this is disrespect)
reply
If you wish to have a real technical debate, I’m open. So far you’re just rude. I appreciate that you generally win an argument not on tech merit but via being the rudest party. That fine. I don’t, and I’m not offended.
You are comparing non equivalent things here.
If you wish to have an actual technical discussion on the tradeoffs of caching, latency and onion routing vs broadcast over the public internet, I can share my position and beliefs. But otherwise you are mixing a lot of ideas and words here that don’t make sense.
Tor is “chaining” without “optimization”? Nostr is “singular”? Routing is separate than the “base communication layer”? Lightning Graph is a “Cache”?
Keep going bro
reply
I’m open
Seems not, you intentionally derailed the thread with your crying about tone because you got nothing of substance
generally win an argument not on tech
Sorry for the delayed response, I was on a flight coming back from a fully comped trip because the shit I've built with this tech has blown some minds, what is it you do you do again? Cope.
a real technical debate
Not that I think you could even parse one if you saw it, but since there are non-retards reading this I'll clarify for their sake...
Tor "the onion router" forwards comms across multiple hops, that's a chain of relays in the Nostr analogue. It's latency and reliability can't be optimized because by nature the next hop can be anywhere or anyone. Nostr relays on the other hand you pick and choose, which means you can even optimize to equivalence of a local reverse-proxy.
Routing is how Lightning moves Bitcoin, it uses a custom communication layer to coordinate that, but that communication layer could easily be anything... like Nostr events.
The graph in Lightning is data that's cached by nodes and served to other nodes, just like a Nostr relay serves notes.
Keep going bro
Cry harder.
reply
Thank you for explaining your words. Derailing what? Bro, you need to be nicer. Your argument holds no water while you act like an ass.
I appreciate that you like the LN over nostr pattern. You are welcome to build on it.
reply
Still no technical debate, just more crying.
Introspect that before you give me advice.
reply
Right back at ya! I’m not trying in insult ya. We have a problem here tho. So, back on topic.
Ok, few issue you may not have considered are:
Non persistent note flag is implementation specific; if my modded relay is set to snoop all your traffic and record traffic - Intractable problem.
Open source and voluntary nature of nostr relays.
Not an issue with tor, due to telescoping (eg: intermediate nodes on path do not see routing metadata). Even if we encrypt the full payload, the npub is in the clear. This is not the case for Tor.
Routing metadata - tor vs relay; I appreciate that there similarities with peer routers and guard/tor nodes - however the telescoping behavior of Tor circuits leaks much less metadata. I’m already assuming I’m capturing all the notes, and now I’m snooping on the addresses too.
The behavior of the intermediate nodes on the path is a known quantity too vs implementation specific behavior in nostr relays.
Other have alluded to latency, which apparently I know nothing about. There is a publish, relay, database cache, and fetch cycle associated with each note which does not exists over a TCP/IP or Tor circuit.
It’s not to say you can’t design a low latency solution using the protocol, but do not ignore this trade off. I would estimate the order of latency for note propagation vs single LN message over Tor to be ~10x. Happy to be proven wrong here. It’s comparing a broadcast application layer protocol (in JSON no less) [nostr] to a low level network routing protocol [tcp/ip or tor circuit]. Of course it’s going to add trade offs.
reply