𝚗𝚘𝚏𝚏𝚎𝚛: Static, Shareable Lightning Payment Codes𝚗𝚘𝚏𝚏𝚎𝚛: 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.
Check a Lightning Address for CLINKCheck a Lightning Address for CLINK
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 OfferGenerate 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.
Want to make an offer? Try CLINK 𝚗𝚘𝚏𝚏𝚎𝚛 →
𝚗𝚍𝚎𝚋𝚒𝚝: Authorize Payments from Your Wallet𝚗𝚍𝚎𝚋𝚒𝚝: 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.
Pay an Invoice with a CLINK DebitPay an Invoice with a CLINK Debit
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.
Want to request payments? Try CLINK 𝚗𝚍𝚎𝚋𝚒𝚝 →
The demo available at https://clinkme.dev is built with the CLINK SDK, and the source is available on GitHub.
Looking into clink again after a year.
Great project 👌
I am searching for a possibility to pay profiles instead of clunky invoices or scanning or NFC. The users should not know they are using Nostr. They just get a profile, have friends and want to pay OR even request from them.
What are the limitations? Why is there no wider adoption for now? It's seems to good on the first view :D
@justin_shocknet is your man
May need a little more context on your application, but I think I get where you're going and this should be fairly trivial... CLINK is already doing something like this for lightning addresses via NIP-05 instead of LNURL.
The NIP-05 address, or profile in your case, either username@domain or domain/username, returns
clink_offerin the body so that a wallet can pay that on lookup. It'd just be a property of the profile.clink_offercould be added to kind-0 metadata as well and used the same wayclink debits work similarly, its a differentiated offer that sends a request the user has to approve on the wallet, there they can establish auto-approvals/budgets for the requesting key. It's a little more lift on the wallet side but still lighter than NWC and is ideal for user-to-user.
I'm available via telegram or can schedule a zoom if you want to sync on any of it, happy to help.
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:
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?
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.
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?
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