# for subscriptions
You don't need a custom protocol for Lightning subscriptions. You just have
to embed a calendar in a wallet.
Service shares a subscription lnurl-pay. That should contain some
unique identifier for the user so service knows who is requesting to pay
Wallet has a special screen for scanning subscription lnurls.
After scanning, wallet asks user if the payment is going to done monthly
or how (in a better world wallet could extract from the URL query string
that info) and stores that along with the URL somewhere.
Every month or so, wallet fetches metadata and amounts from the
lnurl and shows to user, prompting him to pay. If yes, proceed
with lnurl flow.
Notice that this simple protocol allows for service to change its prices,
charge extra based on something user did on the platform, change exactly the
service it is offering by returning a new metadata every month -- or even
graciously shut down by returning an error.
# for streaming
Wallet has a special streaming mode (the UX for this is terrible and who
wants streaming anyway, but it's easy to imagine).
The flow here is basically the same as with subscriptions above, but with a
much shorter periodicity:
User scans lnurl in special streaming mode.
- Wallet fetches metadata and price and shows to user.
After getting agreement from the user, wallet starts making repeated
automated lnurl-pay payments.
If for some reason the metadata or invoice amount returned by the service
changes, wallet must stop and tell the user.
- Upon hitting "stop" or something like that, wallet must stop.
# in-app marketplaces
Wallets have tried to embed marketplaces inside them before
lnurl-pay and the result wasn't good. It was just a browser with
Now imagine that instead of webpages, apps have just a collection of items
or services they sell. Something like
A browser app, dedicated app or wallet itself could fetch these from some
URL provided by the service (and maybe even cache it for a while) and use
that info to display a menu of options to the user with these rich param
Upon choosing one, the app would then fetch the lnurl appending the chosen
params as query strings to it.
The app can then show more info from the metadata returned from
the lnurl call (this metadata will be specific for the item with the
parameters passed) and proceed with the lnurl flow.
Of course this is probably an overengineered solution we should only start
thinking about in 2040.
Validation?! The service can perform validation on the params and
# for UBL
Universal Business Language
is an standard some people like because it's a standard and thus written in
XML by boards of people who like to write XML.
Turns out lnurl-pay is a great fit for this! Or I should say just
that it probably is, because you can embed arbitrary metadata in your
payRequest (an thus in your Lightning invoice through
description_hash), so it should fit, but I decided to not try to
understand UBL anymore because I don't have 36 years to spare at the moment.