pull down to refresh
111 sats \ 4 replies \ @ZezzebbulTheMysterious 9 Oct \ parent \ on: Could you run lightning on top of nostr? If so, would you? nostr
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
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