LN Link
LN Link is not a wallet app by itself. It is the protocol-facing connection layer around LN Node, built on Nostr Wallet Connect and extended for Lnfi's node, liquidity and asset workflows.
What LN Link really is
LN Link is best read as the connection layer around Lnfi Network's LN Node. The official LN Link page says LN Node capabilities are made possible through LN Link, which builds on Nostr Wallet Connect. The LNLink README in the `lnfi-network/ln-node` repository describes a way for clients to access a remote LN Node through a standardized protocol. That is the center of the product: a client wants wallet or node actions, LN Link carries those requests through Nostr-style messaging, and LN Node is the service on the other side.
This distinction keeps the reader out of trouble. LN Link is not a mobile wallet, not a browser extension, not a social client and not the Lightning node itself. It is the protocol-facing bridge that lets another app speak to LN Node. LN Node then brings the larger stack: lnd for Lightning, tapd for Taproot Assets, TAHub as the coordination layer named in the docs, and Nostr for authorization and app communication.
That is why LN Link belongs with protocols. A user does not normally choose LN Link because they want a new interface. They choose it because they have an LN Node connection string or want a client to talk to an LN Node. The practical questions are protocol questions: which event kinds are used, which methods are supported, which fields are standard NWC, which fields are LNLink extensions, which relays are involved, and what the connection is allowed to do.
Why it is NWC-compatible, not just NWC
LN Link deliberately stands close to Nostr Wallet Connect. NIP-47 describes how a client can access a remote Lightning wallet through Nostr relays, encrypted request and response events, and a connection URI beginning with `nostr+walletconnect://`. The NWC docs frame the same idea in user terms: apps can connect to Bitcoin wallets without taking custody of funds. LN Link uses that shape so existing wallet-connected apps can understand the basic contract.
The LNLink README lists the same core NIP-47 event families for the checked implementation: an info event, a request event and a response event. It also lists familiar wallet methods: `get_info`, `get_balance`, `pay_invoice`, `make_invoice`, `list_transactions` and `lookup_invoice`. For many app flows, those names are exactly what a NWC client expects. A client asks what the wallet can do, requests an invoice, pays an invoice or reconciles transaction state.
The word compatible still matters. LN Link is tied to LN Node and Lnfi's broader asset and node model. The API file adds LNLink-specific fields such as `asset_id`, adds an `assets` list to balance responses and exposes `get_assets`. The safe reading is therefore: LN Link can speak the base NWC language where it overlaps, while adding extra Lnfi semantics where LN Node needs them. A generic NWC client may handle the overlap and ignore or fail on the extra behavior.
The LN Node side of the bridge
LN Link cannot be evaluated without LN Node. Lnfi describes LN Node as a self-custodial, open-source Lightning node product that connects to other apps and supports Bitcoin, Taproot Assets and RGB asset workflows. The GitHub README says LN Node is empowered by Nostr and meant to simplify setup and management of a Lightning node. The repository itself is small, MIT licensed and was last pushed in February 2025 when checked through the GitHub API.
The custody claim is important. The LN Node README says users hold the LND seed and interact with the node through actions signed with a Nostr private key. That means LN Link is not merely moving harmless status messages. It can be the app-facing control path to a node that may hold channel state, wallet state, asset state and delegated app permissions. A connection string becomes operationally serious because it can ask a node service to act.
The LN Node documentation also names tapd and TAHub, which is why LN Link goes beyond a plain BTC invoice surface. Taproot Assets support, RGB management, Zapper accounts and Channel Mining all sit near the same product family. Even if a reader only wants ordinary Lightning zaps, the surrounding platform is broader. The correct response is not fear, but precision: know which part you are using and which parts your client can actually invoke.
How the connection string works
The LNLink API file follows the NWC connection model. A wallet service generates a `nostr+walletconnect://` URI. The base path identifies the wallet service public key, and query parameters include relay URLs and a secret. A client obtains that URI through a QR code, deeplink or paste action, stores it and then uses it when it needs wallet actions. This is convenient because a Nostr app does not need direct access to node admin credentials.
The relay parameter is not a decorative field. It tells the client where the wallet service is listening for events. If the relay is slow, blocked, prunes unexpectedly or drops idle connections, requests may fail even when LN Node is healthy. The NIP-47 document explicitly warns that relays used for ephemeral wallet events should not close connections on inactivity in ways that drop events. For LN Link, relay choice is part of reliability.
The secret is also not an ordinary login token that can be pasted everywhere forever. It is the client-side capability for this wallet connection. NIP-47 emphasizes that users can create different keys for different applications, revoke them and apply constraints such as budgets. LN Link should be used the same way. Create a connection for one client, test it, keep its spending ability narrow, and revoke it when the app or device is no longer trusted.
The core event and method set
The minimum useful LN Link reading starts with event kinds. The LNLink README lists NIP-47 info event kind 13194, request kind 23194 and response kind 23195. NIP-47 also documents wallet notifications, including notification events, but the checked LNLink README focuses on the three listed event types. That tells app builders what to test first: capability discovery, request creation and response handling.
The current supported method list in the README is practical rather than huge. `get_info` tells the client what the wallet service is and what it supports. `get_balance` exposes balance state. `pay_invoice` asks the node to pay a BOLT11 invoice. `make_invoice` asks for a new invoice. `list_transactions` and `lookup_invoice` let a client reconcile history and invoice status. That set is enough for many wallet-connected apps, point-of-sale screens, zap clients and dashboards.
The same README names two limitations that readers should not skip. Amount is not supported for amountless invoices in `pay_invoice`, and the `PAYMENT_FAILED` error code is marked as unsupported there. The separate API file includes a larger NWC-like error and method surface, so developers should test the running LN Link implementation they are actually using. Documentation files can describe direction, but production safety comes from checking the specific client, specific wallet service and specific invoice cases.
The Taproot Assets extension
The most distinctive LN Link feature is the `asset_id` thread running through the API file. In `pay_invoice`, `make_invoice`, `lookup_invoice`, `list_transactions` and transaction or notification objects, the file marks `asset_id` as an LNLink feature. Balance responses can also include an `assets` array, and `get_assets` is listed as an LNLink-specific method. That is the real reason LN Link should not be flattened into ordinary NWC.
This extension matches the LN Node product story. Lnfi's LN Node page says tapd implements Taproot Assets, while the Taproot Assets node-management guide describes deposits, channel creation, channel deposits, withdrawals and asset-specific invoice prefixes. If LN Node is meant to handle BTC and assets, the connection layer needs a way to describe which asset a request or response refers to. `asset_id` is that hint in the public API file.
For app builders, this is powerful and hazardous. A client that only understands BTC Lightning invoices should not pretend to understand Taproot Asset payments. A UI that shows a generic balance should not merge satoshi balance and asset balances into one vague number. A failed asset request should not be displayed like a normal route failure if the asset was unsupported. LN Link gives the protocol room to express assets; the client still has to present that room honestly.
What the Alby flow proves
The official LN Link page gives a concrete user flow through Alby. The user opens LN Node, generates an NWC string, copies it, opens the Alby Chrome Extension, chooses to connect a wallet, selects Nostr Wallet Connect, pastes the string and finishes the connection. When successful, the Alby screen displays success and the sats on the LN Node.
That flow proves three useful things. First, LN Link is meant to leave the Lnfi interface and connect to real app surfaces. Second, the generated string uses the same mental model as other NWC wallets. Third, the user experience depends on both sides supporting the same expectations. LN Node can generate the connection, but the client still has to parse, store and use it safely.
It also exposes the user risk. A browser extension or app that receives the connection string can request the methods that the connection allows. If the string is broad, copied into too many places or stored on an untrusted device, the risk follows it. The right Alby-style setup is a fresh connection with a clear label, small budget, limited methods where supported and a known revoke path in LN Node.
Where LN Link differs from normal wallet UX
A normal wallet interface usually hides the node. LN Link sits near a product that exposes the node as a managed object. LN Node talks about enabling nodes, managing Taproot Assets and RGB nodes, creating channels, providing liquidity and connecting to apps. The user is closer to a node operator than a simple wallet holder, even if the interface tries to make the work approachable.
Channel Mining is the clearest example of this difference. The Lnfi docs describe rewards for providing liquidity through a channel, list current channel-capacity boundaries and discuss reward tokens. Whether or not a reader ever uses Channel Mining, its existence tells you what kind of system LN Link belongs to. This is not only a zap bridge; it is part of a LightningFi node environment with channels, incentives and terms.
That makes the testing burden higher. A wallet that only sends small zaps needs invoice tests and spending limits. An LN Link setup may also need asset tests, channel state checks, node uptime checks, seed recovery, relay behavior, account delegation review and terms review. The connection may feel like one QR code, but the responsibility behind that QR code is wider.
Security boundaries to name before use
The first boundary is key custody. Lnfi's terms say users are responsible for credentials and backups, including Nostr keys and seed phrases, and disclaim liability for losses from mismanagement. The broader LN Node wording says users hold the LND seed. That puts recovery, storage and leak prevention on the user. If the seed, Nostr key or app connection is lost or exposed, protocol elegance will not save the funds.
The second boundary is relay and metadata exposure. NIP-47 requests and responses are encrypted, but relays still see event kinds, timing and tags. The NIP recommends avoiding the user's main identity key for wallet activity and using unique keys per connection. LN Link should be operated with that privacy model in mind. Do not attach a broad wallet-control connection to a public identity unless you have a reason.
The third boundary is client honesty. A client should surface method support, budgets, asset names, asset identifiers, invoice amount expectations, failures and revocation clearly. If a client hides that an LN Link connection has asset capabilities or broad balance visibility, the user cannot make a good decision. Protocol support is not only whether a JSON request works; it is whether the human can understand the permission.
How to test an LN Link connection
Start with capability discovery. Generate a fresh LN Link or NWC string from LN Node, connect one client and call `get_info`. Confirm the method list. If the client expects `pay_invoice`, `make_invoice`, `lookup_invoice` or `list_transactions`, verify that those methods appear and behave as expected. If the client claims asset support, confirm whether `get_assets` or asset-aware responses are present.
Then test tiny money movement. Create a small invoice from the client, pay it from a separate wallet and verify `lookup_invoice` and transaction listing. Pay a small invoice through `pay_invoice`. Try an amountless invoice only if the client claims support, and remember that the LNLink README warns about amount handling for amountless invoices. Test a failure path too: insufficient balance, expired invoice or unsupported method.
Finally test lifecycle behavior. Reboot or stop the node if your setup allows safe testing, confirm whether the client reports failures clearly, then revoke the connection and confirm that requests stop working. If a relay is changed or unavailable, test the error path. If assets are involved, run separate asset-specific tests with tiny values and clear labels. A connection that cannot be revoked or tested is not ready for meaningful funds.
What developers should check
Developers should treat LN Link as NWC plus explicit extension handling. Use NIP-47 as the base for connection URI parsing, event kinds, request and response shapes, encryption expectations and wallet notifications. Then layer the LNLink API file on top. The moment your code sees `asset_id`, `assets`, `get_assets` or `is_lnlink`, it should move from generic NWC assumptions into LNLink-aware UI and validation.
Error handling needs special care. The API file lists familiar NWC errors such as rate limiting, unknown or intentionally unimplemented commands, insufficient balance, quota exceeded, restricted access, unauthorized access, internal errors and other failures. But the README also warns that a particular error code may not be supported in the current method list. Do not build a client that depends on one perfect error path. Show recoverable messages and log enough context for users to debug safely.
Data model choices matter too. Store the connection string as a secret. Do not put it in analytics, crash reports or public logs. Separate connection labels from the user's main Nostr identity. Avoid showing asset IDs without human-readable names when possible, but never hide the ID entirely for asset operations. If the client supports multiple NWC wallets, identify LN Link connections clearly so users do not confuse a simple Lightning wallet with an asset-capable node.
What ordinary users should check
Users should begin by deciding whether they actually want LN Node. If the goal is one low-value zap wallet, LN Link may be more system than needed. If the goal is to connect a self-custodial LN Node to apps, explore Taproot Assets or test Nostr-based wallet control, LN Link is relevant. The protocol is interesting because the node behind it is interesting.
Before putting meaningful value behind a connection, write down the recovery path. Where is the LND seed? Where is the Nostr key used for authorization? What happens if the device with the client is lost? How do you revoke one app connection without damaging the whole node? Which relay does the connection use? Which methods and budgets are allowed? These questions sound tedious until something breaks.
Use the Alby-style flow conservatively. Generate one string, paste it into one client, pay and receive tiny amounts, then revoke it and generate a fresh one when the real setup is ready. Do not reuse a powerful connection across multiple apps just because copying a URI is easy. LN Link gives a client a path to a node. Treat that path like a spending and visibility boundary.
The current public footprint
The public LN Link footprint is compact. The official product documentation lives under the LN Node section of the Lnfi GitBook. The GitHub implementation reference lives in `lnfi-network/ln-node`, especially `LNLink/README.md` and `LNLink/APIS.md`. The repository metadata checked on June 13, 2026 showed a small MIT-licensed public repository with the default branch `main`, six stars, no forks, no open issues and a last push on February 4, 2025.
Small public footprint does not automatically mean weak technology, but it does change the review posture. LN Link is not like NIP-47 itself, which is a broad ecosystem specification with many implementations and current documentation. LN Link is a specific Lnfi/LN Node connection layer. If you build on it, check the current docs and repository, not only ecosystem lists. If the running service differs from the public files, trust the tested behavior over assumptions.
The docs themselves contain a useful warning: the official LN Link page says it is still under development and that more functionality will be added in the future. A reader should take that seriously. A developing protocol layer can be useful today and still require careful version checks tomorrow. Build small, test often, and expect the asset and node-management parts to evolve.
The bottom line
LN Link is one of the more interesting NWC-adjacent protocol paths because it shows how wallet connections can move beyond simple Bitcoin invoices. It keeps the recognizable NIP-47 shape: connection URI, relays, client requests, wallet-service responses and familiar wallet methods. Then it points that shape at LN Node, where lnd, tapd, Nostr authorization and asset-aware workflows live together.
That ambition is exactly why the reader should be careful. If you only need a wallet to zap posts, a simpler NWC wallet may be easier to reason about. If you want an app connection to a self-custodial Lightning node with asset-aware extensions, LN Link is worth understanding. The value is not that it hides complexity. The value is that it makes a complex node reachable through a protocol pattern other apps can learn.
Use LN Link with the same discipline you would use for any app-controlled money system: one connection per app, low limits, clear method support, small test payments, asset-specific labels, reliable relays, documented recovery, and a real revoke path. When those pieces are in place, LN Link can be a useful bridge between Nostr apps and Lnfi's node environment. Without them, it is just a powerful connection string moving through a convenient UI.
Sources worth opening
Open the official LN Link page, LNLink README and LNLink API file first. Then read the LN Node product page, user guide, Channel Mining, Taproot Assets, Zapper Accounts, terms, NIP-47 and current NWC docs. LN Link makes sense only when you see both sides: the base NWC protocol and the Lnfi-specific node and asset layer.
- Lnfi LN Link documentation
- LNLink README raw file
- LNLink API raw file
- LNLink README on GitHub
- LNLink API on GitHub
- Lnfi LN Node product page
- LN Node user guide
- LN Node enable nodes guide
- LN Node Taproot Assets node management
- LN Node RGB node management
- LN Node Zapper Accounts
- LN Node Channel Mining
- Lnfi terms including LN Node annex
- lnfi-network/ln-node repository
- LN Node README raw file
- LN Node MIT license
- LN Node GitHub API metadata
- LN Node GitHub commits
- NIP-47 Nostr Wallet Connect
- NIP-47 GitHub source
- Nostr Wallet Connect official site
- NWC documentation home
- NWC wallet getting started guide
- NWC app getting started guide
- Alby app connections via NWC
- getAlby awesome-nwc list
- Lightning Labs lnd
- Lightning Labs Taproot Assets
- Taproot Assets documentation
- RGB protocol project
- Old MicroNode early access page
- Old MicroNode user guide
- Old MicroNode disclaimer
