bLIP: 0011
Title: NameDesc
Status: Active
Author: Hampus Sjöberg <[email protected]>
Created: 2022-01-27
License: CC0
NameDesc is a standard for conveying "receiver name" in BOLT11 invoices.
This bLIP serves to document what is already supported by some wallets (see Reference Implementations), for posterity and so that new implementations don't have to reverse-engineer general-purpose NameDesc from existing implementations.
This bLIP is licensed under the CC0 license.
BOLT11 lets you include a description of an invoice. This is widely used across the ecosystem, however there's no coherent or conventional way to write an invoice description.
NameDesc provides a clear way on how to structure an invoice description that is helpful for the user and which the wallet software can parse.
It specifies how the name of the receiver should be presented, something which isn't always included. Not including the receiver name can lead to a transaction log item only showing an ID or product name, but not the actual service or store.
NameDesc is intentionally simplistic in order to make it easy for wallets and services to adopt it. It also provides a very good experience should a wallet not support reading NameDesc.
NameDesc consists in prepending the actual invoice description with the receiver
name, a colon and two spaces (: ).
For example, Alfred's wallet can produce an invoice with the following description:
Alfred: payment for the bubblegum you owed me
When Barbara's wallet receives that, it displays something like:
Paying to: Alfred
Description: payment for the bubblegum you owed me
NameDesc paves a way for a more structured and standardised way of writing invoices descriptions. Wallets that do not support NameDesc will still have a graceful fallback, as they will show:
Description: Alfred: payment for the bubblegum you owed me
And if the payee's wallet doesn't support including a "Name", Alfred can still manually type his name in the description field. Not the best experience in the world, but doable.
NameDesc lives in the application layer. It is not necessary for a lightning implementation to support/insert what the bLIP does here.
This does not have backwards compatibility concerns.