CLINK defines Nostr-native standards for Lightning Network interactions, leveraging the protocol's built-in transport, identity, and encryption. This enables secure communication between Lightning nodes, wallets, and applications without traditional web infrastructure dependencies while also remaining web-friendly and facilitating self-custody. This novel use of Nostr delivers a greatly enhanced user experience and unlocks new use-cases versus the status quo of things like LNURL, Bolt12, and NWC.
The primary goal of CLINK is to provide standardized, Nostr-native methods for common Lightning interactions. By building directly on Nostr's capabilities, CLINK enables secure integration between Lightning applications and node services that enhances the user experience without compromising sovereignty.
Current Lightning interaction methods have a number of pitfalls. Some require maintaining traditional web infrastructure, adding undue complexity to self-hosting that results in custodial solutions. Others either introduce friction and security risks through pre-shared secrets, or suffer from dependence on slow and unreliable onion messages that are also impractical for use in web applications. These approaches have created significant barriers to broad adoption.
CLINK leverages Nostr's native strengths to enable direct, identity-driven interactions between Lightning nodes and applications. By building on Nostr's cryptographic primitives, CLINK aims to:
- Simplify User Experience: Enable direct, spontaneous interactions in a way that is compatible with familiar Nostr identifiers (e.g., NIP-05 addresses).
- Reduce Infrastructure Dependency: Operate entirely over the Nostr network where desired, eliminating the need for traditional web infrastructure.
- Enhance Security & Leverage Web-of-Trust: Utilize Nostr's cryptographic identity and signed events for establishing connections and authorizing actions.
- Foster a Native Ecosystem: Provide standardized protocols built for Nostr, enabling tighter integration between Lightning and Nostr-powered applications.
- CLINK Offers: Provides static payment codes (
noffer1...) analogous to LNURL-Pay but entirely Nostr-native. Enables services to offer invoice generation via Nostr direct messages, removing the requirement for a publicly accessible HTTPS endpoint but without unreliable P2P performance. Services like Lightning.Pub can trigger webhooks on offer events, enabling easy integration with traditional application flows while maintaining self-custody. - CLINK Debits: Provides static debit authorization pointers (
ndebit1...) enabling direct, secure payment requests between parties by leveraging key-based identity and event-based authorization flows. This eliminates reliance on custodial APIs or key distribution for debit-style functionality.
While NWC also utilizes Nostr for transport, it specifically targets wallet remote control modeled after the RPC pioneered by Lightning.Pub and ShockWallet to provide a Nostr-tunneled API.
CLINK, conversely, defines interactive protocols using Nostr's wider range of capabilities such as identity and ad-hoc messaging that enable direct application-service and peer-to-peer relationships. This includes:
- Service Interactions: Providing specifications like
CLINK Offersfor invoice requests – functionality not covered by NWC. - Payment Workflows: Defining protocols like
CLINK Debitsfor event-driven payment requests and authorization.
This comprehensive and protocol-based approach facilitates a more integrated architecture for applications communicating directly over Nostr for diverse Lightning tasks. It enables enhanced security models tied to Nostr identity while maintaining compatibility with traditional web application architectures.
Where NWC is deferential to LNURL and scoped for a specific task, CLINK is fundamentally committed to Nostr as the foundation for the next generation of decentralized Lightning applications.
- CLINK Offers: Static payment codes (
noffer1...) for invoice requests - CLINK Debits: Static authorization pointers (
ndebit1...) for payment requests
| kind | description | spec |
|---|---|---|
21001 |
Offer Request/Response | CLINK Offers |
21002 |
Debit Request/Response | CLINK Debits |
| Project | Type | Supports | Features / Notes |
|---|---|---|---|
| Lightning.Pub | Server | Offers, Debits | Reference server for wallets. |
| ShockWallet | Wallet | Offers, Debits | Pay offers and manage your offers and requests via Lightning.Pub. |
| Bridgelet | Bridge | Offers | Simple NIP-05, LNURL and Lightning Address bridge for your custom domain, uses Offers to fetch invoices from your node. |
| CLINK SDK | SDK | Offers, Debits | JS/TS library for CLINK integration. |
| clinkme.dev | Web Demo | Offers | Demo of a static website using CLINK Offers. |
| Your project here | - | - | PR welcome! |
CLINK specifications aim to standardize common Lightning interactions over Nostr. To propose changes or additions:
- Implementation First: New specifications should demonstrate working implementations.
- Backwards Compatible: Changes must not break existing implementations.
- No Redundancy: There should be no more than one way of doing the same thing.
- Nostr Native: Specifications should leverage Nostr's inherent capabilities (identity, events, encryption).
- Discussion: Open an issue to discuss the proposed change/addition
- Implementation: Develop and test the feature
- Documentation: Submit a PR with specification updates
- Review: Community feedback and refinement
- Acceptance: Merge when consensus is reached
All CLINK specifications are public domain.