Alby NWC Relay
Alby NWC Relay is the relay layer behind app-to-wallet payment requests: a dedicated NWC transport path for wallet services, with reliability choices and operational limits that normal Nostr timeline relays do not promise.
wss://relay.getalby.com/v1. Alby's docs position it for wallet services that need to send and receive NWC requests reliably, with a dedicated relay to reduce metadata leakage and avoid the fragility of using any random public relay. The service advertises no authentication for getting started, but also public rate limits, query-filter requirements, limited filter and kind counts, RabbitMQ and Kubernetes based scaling, and persisted ephemeral events until consumed for better NWC delivery. The important question is not whether this is NIP-47. The important question is what happens when payment-capability messages depend on relay infrastructure.The relay that should not be read like a timeline relay
Alby NWC Relay is easy to misclassify if you only see the word relay. A normal Nostr relay can store notes, profiles, reactions, articles, lists, relay metadata and whatever other event kinds a client writes to it. Alby's NWC relay is different. The public guide frames it as relay infrastructure for NWC wallet services, not as a place to build a social timeline. Its address, wss://relay.getalby.com/v1, appears in Alby's NWC wallet-service examples because it is meant to carry wallet-connect traffic.
That distinction is why the route belongs under Relays while the Apps hub still links to it. A reader browsing the Apps start page should find Alby NWC Relay because it is one of the 131 ecosystem entries. But the article itself has to teach relay infrastructure: message delivery, filters, metadata, rate limits, partner infrastructure and the operational role between wallet services and apps. Calling it a normal app would hide the thing that matters.
It also should not be dropped into a generic NIP-47 bucket. NIP-47 defines the protocol. Alby NWC Relay is an operated infrastructure surface that wallet-service builders can use while implementing that protocol. The difference matters because the risk moves from specification design to uptime, limits, metadata, partner dependency and whether payment requests arrive when the user expects them to.
What an NWC wallet service actually needs
Alby's NWC Relay guide starts with wallet services. To make a Lightning wallet connectable through NWC, a wallet service has to access wallet transactions and wallet information, create NWC URIs for app connections, and send and receive NWC messages that let connected apps use Lightning capabilities. That is the operational middle layer between a wallet backend and an app that wants to pay, receive, check balance or list transactions.
NIP-47 uses the phrase wallet service for the component that typically runs on an always-on computer and has access to the wallet APIs it serves. That detail is not academic. A mobile wallet may be great for manual payments, but an NWC service often needs to be reachable when a connected app sends a payment request. The wallet service is the listener, policy checker, backend adapter and response publisher.
A wallet service therefore needs a relay path it can trust enough for payment-capability traffic. The relay does not need to know the Lightning backend. It does need to accept the relevant events, deliver requests to the wallet service, deliver responses back to the app, handle notifications and survive real-world abuse pressure. Alby NWC Relay exists because using a random relay for that job is fragile.
NWC makes the relay part of the payment flow
The NWC homepage explains the simple version: once an app connection is created, an app can request payments through a Nostr relay. NIP-47 gives the details. There is an info event, a request event, a response event and a notification event. Requests and responses are encrypted. The relay sees event kinds, tags, timing and routing metadata, but not the decrypted payment command.
In a normal timeline context, relay failure may look like a missing note or delayed profile update. In NWC, relay failure can look like a stuck checkout, a zap that never completes, a subscription that fails to renew, a mobile approval flow that times out, or a user wondering whether an invoice was paid. The transport layer becomes part of the payment UX.
That is why a dedicated NWC relay is a product decision. NWC aims to keep apps from taking custody of user funds. That is good. But it creates a sustained communication path between app and wallet service. The relay does not become a custodian, but it becomes an availability and metadata boundary. Builders have to treat it as infrastructure, not a disposable URL.
Why Alby recommends a dedicated relay
Alby's guide says NWC does not specify requirements on the type of Nostr-compatible relay, but recommends using a dedicated relay because it helps prevent metadata leaks and ensures reliability. That is the core argument for Alby NWC Relay. If a wallet service uses a general public relay with unknown retention behavior, unknown rate limits and lots of unrelated social traffic, payment messages compete with everything else.
The metadata point needs care. NIP-47 encrypts the request and response content, now with NIP-44 as the modern encryption path and NIP-04 as legacy compatibility. Encryption protects the payload. It does not erase all observable structure. A relay can still see that certain pubkeys are communicating, which event kinds are used, when messages are sent, and how often a connection appears active. A dedicated relay reduces the noisy public surface and can be operated around NWC-specific expectations.
Reliability is the other half. NIP-47 itself says that because the protocol uses ephemeral events, clients should pick relays that do not close connections on inactivity and ideally retain events until they are consumed or become stale. Alby's relay guide turns that protocol caution into an operated service claim: enhanced delivery guarantees through persisting ephemeral events until consumed. That is exactly the sort of thing a normal relay may not do for NWC.
The public endpoint and the no-auth starting path
The getting-started path is deliberately low friction. Alby's guide says interested wallet applications can access the relay at wss://relay.getalby.com/v1, and says no authentication is needed so builders can focus on building rather than administrative topics. That is a generous developer experience. A wallet-service team can begin testing NWC relay behavior without negotiating an enterprise contract first.
There are two paths. A builder can use Alby's NWC HTTP API to communicate events over HTTP instead of dealing with websockets, or connect directly to the relay endpoint. This is useful because different teams have different infrastructure. Some are comfortable with WebSocket clients and Nostr event subscriptions. Others want an HTTP wrapper that can fetch NWC info, publish NWC requests or subscribe through webhook callbacks.
No-auth does not mean no-limits. The same page later warns that public unauthorized requests to the main relay are rate limited to avoid abuse, and that Alby reserves the right to change limits to protect the service. That balance is honest. Open access helps developers start. Rate limits keep the shared endpoint from being ruined by broken clients, abusive loops or production workloads pretending to be tests.
RabbitMQ, Kubernetes and persisted ephemeral events
Alby names two infrastructure benefits directly: scalable architecture using RabbitMQ and Kubernetes, and enhanced delivery guarantees by persisting ephemeral events until consumed. Those words should not be treated as decorative DevOps language. They describe why this relay is specialized. NWC traffic is not just publish-and-forget social chatter. It can be request-response traffic where missed delivery changes a payment outcome.
RabbitMQ suggests a message-queue layer behind the relay behavior. Kubernetes suggests horizontal deployment and orchestration rather than a single handmade relay box. The article does not need to invent details Alby has not published, but it should note the intent: the service is built for growing demand and a payment-specific event flow, not merely for storing public notes. When an operator says horizontally scaled relay infrastructure, the reader should think uptime, backpressure, queues, worker behavior and failure modes.
Persisting ephemeral events until consumed is the more Nostr-specific claim. NIP-01 defines ephemeral event kinds as not expected to be stored by relays. NIP-47 then relies on ephemeral-looking request flows but also recommends relay behavior that keeps messages long enough for practical delivery. Alby's relay is explicitly trying to bridge that gap. It respects the NWC use case rather than relying on generic relay storage expectations.
The filter rules reveal the abuse model
Alby's technical requirements say Nostr query filters need an author field, a #p tag or a #e tag. They also limit the number of filters per query and the number of kinds inside filters. Those rules are practical. A relay that lets clients subscribe with huge vague filters can be forced to scan too much, send too much and waste resources on traffic that has nothing to do with a specific NWC connection.
NIP-01 gives the basic relay subscription model: clients send REQ messages with filters, and relays return matching events and new updates. That flexible model is one reason Nostr is simple. It is also why production relays need policy. Alby NWC Relay narrows the allowed filter shape so NWC clients subscribe around known authors, recipient tags or event references instead of asking the relay to act like a broad search engine.
This is another clue that Alby NWC Relay should not be treated as a general social relay. A timeline client often wants broad filters for follows, kinds, since timestamps or search patterns. An NWC relay wants precise traffic between known app and wallet-service identities. Restricting filters is not a weakness in that context. It is how the service stays focused enough to protect payment messaging.
Rate limits are part of the product contract
The rate-limit section is one of the most important parts of the guide. Alby warns that public unauthorized requests to the main relay are subject to rate limiting, and asks developers who encounter rate limits to confirm their client code is not incorrectly sending events too frequently. That sounds mundane until you remember that a bug in an NWC client can create real operational damage.
A broken payment app might retry too aggressively, duplicate subscriptions, republish requests after timeouts, open too many sockets or fail to close old subscriptions. A normal user might only see failed payments. The relay operator sees load, abuse signals and service risk for everyone else. Rate limits are therefore not an arbitrary annoyance. They are part of keeping a shared NWC endpoint alive.
The guide also has a partner path. Wallet-service providers who want to use Alby's relay infrastructure for dedicated services should contact Alby about a dedicated relay service so they avoid rate limits on the open public relay address. This is the grown-up route for production wallets. Test on the open relay. Do not build a serious payment product on a shared no-auth endpoint and then complain when protective limits appear.
How the Alby JS SDK points builders at the relay
The Alby JS SDK wallet-service docs use wss://relay.getalby.com/v1 in the NWCWalletService initialization example. The example then publishes a NIP-47 wallet-service info event, builds a key pair for a client connection and subscribes to requests such as get_info. This is exactly the code-level layer beneath the public Alby NWC Relay guide.
That makes the relationship between entries clear. Alby JS SDK is the developer toolkit. Alby NWC Relay is the transport infrastructure. Alby Hub is a production wallet service. NIP-47 is the protocol. Alby Go and Alby Extension are user-facing interfaces. Treating all of those as one generic Alby item would lose the architecture. Treating them as separate but linked pages gives the reader a working map.
For wallet builders, the SDK plus relay combination lowers the barrier. They can implement NWC request handlers in JavaScript and point the relay layer at Alby's specialized endpoint. The hard parts remain: wallet access, user authorization, method support, budgets, revocation, observability and incident handling. But they no longer have to begin by operating a custom relay before testing the wallet-service concept.
What the relay can and cannot promise
Alby NWC Relay can improve delivery behavior for NWC events, reduce reliance on random public relays and provide an operated endpoint with clear rules. It can carry encrypted request and response traffic, support wallet-service development and offer a path toward dedicated partner infrastructure. That is already valuable. But it cannot make the whole wallet integration safe by itself.
The relay cannot decide whether an app requested too much authority. It cannot make a wallet backend solvent. It cannot fix an NWC secret leaked into logs. It cannot guarantee that a mobile client handles approvals clearly. It cannot turn a custodial wallet into a self-custodial one. It cannot tell the user that an app connection should have expired last month. Those layers live in the wallet service and app product design.
This is why the article should keep returning to boundaries. Alby NWC Relay is transport and infrastructure. NWC is protocol. A wallet service is policy and backend access. A user interface is consent. A good production product needs all four to behave. The relay can be excellent and the integration can still be reckless if app permissions are too broad or wallet operations are opaque.
Metadata risk is smaller than content risk, but not zero
NIP-47's theory of operation says the relay knows kinds and tags but not encrypted payload content. That is a strong design choice. Payment commands such as pay invoice or make invoice should not be readable by the relay operator when encryption is implemented correctly. But readers should not mistake encrypted content for total privacy.
Timing, frequency, pubkey pairs, relay choice, request counts, notification patterns and retry behavior can still reveal patterns. A public shared relay may also make those patterns visible in a wider environment than necessary. Alby's recommendation to use a dedicated relay for NWC therefore has a concrete privacy rationale. It narrows the infrastructure context around payment-capability traffic.
The best production practice is layered. Use unique NWC keys per connection. Avoid reusing the user's main Nostr identity key for payment control. Name connections clearly in the wallet service. Keep budgets small where possible. Rotate and revoke old connections. Avoid broad relay subscriptions. Do not store NWC secrets casually. The relay helps with transport; privacy still depends on the whole connection lifecycle.
How to test without fooling yourself
A developer should not test Alby NWC Relay only by sending one happy-path request. The point of relay infrastructure is what happens when things are slightly wrong. Test connection setup, info-event fetch, request publication, response delivery, notification delivery, revoked connection behavior, wallet-service restart, app retry behavior, duplicate requests, stale events, broad filter rejection and rate-limit responses.
The filter requirements make a useful test checklist. Does your client always include author, #p or #e where required? Does it keep filter count reasonable? Does it subscribe only to event kinds it really needs? Does it close subscriptions? Does it use NIP-44 when available? Does it handle legacy NIP-04 fallback if it must? Does it show understandable errors to the user rather than silently looping?
Then test money behavior with tiny amounts or sandbox wallets. A relay test becomes a wallet test quickly. What happens if the wallet service receives a pay_invoice request after the user has deleted the connection? What if the app sends a request just before expiry? What if a payment succeeds but the response is delayed? What if the app retries and the wallet service sees a duplicate? These are the cases that decide whether NWC feels magical or dangerous.
When to use the public relay and when to ask for more
The public Alby NWC Relay is a strong fit for exploration, prototypes, SDK examples, early wallet-service work and small tests where the developer needs to understand NWC traffic quickly. No-auth access lowers friction. The HTTP API option helps teams that do not want to manage raw WebSocket behavior immediately. The public endpoint is a useful on-ramp.
A production wallet service has a different responsibility. If the product will support real users, significant volume, business-critical payments or a branded wallet experience, the team should treat relay infrastructure as part of the service plan. Alby's guide explicitly points partner wallet service providers toward dedicated relay service. That is the right place to discuss limits, availability, support, abuse handling and operational expectations.
This recommendation is not about gatekeeping. It is about payment infrastructure. A shared public endpoint can be welcoming and still not be the final answer for every production workload. The responsible builder graduates from experiments to explicit infrastructure commitments before users depend on the system.
Where it fits on Crays
On Crays, Alby NWC Relay belongs at /nostr/relays/alby-nwc-relay/. It should appear in the Apps hub because the user wants every ecosystem entry discoverable from /nostr/apps/, but the actual article needs the Relays route context. Readers looking at wallets or developer tools can still arrive through related links to Alby Hub, Alby JS SDK and NIP-47.
This routing also keeps the ecosystem map honest. The map places Alby NWC Relay under Relays, and that is correct. The product is not a wallet, not a signer, not an app UI and not a generic protocol page. It is operated relay infrastructure specialized for NWC wallet-service traffic. That is exactly the kind of nuance the hub needs if it is going to be more than a pasted list of logos.
The final judgment is practical. Alby NWC Relay is important because it turns a protocol assumption into an operated path: apps and wallet services need somewhere reliable to exchange encrypted payment-capability messages. The value is obvious. The risk is also obvious. Payment UX now depends on relay behavior. Builders who use it should respect the limits, watch the metadata boundary, test failure cases and move to dedicated infrastructure when the product outgrows the public endpoint.
Sources worth opening
Use Alby's NWC Relay guide first, then compare NWC, NIP-47, NIP-01 relay behavior, the Alby JS SDK wallet-service docs and the broader relay specifications. This page is about infrastructure, not a generic NWC category.
- Alby NWC Relay guide
- Alby NWC Wallet API overview
- Alby NWC JS SDK guide
- Alby NWC HTTP API guide
- Alby JS SDK NWC wallet-service docs
- getAlby/js-sdk repository
- Alby Developer Guide
- Nostr Wallet Connect site
- NWC documentation
- NIP-47 Nostr Wallet Connect
- NIP-01 basic protocol flow and relay filters
- NIP-11 relay information document
- NIP-42 client authentication to relays
- NIP-44 encrypted payloads
- NIP-66 relay liveness monitoring
- Alby Hub
- Alby Hub user guide
- getAlby/hub repository
- Alby official site
- Alby Help
- Alby Feedback Forum
- Alby NWC Relay endpoint
- RabbitMQ
- Kubernetes
- Nostr protocol site
- Nostr.com overview
