NIP-69 Nostr Offer STRings

[shocknet-justin]

Static payment codes to replace LNURL-P

edit: This NIP now has a companion, NIP-68, to allow the inverse operation of ad-hoc debits

#1529

[staab]

So I'm not well versed in the details of lightning, but it looks like this at least partly overlaps with bolt12. Why not use that instead?

[shocknet-justin]

So I'm not well versed in the details of lightning, but it looks like this at least partly overlaps with bolt12. Why not use that instead?

Bxlt12 is effectively a re-implementation of Tor which has proven too unreliable with Lightning as bouncing onion messages across hops adds latency and failure probability. It also can't be used trivially in web apps, where Nostr excels and most economic activity happens.

There's also the separation of concerns in that Lightning is a payments network, not a communications network. Muddling the two like bxlt12 is scope creep for implementations that now would need to provide account related hooks, something that's much more straightforward in a Nostr middleware. Nostr offers are also portable across nodes unlike bxlt12 (and it's keysend predecessor). Reality is that the prevailing implementation has had keysend for years and that coupling of LN and Identity is not optimal. Same reason LNURL-Auth had so many issues. Bxlt12 is just a bad design and manufactured hype by the minor implementations looking to gain some share as they trapped themselves into trying to turn phones into servers.

[shocknet-justin]

This is now implemented for additional testing in ShockWallet and Lightning.Pub

A simpler demo client is also available at demo.nip69.dev

How we are using this to provide self-custodial Lightning Addresses:

Shockwallet will automatically claim on users behalf a shockwallet.app Lightning Address from a LNURL bridge server. The bridge server will serve legacy LNURL clients by using NIP69 as the method of communication for invoice fetching from self-hosted Lightning Pubs. NIP69 aware clients will simply see this value and fetch the invoice directly as if the offer were Nostr metadata or included in NIP05.

We will provide sources for a simple bridge server shortly: https://github.com/shocknet/bridgelet

[jklein24]

Love this! Very cool stuff @shocknet-justin

[ekzyis]

Afaict, this means that one can only specify invoices in sats. It would be nice if you could consider to use msats here. Explanation:

LUD-06, NIP-47 and NIP-57 also specify the amount in msats. It would also be good for us at Stacker News if this spec supports msats out of the box because we forward payments between users and take 10% as a fee for sybil resistance and rewards. This means that if someone zaps 25 sats, 22.5 sats will be received which requires being able to specify invoices in msats.

Ideal would be amount + unit like BOLT11 though but msats is probably good enough and would be consistent with other specs as mentioned.

I have to mention though that most LNURL providers seem to simply round to nearest sat so don't really support msats; contrary to the spec.

[shocknet-justin]

LNURL providers seem to simply round to nearest sat

Yea I considered this but steered away from assuming any baggage from LNURL... the issue with millisats is that they can't actually be settled in payments (technically they are shitcoins and thus rounding happens regardless of whether we use them or not). The scope operates on the assumption that offers will be used in sales reports and things of that nature which do not go to decimal places of a penny etc and so I didn't re-introduce that here.

[TheBlueMatt]

Bxlt12 is effectively a re-implementation of Tor which has proven too unreliable with Lightning as bouncing onion messages across hops adds latency and failure probability.

Do you have a source for this? I don't know anyone working on Lightning that thinks this.

This seems like a pretty poor reimplementation of BOLT 12 over nostr that loses some of the important features of BOLT 12 (like recipient privacy!). If you're insistent on not using Lightning onion messages (and getting the privacy that comes with them), why reinvent the wheel? Just shove BOLT 12 messages over Nostr?

[shocknet-justin]

Do you have a source for this? I don't know anyone working on Lightning that thinks this.

You can find hundreds, maybe thousands of people debugging their Lightning node across socials over the years where the ultimate solution was disabling Tor. There's too much latency and failure probability to make it reliable enough for real world use.

This seems like a pretty poor reimplementation of BOLT 12 over nostr that loses some of the important features of BOLT 12 (like recipient privacy!). If you're insistent on not using Lightning onion messages (and getting the privacy that comes with them), why reinvent the wheel? Just shove BOLT 12 messages over Nostr?

It's not a re-implementation of BOLT12 at all, and that's intentional. This also makes it far more private because the keys are completely decoupled from the payment layer, Nostr ensures that comms and payment concerns are properly separated. If a recipient wants to use blinded paths/rendezvous/randomized scids in the bolt11 invoice they can already do that.

Nesting OM's into yet another overlay network would make performance an order of magnitude worse than it already is. The goal here is to obviate that while at same time delivering only what's needed where it is needed: the web.

That said, optional fields mean a wallet service COULD return a bolt12 offer just as they would a bolt11 invoice, but there's no logical reason why they would.

[vitorpamplona]

optional fields mean a wallet service COULD return a bolt12

We hate optional fields. Just pick one and go for it. If it doesn't work, we can always create a new PR/NIP.

[TheBlueMatt]

You can find hundreds, maybe thousands of people debugging their Lightning node across socials over the years where the ultimate solution was disabling Tor. There's too much latency and failure probability to make it reliable enough for real world use.

Ah, you're saying Tor is problematic, not lightning onion messages. Sure, makes sense. Its worth noting that lightning onion messages are a totally different thing from tor (packetized rather than stream, minimal bandwidth available rather than full browsing/download bandwidth, etc), so arguments around how Tor sucks largely don't apply to lightning onion messages.

It's not a re-implementation of BOLT12 at all, and that's intentional.

It has a handful of the features of BOLT 12, but misses many others, apologies if I overstepped there.

This also makes it far more private because the keys are completely decoupled from the payment layer, Nostr ensures that comms and payment concerns are properly separated.

Nostr and privacy are....not a thing. If the nostr relay wants to deanonymize you, they can.

If a recipient wants to use blinded paths/rendezvous/randomized scids in the bolt11 invoice they can already do that.
Nesting OM's into yet another overlay network would make performance an order of magnitude worse than it already is. The goal here is to obviate that while at same time delivering only what's needed where it is needed: the web.

Except, no, because the benefit of having the messaging layer use the same path as the payment is you actually get more information from the messaging step - when we exchange BOLT 12 payment info, we do so over many paths redundantly, and in doing so learn which nodes are online and ready to forward the payment, reducing payment retries which is where a lot of the latency of lightning lies.

[shocknet-justin]

arguments around how Tor sucks largely don't apply to lightning onion messages

Except that they do, what matters is proximity and availability of peers between you and the payer. Channel peers in Lightning vs. arbitrary peers in Tor is better, sure. But optimizing for those as your reverse proxy adds yet another consideration for users who are struggling to grasp channel management already.

Back and forth aside, still need to get the response out to a browser in most cases, and offers with any external utility will have already been orchestrated by middleware.

Nostr and privacy are....not a thing. If the nostr relay wants to deanonymize you, they can.

Bolt12 isn't a tool for IP obfuscation, you have to connect to other things on the internet in either case. At least here, your keys aren't linked to anything, and are still optionally gift-wrappable as Vitor pointed out. If traffic level inspection is level of concern we're talking then in that context Nostr has the added benefit of blending in with everything else that uses https. Nostr can do anything onions can do, but better.

learn which nodes are online and ready to forward the payment

I agree this is a very good byproduct but of what is otherwise useless traffic. LND is doing something similar iiuc by flagging channels as inactive. Not sure about others. This does lend credit to the theory that, as Lightning and Nostr move closer together, information from the Nostr social graph will pull Lightning route construction up a layer.

[TheBlueMatt]

Except that they do, what matters is proximity and availability of peers between you and the payer. Channel peers in Lightning vs. arbitrary peers in Tor is better, sure. But optimizing for those as your reverse proxy adds yet another consideration for users who are struggling to grasp channel management already.

Except they dont apply, and this is a really lazy straw man, come on.

Back and forth aside, still need to get the response out to a browser in most cases, and offers with any external utility will have already been orchestrated by middleware.

One way or another you're accepting over lightning. That lightning node speaks lightning to its peers, so this is not a concern.

Bolt12 isn't a tool for IP obfuscation

Yes it is.

[shocknet-justin]

Published and referenced a simple LNURL bridge server that will service legacy LNURL clients by using NIP69 to retrieve invoices on their behalf

https://github.com/shocknet/bridgelet

[shocknet-justin]

Video demo

https://cdn.lightning.video/bd926eaa77a9a1046afb12faabb268be925b01d952edc3ce19d092f258ea3572/4WyiE6SuFQ.mp4

[dhalsim]

This looks very promising, but let me summarize what I understood.
Please correct me if I'm wrong.

Does it mean I can:

1. Run my own LND node locally not connected to public network
2. Run a service locally that listens to NIP-69 events for zaps, talks with my LND node
3. Creates and sends bolt11 invoices over a nostr relay to communicate

So that means, I can have self custody lightning without using tor and a LNURL service, a wallet can pay directly to a NIP-05 address by checking its nip69 field in the content.

But we still need to support Lightning Addresses because it is already popular by so many applications and wallets. So you built a bridge, that when there is a "nip69" field, supported wallets can upgrade the payment to nostr. Unsupported wallets can still pay using lnurl-p but underneath the connection between the LND node happens over nostr.

And I have some questions, too

1. what are the privacy implications over tor connections? Is NIP-44 encryption enough?
2. The bridge itself is still a burden. What is the advantage of using NWC over your bridge?
3. Do you think people stop using LNURL altogether and switch to nostr?

[shocknet-justin]

Does it mean I can:

1. Run my own LND node locally not connected to public network

Connection to the Nostr relay and the other ancillary stuff like DNS etc is still using your internet IP, so if you want to obfuscate that you'll still need a VPN / reverse SSH etc. What this does help you do is make that obfuscated LND reachable by apps.

2. Run a service locally that listens to NIP-69 events for zaps, talks with my LND node
3. Creates and sends bolt11 invoices over a nostr relay to communicate

Exactly!

So that means, I can have self custody lightning without using tor and a LNURL service, a wallet can pay directly to a NIP-05 address by checking its nip69 field in the content.

But we still need to support Lightning Addresses because it is already popular by so many applications and wallets. So you built a bridge, that when there is a "nip69" field, supported wallets can upgrade the payment to nostr. Unsupported wallets can still pay using lnurl-p but underneath the connection between the LND node happens over nostr.

Yes!

This should be an easy upgrade for any service providing Lightning Addressees to implement in an hour or two, so bullying them may even be easier than setting up a bridgelet.

And I have some questions, too

1. what are the privacy implications over tor connections? Is NIP-44 encryption enough?

NIP-44 was audited and as far as anyone knows is no worse than any other encryption scheme out there, NIP-44 has a versioning so if theres a vuln discovered this NIP would imply the latest version. Tor can be used to obfuscate your IP and has no bearing on this, but there are better options (VPN/SSH) since it's connections are so unreliable. Tor is also honeypot that will just get your connection some extra monitoring by whoever controls your ISP.

2. The bridge itself is still a burden. What is the advantage of using NWC over your bridge?

Could eschew the bridge if legacy Lightning Address isn't a concern, that's baggage for any new protocol. NWC doesn't have a solution for that, its more for app accounts.

NWC does have debits for app connections, but it does so in a unscalable way with bad UX by forcing the user to pre-provision keys (that are re-playable) and fumble them over to every service. That doesn't scale because the service has to fire up a separate listener for each user.

A better debit protocol is coming in a companion NIP to this, just working on the implementation a bit before I ask people to review it.

3. Do you think people stop using LNURL altogether and switch to nostr?

Yes, LNURL is kind of dying already while the benefits of Nostr keep compounding.

[shocknet-justin]

This NIP now has a companion, NIP-68, to allow the inverse operation of ad-hoc debits

#1529

Also a fork of nostr-tools has been provided