Introducing: Joule Allowances
Configurable automatic payments for a seamless experience
Since I first started working on Joule, I’ve always had the goal of enabling seamless micropayments to happen in the background so that you can enjoy content on the web without content creators having to resort to back channel methods to get paid. Methods such as selling your data, showing privacy leaking and potentially malicious ads, or even embedding advertising into the content itself (he writes, whilst sipping on a refreshingly cold Coors Light™️).
Today I’m happy to give a preview of the first of many steps to enable seamless payments in Joule, that you should have a chance to try out yourself soon.
In an upcoming update, opening the Joule extension will show you the following banner when you’re on a WebLN-enabled page:
Clicking on the piggy bank icon on the right will take you to the new allowance configuration page:
Here you can configure an allowance for any application, that will allow WebLN payments to be completed without any intervention on your part. This is ideal for apps that have small, frequent payments to access content (For instance, a video streaming platform that charges you for every minute of viewing time.)
You can configure your allowances in a few ways:
- Balance — This is the maximum amount of money that can be spent on the application in total. As payments are made, your balance will be depleted. You can come back in here and click the refill button at any time to top up.
- Max Payment — This is the most any individual invoice payment can be without your explicit confirmation.
- Cooldown — This is how frequently payments can be made, in seconds. This will prevent malicious websites from trying to drain your allowance by spamming a bunch of small payments.
- Notifications — Whether or not to notify you each time a payment is made. By default, each payment will give you a little prompt to let you know how much you just paid, and how much balance you have left.
Any payment attempts that don’t meet the criteria of your allowance will just pop up the payment window as normal, so you won’t miss out even if a payment doesn’t fall into your allowance configuration.
If you have thoughts about the allowance implementation, or are brave enough to try it yourself, the open pull request is here.
Allowance Payment Compatibility
After some testing, I found that allowance payments were a rough experience for the majority of Lightning apps available today, especially those whose nodes I wasn’t directly connected to. I’d typically click on a button, and sit for a few seconds with no UI feedback. After a few seconds, I’d get access to what I paid for (if the payment was successful) or be prompted by Joule (if the payment had an issue.)
To prevent confusing and negative user experiences, Joule allowance payments will be limited to payments made via WebLN for now. Due to the asynchronous nature of payments, it’s important for applications to keep the user aware of the current state of their payment. With the traditional method of presenting an invoice, there’s no feedback to the user that their payment is in-flight. Something may go wrong along the way, or it may just be taking a while, but all of that is opaque to your application.
With WebLN’s asynchronous sendPayment API, you can programmatically know when the user has started making the payment, when it completes, and if anything goes wrong along the way.
If you’re interested in enabling allowances in your application, but haven’t gotten started with WebLN, I suggest you check out the official WebLN documentation, and maybe go through a recent tutorial I put together of how to add WebLN support to an existing web app, with plenty of code examples.
The Future of Automatic Payments
Joule’s interface is just the start of automatic payments while browsing the web with Lightning. There’s currently ongoing discussion of how to programmatically request, configure, and inspect allowances via WebLN, a discussion of using the HTTP 402 response code for payments (that could be done automatically), and new features that would make programmable auto-payments more feasible (e.g. customizable LND macaroons.)
While it’s hard to say if Joule Allowances will be the end-all-be-all of auto payments, hopefully it will enable builders to start trying out a more micro-payments driven approach to new applications, and spur more interest and development in this area. If you have any feedback, don’t hesitate to hit me up on Twitter, or drop an issue in the Joule issue queue.