# for restaurant menus

  1. A browser, a dedicated app for reading restaurant menus or the wallet itself (if it also wants to be that) reads a QR code with an URL (no lnurl here) and fetches a menu spec. That spec in its most simplest form is just
    [
      "lnurl...",
      "lnurl...",
      "lnurl...",
      "lnurl..."
    ]
    
  2. The app decodes and fetches all these URLs. Since items are the same for everybody these requests should be mostly static/cached and cheap. Each item may return a "text/plain" and an "image/png;base64" as metadata items, for example.
  3. Using text, price and image from above, the app displays a standard collection of items.
  4. As user chooses items, the app handles them to the wallet so it can proceed with the lnurl-pay flow.
  5. User shows payment proofs at the end and gets its products.

If the restaurant has tables and want to know which table ordered what, just make a different QR code for each table so the menu collection and each of the items lnurl-pays have the table number in them.

# for subscriptions

You don't need a custom protocol for Lightning subscriptions. You just have to embed a calendar in a wallet.

  1. Service shares a subscription lnurl-pay. That should contain some unique identifier for the user so service knows who is requesting to pay each month.
  2. Wallet has a special screen for scanning subscription lnurls.
  3. 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.
  4. 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:

  1. User scans lnurl in special streaming mode.
  2. Wallet fetches metadata and price and shows to user.
  3. After getting agreement from the user, wallet starts making repeated automated lnurl-pay payments.
  4. If for some reason the metadata or invoice amount returned by the service changes, wallet must stop and tell the user.
  5. 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 services webpages.

Now imagine that instead of webpages, apps have just a collection of items or services they sell. Something like

[
  {
    "lnurl": "https://service.com/lnurl/itemA",
    "name": "itemA",
    "picture": "https://service.com/pic/itemA",
    "params": {
      "color": {
        "type": "select",
        "options": [
          "red",
          "green"
        ]
      }
    }
  },
  {
    "lnurl": "https://service.com/lnurl/itemB",
    "name": "itemB",
    "picture": "https://service.com/pic/itemB",
    "params": {
      "address": {
        "type": "text"
      },
      "custom": {
        "type": "text"
      }
    }
  },
  {
    "lnurl": "https://service.com/lnurl/itemC",
    "name": "itemC",
    "picture": "https://service.com/pic/itemC"
  }
]
  1. 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 choices.
  2. Upon choosing one, the app would then fetch the lnurl appending the chosen params as query strings to it.
  3. 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 return errors.

# 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.