Modularizing Alby Hub

Alby Hub is a self-sovereign lightning wallet optimized to be connected directly to apps through the power of Nostr Wallet Connect (NWC). Currently Alby Hub is powered by a full lightning node with 1-click channel management. Alby Hub works great for self-hosters and more active bitcoin users who appreciate being in control of their bitcoin and their transaction fees in combination with the convenience of the Alby Cloud hosting service.

With new Layer-Twos such as Spark and Ark, we aim to bring the amazing experience of Alby Hub to more casual, less technical and beginner users. We think it is important to lower the barrier of entry to access great self-custodial NWC wallets, which will help the bitcoin app ecosystem continue to grow.

Recently we wrote about a Trust-Minimized Multi-user NWC Wallet With Ark & Spark, while it is an interesting approach to providing a scalable and user-friendly always-online NWC wallet, it comes with some difficult regulatory challenges and trust assumptions.

Today we explore an alternative approach that is more inline with Alby Hub. Each user hosts their own wallet and therefore stays in full control, but with a key difference: the wallet is cut down to the absolute minimum. Everything else is extracted, run and maintained separately. You might wonder why this seemingly small change makes a big difference? Continue reading to find out!

The Composition of Alby Hub

Alby Hub today is made of three main components:

• Lightning node (embedded LDK node or remote LND connection): enables receiving and making lightning payments self-custodially.

• NWC wallet service: enables Alby Hub to be connected seamlessly to other apps through secure, permissioned, end-to-end encrypted communication over a Nostr relay.

• Management UI: enables users to manage their lightning node, payments and connected apps.

Alby Hub: The Truly Open, Always-Online Lightning Wallet

Alby Hub runs as a NWC wallet service which means it requires a persistent connection to the NWC relay to be able to process wallet requests to send and receive payments. Alby Hub also runs a full lightning node that must be online to receive payments. Unlike other self-custodial wallets like Phoenix or Lexe, Alby Hub also allows users to connect to any node on the lightning network. Users can buy channels from multiple different LSPs, with guarantees that their channels will stay open based on the terms of the channel purchase. Alby Hub users can also open outbound channels to any lightning node. However, it’s much more likely for channels to be closed if a user does not keep a high uptime. For these reasons, we highly recommend users to run Alby Hub on an always-online self-hosted server (Like Umbrel or Start9) or use the Alby Cloud hosting service.

The Cost of Always Being Online

Alby Hub must be hosted on an always-online machine which has ongoing costs. The cost is fixed, no matter how often Alby Hub is used or, inversely, how much time Alby Hub is sitting idle. Because under the hood Alby Hub runs a full LDK lightning node, Alby Cloud machines require continual CPU usage and consume on average 300-400MB of memory at all times. This means at scale it is not economical for Alby Cloud hosting to be provided as a free service for casual and beginner users where we have no guarantee they will generate any revenue to cover the cost for providing the infrastructure.

A Suspendable Layer-Two Hosted Wallet

What if the wallet is only running when the user is actively using it? This model has been proven by Greenlight and more recently Money Dev Kit, which both launch a full lightning node to fulfill requests, and then shut it down again. If a user only used their wallet for a total of 10 minutes per day, then suspending the wallet would reduce computing costs by over 100x.

With new Layer-Two solutions we can take this one step further: rather than launching a full lightning node, we launch only a “signer” which is the most cut-down, lightweight user-controlled lightning wallet.

The Spark or Ark service providers run the actual lightning node and do most of the heavy lifting, and the signer which, exclusively controlled by the user, creates signed wallet requests to the service provider.

Extracting The NWC Wallet Service

In order for this wallet to be suspendable, it can no longer have a persistent websocket connection and directly process NWC requests. Instead, the wallet has a simple HTTP interface to handle requests, which allows cloud infrastructure platforms to easily handle auto-suspension and resumption of machines based on whether or not there have been any recent HTTP requests.

We bring the multi-user wallet service idea from our previous article but with an adjustment: that the multi-user wallet service becomes a simple service that just facilitates NWC requests, very similar to how NWC relays work today. Signed, E2E-encrypted NWC requests from the user’s NWC clients will be sent through the relay and multi-user wallet service to a particular signer, which can verify the request truly came from the user (because the NWC request is signed and encrypted by the user’s client) and then process it by signing requests using the user’s wallet key.

You might notice: a downside here is that the signer will not work so well on self-hosted always-online machines. NWC solves the self-hosting problem by giving a secure, end-to-end persistent connection from the user’s node to the outside world, without having to open a clearnet tunnel to their machine or use TOR. This is a trade-off we are considering because it enables wallets to be cloud hosted very cheaply at scale.

Extracting The Management UI

The management interface could live in the signer, but by extracting it we remove one part of the signer that requires a lot of continual iteration and experimentation. A learning from Alby Hub is that users do not often update and often it takes months to roll out new versions.

Note: the Management Interface needs a trusted connection to the signer because it allows the creation of new apps which can spend money from the wallet. This could be a website that only keeps the signer access token clientside, or it could be a user-owned product like Alby Go or the Alby Extension.

So What Does The Signer Look Like?

At its core the signer is a basic wallet backend with simple functions like retrieving the balance and transaction list, making and paying invoices. This could be Spark, Arkade or Bark, or another layer 2. The great thing about decoupling the signer is that multiple signers can be built with different wallet backends.

The other important part of the signer is the registration of NWC connections. This allows users to give apps permissioned access to their wallet. Each app request to the signer is E2E-encrypted from the app itself and only decrypted by the signer - maintaining the user’s privacy and control over their wallet.

By removing all these parts the signer consumes much less resources and ideally rarely has to be updated. The management interface and NWC wallet service can be constantly iterated on, allowing Alby to incorporate user feedback faster.

Why Can’t The Signer Truly Be “Just a signer”?

Alby believes in the importance of self-sovereign, open wallets. By creating a signer that simply has a key and blindly signs user’s requests, we would likely have to create very implementation-specific code (for example for Spark we would need to implement a FROST signer), meaning we would be more locked into a particular Layer-Two implementation, which limits experimentation and future development based on this architecture.

Another reason for this is the signer needs to know what payments were actually made by the wallet in order to be able to enable NWC connections with budgets. This is important so that users stay in control by giving apps limited access to their wallet.

Future Possibilities

By decoupling the signer we have interesting future possibilities, such as a mobile wallet signer powered by push notifications, or a signer running inside a TEE to address the regulatory challenges outlined in the previous article.

Why not just add Spark/Ark directly to Alby Hub?

We are also looking into this ;-)

Why Not Make Alby Hub Suspendable?

Alby Hub is designed to be a self-contained, full NWC wallet service for a full lightning node. To make Alby Hub suspendable we’d need to switch the main backend to be one of the new Layer-Two options, and either support an optional HTTP layer for accepting NWC requests rather than running a full NWC service (which creates more complexity by having to support both NWC modes), or by having a separate wake-up mechanism when events from one of the hub’s apps come in (which is overcomplicated and likely a lot less performant than exposing a simple HTTP API).

Even if we did make the above changes, we have to consider whether Alby Hub is the correct architecture for these new Layer-Two wallets, and also whether the correct user experience still matches the needs of more casual and beginner users - maybe these types of users don’t need all the features of Alby Hub. We are also possibly limited on how simple an onboarding can be, compared to what is possible with this modular approach where some parts of the UI could be more hidden away.

With the Introduction of Simple Layer-Two Wallets, is NWC still needed?

NWC as a common protocol for connecting apps to wallets is necessary. Spark, Ark, or Cashu enable developers to create basic wallets within their apps, but building a great wallet is complex if you take into account security and regulatory considerations. NWC means app developers don’t need to care about this - they only need to know that the user has a wallet - and the easier it is for a user to get one, the more confident the developer can be. Thus, they can fully focus on building the best app UX.

Conclusion

By creating a lightweight suspendable signer it is viable to provide cloud-hosted wallets with a free tier. This means users can get quickly onboarded to a free, simple, no-KYC, self-custodial, hosted NWC-powered wallet. As NWC wallets become more accessible, more developers will choose NWC to power their apps.

What do you think about this idea?