Alby Hub - Android Foreground Service Experiment

• 7 min read
Alby Hub - Android Foreground Service Experiment

Alby Hub pushes the bounds of innovation as an NWC-first bitcoin lightning wallet, leading the way in next-generation payment wallets that connect seamlessly to apps.

Alby Hub Today

Alby Hub currently works on multiple platforms: in the cloud, home servers, desktops and laptops, and even Raspberry PIs and has enabled thousands of users to take the step to run their own lightning node and open their own channels for the first time.

The barrier to entry is lower than before but is not low enough. Alby Hub by default runs an embedded lightning node which requires certain resources. Mobile users can run their Hub using Alby Cloud and install it as a progressive web app on their smartphone which is a great and highly reliable solution, however comes with additional hosting costs. Lightning channels also come with a high up-front cost which sometimes are not very cost-effective for casual users or onboarding users, and this barrier becomes continually higher as the price of bitcoin inevitably rises.

"Nodeless" Options

Rather than end-users running nodes, it is much more effective and user friendly for multiple users to share the same node. Today there are some options being explored by different lightning wallets, each with their own upsides and downsides:

  • Cashu e-cash mints (& Fedimint mints) are great for micro-payments and onboarding new users, with a large list of options at Bitcoin Mints. However, mints are custodial and 100% trusted. There is no guarantee a specific mint will be around a year from now or even tomorrow. It's also difficult for a mint to contact users when the mint plans to shut down, making it likely that some onboarded users will lose funds, and even if they don't, it's a big pain to contact people you have onboarded to ask them to move to a new wallet. Minibits and Cashu.me are Cashu wallets that support NWC.
  • Liquid side-chain submarine swaps allow users to take custody of their own (Liquid) keys, however are slow (a Liquid block must be mined before the swap is confirmed), and have a minimum payment size of 1000 sats, making them unsuitable for micro-payments. Although Liquid federation is still custodial, it is much more likely to be around years from now than any specific Cashu mint that you use today. Flash currently builds a NWC-powered wallet using Breez Liquid swaps.

Upcoming Nodeless Technologies

Ark (Ark Labs, Second) and Spark are very interesting because they aim to allow the user to maintain self-custody* while still providing user-friendly, instant and cost-effective transactions without the user having to run a node. This reduces complexity and makes mobile closer in reach.

Even though these technologies are not quite ready, Alby continues to build, experiment and prepare for the day they are. What would Alby Hub look like when it is not constrained by the requirement to run a node? Could we bring a great user experience by building a version of Alby Hub that runs self-contained, natively on mobile?

*Both Ark and Spark have trust components that must be made aware of - ArkOOR payments must be refreshed before becoming trustless, Spark is currently not trustless. However, it has a lot of power behind it, has fast and cheap transactions with less risk of disappearing tomorrow unlike any Cashu mint you tell me to use today.

A NWC-First Mobile Wallet Service

Alby builds self-sovereign, self-custodial wallets with a focus on enabling seamless lightning integration inside applications. We want to maintain the great experience of Alby Hub while decreasing the barrier to entry for new users. One possible way to do this is to build an application that runs self-contained on a device that almost everyone has - their mobile device. However, because we build more than just a wallet, we must consider how a NWC-first mobile wallet would actually work.

Push Notifications

Alby Go, the simplest mobile NWC wallet interface uses push notification to notify users of sent and received payments. The notifications are sent fully end-to-end encrypted using NIP-44 from Alby Hub, decrypted inside Alby Go, and the content is updated to display the wallet name, and the amount sent or received. "⚡You sent 21 sats". Users can see through push notifications which apps did what in near-real time. For example, I can be notified instantly when one of my ZapPlanner payments goes out.

The same idea could be applied so that Alby Go can handle any kind of NWC request via push notifications. Flash is currently exploring this idea with their new self-custodial wallet, currently powered by Liquid swaps.

Push notifications have some downsides:

  • Visible notifications on iOS: Alby Hub sends notifications for both payments sent and received. Not all NWC communication needs to be shown to the user, but using push notifications each request will result in a visible notification. Alby has requested to hide certain types of notifications but was denied with no explanation.
  • Notification background processing can unexpectedly be killed: there is no guarantee how long a push notification can process in the background before being killed by the OS.
  • Notifications can be dropped: there is no guarantee a certain notification will be delivered, and notifications can be temporarily blocked if too many push notifications are sent.
  • Dependency on Apple / Google push notification services: Even though NWC messages are E2E encrypted and Apple and Google cannot read them, all messages must go through these services and wallet services must rely on them.
  • Non-native NWC integration (Push notifications for receiving rather than websocket connection) means that there are more services involved during the process to send messages - worse performance and less reliability.

Android Foreground Service

Some android apps, such as VPNs (Proton) and privacy-first chat apps (SimpleX) use foreground services to maintain a persistent connection without the need for push notifications. Android users become comfortable with foreground services that provide obvious benefit. This same idea can be applied to a NWC wallet service.

An Android Foreground Service is a more nostr-native approach, allowing a persistent websocket connection without the need for push notification services, and messages simply going from the device, through the nostr relay, to the app, as NWC was originally designed, and the optimal flow. You can read more why the relay is necessary in the NWC documentation.

NWC-First Wallet Service Using Android Foreground Service Experiment

We built an experimental NWC-first app to see how it performs and were surprised how well it works. Just install the app, and you immediately can create app connections and connect to a multitude of apps such as the Alby Browser Extension, Nostr clients, games, and more. You don't need a PC or cloud or home server. Just this Android app which runs a foreground service task.

As you see from the screenshots below, unlike a standard mobile wallet, the app has a clear focus on app connections. The app keeps a persistent connection open to the Alby NWC relay, and uses a Cashu wallet, which works quite well as a placeholder for Spark or Ark.

You can check out the GitHub repository to try it and run yourself. Please do not deposit more than 100 sats as the Cashu wallet is only for testing purposes. Most of the code was written by AI. This is simply an experiment to test a theory, it is not meant as a base to build upon.

One learning is that React Native seems to not be well suited to foreground tasks. It works, but seems to be kind of a hack as the foreground task and main application need to share the same React Javascript context. Extra battery optimization settings had to be set to avoid the app from being suspended, which were not needed by the SimpleX messaging app. If the main app is made inactive, then the foreground task is made inactive too. On the other hand, if both are kept active, the application uses significantly more battery than SimpleX or other foreground services. We rely on a React Native Foreground Service library that has a single maintainer, forked off a fork of an old project, which doesn't seem to be a good base to build from. It's probably best the application be rewritten natively in Android if we decide to pursue this idea further.

Downsides of Foreground Services

Foreground Services require a persistent notification, which is a bit annoying for users and will use more battery due to a persistent relay connection (but in reality it's a very small amount compared to e.g. the screen. In limited testing the foreground service could run for 3 days on a single charge of a cheap Android phone that had its screen off most of the time, Airplane mode on with persistent WI-FI connection). But a bigger problem is that foreground services only work on Android. This is a big downside when trying to build an app for mainstream - is that it should work in both so that you don't have to ask what mobile OS they use before recommending the app to someone.

Next Steps

For now we've proved that it works, and plan to bring it back to life when Ark or Spark work on React Native for another round of testing.

We don't know if we'll take this idea any further, but it was a valuable experiment to make and explore how we could build a NWC Wallet Service that works reliably on mobile.

Building for mobile in general has a lot more complexities than building for 24/7 home servers and cloud environments. By going down this path, users must keep their phone and internet connection turned on (either WI-FI or data) 24/7 to allow for the cool things that are possible with NWC apps that might need to connect to your wallet at any time to function. We're still not sure if building and relying on a mobile wallet service is the right way forward.

Other Ideas

Ark or Spark also enable the possibility of a multi-user cloud wallet service with keys securely stored in a Secure Enclave. This would reduce costs for users but still provide a great 24/7 online service. We haven't experimented much here yet, but is definitely an interesting avenue to explore.

Conclusion

At Alby we continue looking for ways to make it easier for bitcoin to be used as the native open currency of the world. Lightning needs to become 10x easier for developers to decide to adopt this unknown technology and choose to accept bitcoin in their apps. There are obvious challenges but the path to solve them is not always clear. Before we can consider our product landscape we do many experiments like this one to see if the idea is viable or not. We love to hear your feedback as it helps to shape our direction going forward. Would you run Alby Hub as an Android Foreground Service?