Modularizing Alby Hub: User-Hosted Serverless Signers

In our previous article, Modularizing Alby Hub we covered how Alby Hub could be split into 3 components, allowing different types of lightweight wallets (“signers”) to be built, while the management UI and multi-user NWC wallet service can be reused across signers and developed independently. One of the signer implementations this has enabled is a suspendable hosted signer, which can significantly reduce costs and possibly enable a free tier of hosted wallets, while still giving almost all of the benefits of an always-online wallet such as users of Alby Hub experience today.

Challenges with Suspendable Signers

We built both a few experimental implementations of a suspendable signer, and by digging deeper we identified some additional challenges:

1. Hosting costs: Although hosting costs are much lower compared to running an always-online application, there is still a fixed cost per-user for suspended applications, to pay for the storage of the application’s memory while it is suspended.This adds up at scale, and we need to ensure we can provide a free tier that is sustainable.

2. Hosting ownership: Alby Cloud service provides a convenient hosting option for users who don’t wish to host their own Alby Hub. However, to reduce trust in Alby, we would much prefer users to deploy and own the code of their running wallet. Suspendable wallet infrastructure providers (AWS, GCP, Azure, Fly.io etc) all require credit cards to sign up, increasing the barrier for users to run these suspendable signers from their own accounts.

3. Unlock mechanism: if the suspended machine is rebooted (for any infrastructure-related reason), the user must enter their unlock password to regain access to their wallet. Our learnings from Alby Hub have shown that this can lead to a poor experience for some users. The unlock mechanism is a hard requirement with Alby Cloud to ensure we have no way to access our users’ funds.

What If The End User Owns And Runs the Code?

Our goal is that Alby users own and run their own wallet code. Alby users are self-sovereign, running their own self-custodial wallet, from code they have deployed themselves on a server we don’t control.

There are a number of serverless platforms today that users can sign up for free without providing any credit card information: Cloudflare Workers, Google Apps Script, Vercel, Netlify, Deno Deploy. Because of the low resource requirements of Spark and Ark signers, they are possible to host within free tier limits.

Description: Proof of concept of an Arkade signer app running in Google Apps Script

Serverless Performance Concerns

On serverless platforms, every request to the wallet triggers a cold start, which means the wallet has to be initialized before it can respond to the request. The wallet must be optimized to avoid any unnecessary external requests that can slow down the boot-up process, and any possible caching must be applied. From an experiment running Arkade wallet inside Google Apps Script, it’s possible to process wallet requests through NWC in less than 5 seconds without too much effort. which is quite acceptable given the benefit of having an always-accessible wallet (compared to a mobile wallet for example, which could have no signal, or run out of battery, etc. This is important as it enables automation via NWC).

Offline Receive

Serverless signers experience the same issue as suspendable ones: within a few minutes the wallet becomes inaccessible. 

Spark has no issues with offline receive, as the payments are received by the Spark Service Provider and later claimed by the user when they come online.

Ark wallets however have to be able to be online to claim an incoming payment. Arkade swaps are powered by Boltz swap, which can be subscribed to by an always-online third-party and can trigger the user’s signer to be woken up when the swap is ready to claim. Something similar should also be possible with Bark.

Replacing The Unlock Mechanism

The user’s wallet still should not be stored in plaintext on the hosting platform (Google, Cloudflare etc) as there is a risk, even if small, that an employee of one of these hosting platforms can access user application data. Therefore, at rest the user’s wallet must be encrypted. The Alby Hub unlock mechanism no longer works for serverless setups, since it relies on keeping the wallet decrypted in memory. With serverless, each request is a cold boot. Possibly our idea from the first part in this series to encrypt keys using a secret only the user’s NWC client knows, which enables the wallet to be encrypted at rest and only accessible at request time.

User-Friendly Onboarding and Deployments

One immediate challenge is that Alby users need two different accounts:

1. The Alby Account: provides users with a lightning address, wallet notifications, encrypted backups, and more.

2. The Hosting Account: where the user deploys their wallet code

If the user doesn’t have a hosting account yet, they need to sign up as part of the onboarding, which is a point of friction.

Next, we need a user-friendly way to deploy code on the user’s behalf. More tech-savvy users can deploy the code themselves, but for the everyday user it’s best the code can be deployed with a single click of a button.

This is possible through the OAuth APIs supported by some of the mentioned providers, allowing the user to give Alby authorization for a short amount of time to deploy or update the user’s wallet. It’s important we only have temporary deployment access so that users stay in control of what code is running their wallet.

Do you have ideas to overcome the mentioned onboarding and deployment challenges?