pull down to refresh

𝚗𝚘𝚏𝚏𝚎𝚛: Static, Shareable Lightning Payment Codes

CLINK (Common Lightning Interactions with Nostr Keys) provides standardized, Nostr-native methods for connecting Lightning Nodes to the Web and Applications. It uses Nostr's built-in transport, identity, and encryption to let Lightning apps and nodes talk to each other securely from anywhere.
This approach avoids the reliance on traditional web servers or slow and unreliable P2P onion messages, offering broader applicability and enhanced usability over alternatives like LNURL or Bolt12.
An noffer is a static, shareable code that allows anyone to request an invoice from your Lightning node over Nostr.
Enter a Lightning Address (NIP-05 identifier like alice@example.com). The demo will fetch the NIP-05 record and report whether it advertises a clink_offer.

Generate a Lightning Invoice from an Offer

Paste a noffer string to request a BOLT 11 invoice from a provider. This demonstrates how a client (like a website or mobile app) can ask a server (like your node) for an invoice in a standardized way.

𝚗𝚍𝚎𝚋𝚒𝚝: Authorize Payments from Your Wallet

CLINK provides standardized, Nostr-native methods for common Lightning interactions. It uses Nostr's built-in transport, identity, and encryption to let Lightning apps and nodes talk to each other securely.
This approach avoids the reliance on traditional web servers, offering a greatly enhanced user experience over alternatives like LNURL or NWC.
An ndebit is a static, shareable code that grants permission for another party to request payments from your Lightning node over Nostr.
Paste an ndebit string and a BOLT 11 invoice to authorize a payment from a provider. This demonstrates how a client can request a payment from a server that has been granted permission.
You can get an ndebit from a CLINK-compatible wallet like ShockWallet to try this feature.

The demo available at https://clinkme.dev is built with the CLINK SDK, and the source is available on GitHub.
yo!
I'm actually working on materials for this a bit today, any requests for what more should be in the demo/readme/future videos or otherwise I'd appreciate
First I need to stick this somewhere:
reply
Great stuff! I could not wait more to share it... Looking forward to learning more! So is using nostr only to broadcast the payments? or is will also store the payments with can't-remember-which-NIP-00?
Are offer intended like in the BOLT12 implementation? or it needs BOLT12 to be implemented to work?
Would this enable recurring subscriptions over lighting?
reply
All the events for methods are ephemeral, its like an RPC to simply transport the invoices. Relays that don't offer storage are therefore viable.
(Offer based Lightning addresses are still subject to NIP-05 stored events though)
Yes the offers spec provides an alternative to Bolt12 for use-cases where a static QR code or string is desired, but this is more useful since it's trivially used on the web and Nostr is actually reliable. There's no dependence on Bolt12 at all, in fact, I hate Bolt12 :)
Yes this was designed with subscriptions in mind (push payments), hense the pricing types encoded into the offer which allow for pricing to change over time for scheduled payments. I'll eventually demo the tooling we're building into the wallet and wallet server for this.
The debit side of the spec facilitates a service requesting a payment (pull payments) and give the user one-click ruleset approval.
reply
This is great! Look forward for it, pink me in case you need some tester! Or there's something in GH i can already play with?
reply
It's already live in Lightning Pub and ShockWallet, but in a mostly POC state as real users haven't battle-tested it, just internal tinkering.
Feel free to play with it, any and all feedback helps with direction.
The SDK should make it easy enough to make an app that uses it, dev feedback on that would be extremely valuable as well.
The source for the demo is on gh too: https://github.com/shocknet/clink-demo
reply