pull down to refresh

Yea, but it is somewhat literal where it does work like Tor, in terms of hiding the full path from intermediate hops

My beef is with Bolt12 and the introduction of onion messages on the network layer for arbitrary data, that just gives you the unreliability and slowness of Tor unnecessarily and completely unmitigated by the lock of an htlc

Lightning really should have been a web spec, not this p2p slop.

24 sats \ 2 replies \ @brink 21 Jul

Can you detail what you mean by web spec?

I don't consider p2p slop, it is also how fiat banks work. If two banks don't have a partnership the payment can go through a third party bank that have partnership with both banks. There is a need to go through trust/liquidity links.

On the other hand, onion messages are a big mistake (onion routing is great though), no objections there.

reply
7 sats \ 1 reply \ @justin_shocknet 21 Jul -420 sats

Comms specifically, payment channels ofc need to route p2p, but doing so would be more efficient if nodes could reliably reach each other directly and coordinate that... They can't given NAT, dynamic IP's, militarized networks, etc... this would also have less centralizing effects than LSPs do where an static IP4 is effectively a requirement to be a reliable LSP.

They also need an overlay like CLINK to be useful on the web/in user apps where payments are actually executed from

CLINK is based on Nostr, but there were predecessors to Nostr that worked similarly. Web addressability to bootstrap RTC data channels probably would probably have been sufficient at the time.