pull down to refresh

Good question, thanks.
CLINK is, at worst, par with Bolt12 wrt privacy. I think it's much better of course though, given the flexibility it affords.
First point of order is that Bolt12 itself doesn't actually help with privacy, things like blinded paths that it uses to justify those claims exist outside of it's context, and so the invoices CLINK serves can use that as well.
Where I think it's better is that Bolt12 is inherently tied to the receiving node for communications, where CLINK's use of nostr as an overlay network can use ephemeral or decoupled keys. It could even be used to fan out invoice serving across multiple nodes to keep an attacker guessing (our ref server doesn't do HA or randomization yet, but will eventually).
Also, since the transport is not using Lightning, that leaves fewer ways to leak metadata to your Lightning peers that could be used in a correlation attack.
Other things we can do in terms of roadmap, since we have nostr as an overlay network, is leverage that to coordinate things like lnproxy by @supertestnet which would effectively give nodes the ability to tap into a marketplace of obfuscating hops outside of the channel graph by sharding hop hints.
In short, privacy is ultimately a matter of implementation rather than protocol, but the flexibility of CLINK in using nostr as an overlay network allows those implementations to do everything Bolt12 does and much much more.
Right of course, I am most interested in the idea of a blinded path baked into a BOLT12 offer. Does CLINK use blinded paths or have that on the roadmap?
I am averse to lnproxy since I think it could wind up being a centralized data repository.
reply
Blinded paths are just a flag in lnd, can probably have a demo of clink using one tomorrow
Using Nostr to advertise proxies would just be a listing, the forward data wouldnt centralized, each hop would only know the next hop
reply