Lightning is poised to seamlessly integrate into our everyday operations much in the same way the internet has.
Every time you google something, every time you goof off do serious research on YouTube or Instagram, every time you order an Uber, every time you check your portfolio or read the news, you’re using the web. As a matter of fact, you’re using the web right now reading this. The web is a tool, but it’s a tool in the same way that lungs or thumbs are tools; it’s become an integral part of us that we use constantly without even thinking about it.
Money is similar in that we use it constantly and unconsciously. As long as your refrigerator is running, as long as your funds are accruing interest somewhere, as long as the debt clock on your loan is ticking, you’re involved in financial activity. Your financial self is awake, maintaining its position in the global network of value, even as you sleep.
Bitcoiners tend to be acutely aware of this sort of thing. If you use Lightning, you probably see it as a conduit between you and that global network of value. It’s not just a way to buy a beer in Helsinki; Lightning connects you to the sea of Bitcoin.
Weirdly, these two vital networks — the web and Lightning — still operate in parallel with little integration. We don’t want to live without either one, but the seams between them are palpable, sometimes awkward.
As I learned at the bolt.fun hackathon (shoutout to my man Johns!), many web developers would love to build apps with Lightning functionality. The will to integrate is out there, but many seem not to realize that there’s a way, too. In fact, there are several ways to bring Lightning to the web and each is evolving with its own strengths and use cases. Maybe the world just doesn’t know about or understand them?
So let’s do it. Let’s look at how to integrate the web and Lightning, drawing the strands out, weaving them together and making a stronger, combined, seamless net.
LNURL: Keeping It Simple
The Lightning user experience (UX) has come a long way since I first covered it three years ago. But gaps remain. Invoices are one example. Technically, only the payee can initiate a payment, which is inappropriate for many contexts. Many users might not want to generate an invoice for whatever reason and, in scenarios like tipping, it might reasonably come across as cumbersome and rude.
LNURL is a very simple set of specs to bridge some of these remaining UX gaps, including invoice generation. The beauty of LNURL is its simplicity. As the name suggests, LNURL specs are based on links, either in the form of clickable URLs or scannable QR codes. URL links are part of our technological background. You’ve already seen four in this post, probably without even noticing them. QR codes are the same thing, just a different visual representation:
There are several LNURL specs out there, but these are especially relevant to Lightning’s web integration:
- LNURL-Pay: Let’s say you run a Bitcoin blog. You want to collect tips but you don’t want to generate and render an invoice for every tip, nor do you want to interact with each reader individually for each tip. LNURL-Pay lets you generate QR codes for payments within a specified range, say, 2,500 – 10,000 sats. A user can simply scan a code, enter the precise amount and pay. The user remains oblivious to the language of pre-images and invoices, instead just scanning a code and responding to a prompt.
- LNURL-Withdraw: This is the reverse scenario: you want to pay users for interacting with your site, but you want to spare them the trouble of generating an invoice. LNURL-Withdraw lets users scan a code or click a link that will prompt their wallets to generate the appropriate kind of invoice and send it to your node for payment.
- LNURL-Auth is another cool LNURL tool. It generates a public-private key set based on the seed phrases in users’ wallets to let them sign in to websites pseudonymously. It’s as private as the seed phrase itself and harder to brute force than “password123” or “correct_horse_battery_staple.” Best of all, it uses data already contained in the users’ wallets, ready to use with little input.
Lightning Addresses
Email is perhaps so familiar that we take its advantages for granted. Email addresses are strictly unique (unlike fingerprints), and email makes sending and receiving information to exactly the right person extremely easy. Lightning Addresses have the same [email protected] format as email, but they allow users to transfer funds without having to mess with a QR code.
Currently, LNURL-Pay is the most popular means of implementing Lightning Addresses but the Lightning Address protocol is open to innovation. For example, Lightning addresses can be extended to use static invoices or BOLT12 (Basis of Lightning Technology; the Lightning equivalent of the Bitcoin Improvement Proposal [BIP] specifications), once these are adopted.
Even in its current form based on LNURL, Lightning Addresses are very popular and easy to integrate. Indeed, several apps include Lightning addresses natively, but there are also non-custodial bridge servers available for those with their own nodes who don’t mind a little configuration and there are instructions for a fully self-hosted setup with your own domain name.
In order to really make Lightning Addresses a success, we need to figure out how to enable non-custodial mobile wallets to receive while offline.
WebLN
WebLN starts from a simple premise: most of the time when we interact with the web, we do so through a web browser. Web browsers are practically little operating systems in their own right, able to run all sorts of cool software in their own environments.
Given that Lightning is just software and that we want to integrate it with the web, adding Lightning to web browsers will go a long way.
This is precisely the idea behind WebLN, which is a simple JavaScript tool to build Lightning-enabled browser extensions using makePayment and sendInvoice — again, the two core functions for any kind of money: sending and receiving. In other words, WebLN allows web apps to interact with Lightning wallets.
WebLN offers a few advantages. First, JavaScript is nearly universal and almost thirty years old. We’re pretty sure it works. Second, WebLN is simple. How simple? Michael Bumann from Alby can set it up and demonstrate how to use it in five minutes and thirty-eight seconds.
Third, WebLN delivers a much better UX than QR codes, starting with the fact that you don’t need to use a second device. It feels native, not like a workaround. You also have access to all browser events, so a key press, a mouse click, a scroll position, etc. can all trigger a payment. The QR-free UX is especially handy on mobile where WebLN works, too.
Still, WebLN isn’t a universal web-to-Lightning interface. It requires a WebLN-enabled environment. On a desktop browser a simple extension, like Alby, can create that environment. On mobile, developers can either work out their own WebLN solution or find a home in a Lightning app that already offers a built-in WebLN environment, like Breez and BlueWallet. Perhaps the fact that WebLN isn’t native to web browsers has prevented or slowed its widespread adoption. I can see a future where WebLN hosts are implemented natively in sites using WebAssembly, removing the seams for end users.
For many simple browser-based transactions, like tipping and one-time purchases, WebLN is all you need to integrate our two favorite networks. It works so well that many of the top Lightning services have been using it successfully for years. That includes Bitrefill, LNMarkets, and Kollider.
APIs
When it comes to integrating a web service and a Lightning service seamlessly, it’s hard to beat an application programming interface (API) designed to do just that. API integration gives developers the greatest control over the user experience and interface.
As good as that sounds, APIs also come with tradeoffs. The first is that choosing an API is a fairly serious commitment. There is no overarching integration standard, so each Lightning service defines its side of the API as it pleases, and the web service will have to build its UX around the API. Switching to another API could be very costly and entail significant changes to the UX and overall architecture.
A major consideration when choosing which Lightning service and which API is right for which web or mobile app is whether to select a self-hosted solution like BTCPay Server, LNPay or LNbits, or a custodial solution like ZEBEDEE or Strike. Again, tradeoffs apply.
- Self-hosted solutions give you full control over your funds but they require maintenance in the form of managing channels, balances, connectivity, regulatory compliance, server uptime, etc.
- Custodial solutions take a lot of the maintenance off your hands, but you’ll have to trust the custodian to hold your money (and if you’re willing to do that, you don’t really need Lightning in the first place). Moreover, custodial services only operate in certain jurisdictions for their own compliance and those geographic limitations naturally apply to services using them downstream, too.
But whatever their virtues in Bitcoiner philosophy, both approaches do work. Fountain allows users to stream sats back to their favorite podcasters while listening and they host their own node with LNPay. By the same token, the Lightning side of Twitter’s tipping function works on Strike’s API, so I guess a big public company (or is it just Elon?) is comfortable with their custodial service.
Choose what’s right for you.
LNC
The node management involved in a self-hosted solution might sound like a drag. But imagine you could do it in a handy browser interface, managing the channels and balances of your Lightning node just as you would manage your bills and accounts on an internet banking website. Now imagine offering that kind of functionality to your users. The world becomes your Lightning-enabled fintech oyster. And Lightning Node Connect (LNC) is the pearl.
As I said above, browsers are basically sandboxed operating systems. LNC applies WebAssembly to leverage that attribute for Lightning. LNC basically allows for full, remote node management through a browser. Letting users access and control their nodes through their browser gives web developers fantastic flexibility in how they craft their sites’ UX and opens the door to a range of potentially lucrative applications.
LNC allows access to the node’s gRPC (grpc remote procedure call) interface, so operators can open, close and rebalance channels in addition to other advanced functions. Lightning Web Terminal is a good example of how that can look in practice. This terminal is basically a remote control for power users’ nodes that they can access anywhere.
What’s the catch? There are two. First, LNC is the brainchild of Lightning Labs and only works with LND for now. Second, the more control you have over your node from outside, the more permissions you will have to grant to that outside interface; and the more permissions you grant, the greater your attack surface might be. Lightning Labs lists a number of potential threats themselves, including humans with access to the daemon, phishing attempts, browser vulnerabilities and third-party extensions. While the tech people at Lightning Labs are serious engineers, any app with such wide-ranging permissions can be an invitation to get “pwned.”
LSATs
Lightning Service Authentication Tokens (LSATs) are the final means to integrate Lightning with the web that we’ll discuss. No, they’re not a way to check who’s annoying enough to become a lawyer. The basic idea behind LSATs is to use carefully defined macaroons to authenticate the user and define their payment capabilities on the site.
Cleverly, the LSAT protocol uses HTTP code 402 which is a client-side error code meaning either “payment required” or “reserved for future use,” depending on who you ask (the Lightning Labs LSAT spec awesomely, but paradoxically, states “this document assumes the future has arrived”). That 402 code is used to invoke a “ticket” — a macaroon that simultaneously identifies the user and defines how that user can interact with the service.
The first benefit resulting from LSATs is that authentication and payment permissions happen in a single step. The service recognizes the user and how payments to and from that user are supposed to work as soon as they show up. No usernames, passwords or setting amounts at each visit. Sometimes it’s just nice to be familiar.
Second, these APIs can specify metered payments, just like the streaming sats in the Breez podcast player (though we use keysend instead). This is another way to obviate subscriptions. Users can pay for what they use — whether it’s podcast audio, streaming video, game play, text-based media — by whatever unit or interval, right down to the second.
LSATs have great potential and could perhaps even banish bots from social media by charging micropayments for microinteractions that would be trivial for users but prohibitive for bots.
Sounds great! Revolutionary tech that bans bots and integrates Lightning and the web! Hallelujah! What’s the catch? I don’t know, but I can’t figure out how LSATs have been around for a few years and yet I can’t name a single major service that has implemented them. Is it just a question of network effects and everyone is waiting for everyone else to take the plunge? Or is there some deeper, more substantial inhibition? Maybe you, dear reader, can educate me on that one.
The Future Is An Extension Of The Present
Some say that web3 is the future, and it seems to have something to do with crypto… and a network… and there’s probably some DeFi tomfoolery in there somewhere, too. I don’t know and I’m not sure anybody else does, either. What I do know is that the future belongs to Bitcoin, that Lightning is the technology that liquifies bitcoin, and that we have a functioning World Wide Web that everybody loves and wants to keep.
Isn’t it obvious that Lightning is destined to penetrate the web and that the web is destined to use Lightning as its leading payment technology? Or is it just me?
Integrating Lightning and the web was once an intimidating prospect, but no longer. We have a range of technologies for a range of use cases, a thriving community of developers innovating and perfecting the tech, and a world that already loves the web and is growing ever fonder of bitcoin.
Perhaps best of all, we don’t need any central standard to tell us how to integrate Lightning and the web. Everyone can choose the technology that best suits their local needs and work with the development community to help it improve. The new Lightning-enabled web will grow organically from the ground up, as it should.
This is a guest post by Roy Sheinfeld. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc. or Bitcoin Magazine.
