Lightning addresses, which a podcast:valueRecipient of type lnaddress names, and how to pay them. An address has the form user@domain.
The requests ask the domain of an address, as LUD-16 and the podcast namespace define them, and the readers read the answers. The wallet of the app pays.
LNURL-pay gives an invoice for an amount. The domain gives the terms of the address: the callback, the amounts that it takes, and how long a comment can be. The callback gives the invoice, which must ask for the amount that was requested, as LUD-06 requires. The keysend lookup gives a node instead, to pay with keysend.
A reader goes by the JSON of an answer, not by its status, as LUD-01 asks. Services answer an error with any status, and some answer the keysend lookup with a web page.
Lightning addresses, which a podcast:valueRecipient of type lnaddress names, and how to pay them. An address has the form user@domain. The requests ask the domain of an address, as LUD-16 and the podcast namespace define them, and the readers read the answers. The wallet of the app pays. LNURL-pay gives an invoice for an amount. The domain gives the terms of the address: the callback, the amounts that it takes, and how long a comment can be. The callback gives the invoice, which must ask for the amount that was requested, as LUD-06 requires. The keysend lookup gives a node instead, to pay with keysend. A reader goes by the JSON of an answer, not by its status, as LUD-01 asks. Services answer an error with any status, and some answer the keysend lookup with a web page.
The limits of the requests to a Lightning address that their options don't set: the seconds that each request can take, and the size of an answer in bytes.
The terms of an address can hold an image of about 136 kilobytes, by LUD-06.
The limits of the requests to a Lightning address that their options don't set: the seconds that each request can take, and the size of an answer in bytes. The terms of an address can hold an image of about 136 kilobytes, by LUD-06.
(fetch-node! address)(fetch-node! address opts)Fetch the node that pays the Lightning address with keysend, with
opts. On the JVM it gives the node, and in ClojureScript a promise of
it.
A failure gives a map with a diagnostic under :error. The opts are
those of request-invoice!, except the comment.
Fetch the node that pays the Lightning `address` with keysend, with `opts`. On the JVM it gives the node, and in ClojureScript a promise of it. A failure gives a map with a diagnostic under :error. The `opts` are those of request-invoice!, except the comment.
(fetch-terms! address)(fetch-terms! address opts)Fetch the terms on which the Lightning address takes a payment, with
opts. On the JVM it gives the terms, and in ClojureScript a promise of
them.
A failure gives a map with a diagnostic under :error. The opts are
those of request-invoice!, except the comment and the payer.
Fetch the terms on which the Lightning `address` takes a payment, with `opts`. On the JVM it gives the terms, and in ClojureScript a promise of them. A failure gives a map with a diagnostic under :error. The `opts` are those of request-invoice!, except the comment and the payer.
(invoice {:keys [callback] :as terms} msat response)The invoice in the response to the request for an invoice of msat
millisatoshis from terms, or a map with a diagnostic under :error.
{:invoice "lnbc…" ; for the wallet to pay
:msat 25000
:network :bitcoin
:expires-at #inst "…" ; after which no wallet pays it
:success-action {:tag "message" :message "Thanks!"}
:verify "https://…"} ; tells whether it is paid, LUD-21
An invoice that asks for another amount is an error, as LUD-06 requires. So is a success action of a kind that LUD-09 doesn't define, or with a URL on another host than the callback. Show the success action after the payment. An action of the tag aes holds :ciphertext and :iv, which the preimage of the payment decrypts.
The invoice in the `response` to the request for an invoice of `msat`
millisatoshis from `terms`, or a map with a diagnostic under :error.
{:invoice "lnbc…" ; for the wallet to pay
:msat 25000
:network :bitcoin
:expires-at #inst "…" ; after which no wallet pays it
:success-action {:tag "message" :message "Thanks!"}
:verify "https://…"} ; tells whether it is paid, LUD-21
An invoice that asks for another amount is an error, as LUD-06 requires.
So is a success action of a kind that LUD-09 doesn't define, or with a
URL on another host than the callback. Show the success action after the
payment. An action of the tag aes holds :ciphertext and :iv, which the
preimage of the payment decrypts.(invoice-request terms msat)(invoice-request terms msat comment)(invoice-request {:keys [callback] :as terms} msat comment payer)The request to the callback of terms for an invoice of msat
millisatoshis, with a comment when the terms take one, and the details
of the payer that they take, as LUD-18 has it.
The comment is cut to fit the terms. The payer is a map of :name,
:pubkey, :identifier and :email, e.g. {:name "Ann"}, and those that
the :payer-data of the terms doesn't name stay out. The amount, the
comment and the details follow the query that the callback has. It
throws when the terms don't take msat.
The request to the callback of `terms` for an invoice of `msat`
millisatoshis, with a `comment` when the terms take one, and the details
of the `payer` that they take, as LUD-18 has it.
The comment is cut to fit the terms. The `payer` is a map of :name,
:pubkey, :identifier and :email, e.g. {:name "Ann"}, and those that
the :payer-data of the terms doesn't name stay out. The amount, the
comment and the details follow the query that the callback has. It
throws when the terms don't take `msat`.(keysend-request address)The request for the node that pays the Lightning address with
keysend, or nil when address isn't one.
The request for the node that pays the Lightning `address` with keysend, or nil when `address` isn't one.
(lnurlp-request address)The request for the terms on which the Lightning address takes a
payment with LNURL-pay, or nil when address isn't one.
The request for the terms on which the Lightning `address` takes a payment with LNURL-pay, or nil when `address` isn't one.
(node response)The node that the response to the keysend lookup names, as the keys of
a recipient of type node, or a map with a diagnostic under :error.
{:type "node" :address "02…" :custom-key "696969"
:custom-value "1"}
Merged into a recipient of type lnaddress, it keeps the name, the split and the fee of the recipient. A service that holds many wallets on one node names the wallet with the custom key and value.
The node that the `response` to the keysend lookup names, as the keys of
a recipient of type node, or a map with a diagnostic under :error.
{:type "node" :address "02…" :custom-key "696969"
:custom-value "1"}
Merged into a recipient of type lnaddress, it keeps the name, the split
and the fee of the recipient. A service that holds many wallets on one
node names the wallet with the custom key and value.(parse s)The parts of the Lightning address s as a map of :user and :domain, in
lower case, or nil when s isn't one.
A user name holds the letters a to z, the digits, and the characters minus, underscore, dot and plus, as LUD-16 allows. An address that's only @domain is short for the default identifier of the domain, with the user name underscore, as LUD-16 has it.
The domain is a name on the public internet. It isn't an IP address, and it has a dot in it. It isn't a name that stays on a local network, such as localhost, .local, .internal or .home.arpa. It has no port, and the dot that can end a name is left out. A feed chooses the address, and so the domain that the app asks.
The parts of the Lightning address `s` as a map of :user and :domain, in lower case, or nil when `s` isn't one. A user name holds the letters a to z, the digits, and the characters minus, underscore, dot and plus, as LUD-16 allows. An address that's only @domain is short for the default identifier of the domain, with the user name underscore, as LUD-16 has it. The domain is a name on the public internet. It isn't an IP address, and it has a dot in it. It isn't a name that stays on a local network, such as localhost, .local, .internal or .home.arpa. It has no port, and the dot that can end a name is left out. A feed chooses the address, and so the domain that the app asks.
(request-invoice! address msat)(request-invoice! address msat {:keys [comment payer] :as opts})Request an invoice from the Lightning address for msat millisatoshis
with opts. On the JVM it gives the invoice, and in ClojureScript a
promise of it.
A failure gives a map with a diagnostic under :error. This asks for the
terms of the address and then for the invoice, with the :comment of
opts. The comment is text, or a function of the terms that gives the
text, e.g. to fit a comment to their :comment-length. The invoice has
the :comment that went out, as it was cut. An invoice without one went
out with no comment, so the recipient doesn't learn what the payment is
for. The :payer of opts is the details of the payer, as
invoice-request takes them, or a function of the terms that gives them.
The other opts are these:
The domain of an address in a feed chooses the URLs that this fetches. So each request carries a guard as its :allow-pred, which lets nothing go to a private network. To reach your own network, give (constantly true) as :allow-pred.
Request an invoice from the Lightning `address` for `msat` millisatoshis with `opts`. On the JVM it gives the invoice, and in ClojureScript a promise of it. A failure gives a map with a diagnostic under :error. This asks for the terms of the address and then for the invoice, with the :comment of `opts`. The comment is text, or a function of the terms that gives the text, e.g. to fit a comment to their :comment-length. The invoice has the :comment that went out, as it was cut. An invoice without one went out with no comment, so the recipient doesn't learn what the payment is for. The :payer of `opts` is the details of the payer, as invoice-request takes them, or a function of the terms that gives them. The other `opts` are these: - the limits of default-limits - :allow-pred, which URLs a request can go to - :send, a function that sends a request map in place of client/send! The domain of an address in a feed chooses the URLs that this fetches. So each request carries a guard as its :allow-pred, which lets nothing go to a private network. To reach your own network, give (constantly true) as :allow-pred.
(sendable? {:keys [min-msat max-msat] :as terms} msat)Whether a Lightning address with terms takes a payment of msat
millisatoshis.
Whether a Lightning address with `terms` takes a payment of `msat` millisatoshis.
(terms response)The terms on which a Lightning address takes a payment, from the
response to the request for its terms, or a map with a diagnostic
under :error.
{:callback "https://…" ; where to ask for an invoice
:min-msat 1000
:max-msat 100000000
:comment-length 255 ; how long a comment can be, 0 for none
:description "Pay Ann" ; the text of the metadata
:identifier "ann@…" ; the address, as the metadata names it
:metadata "[[…]]" ; the metadata, as the service wrote it
:payer-data {:name {:mandatory? false}}} ; LUD-18
The callback is an https URL, or http for an onion service. It can be on another host than the address. The :payer-data names the details of the payer that the service takes: :name, :pubkey, :identifier and :email.
The terms on which a Lightning address takes a payment, from the
`response` to the request for its terms, or a map with a diagnostic
under :error.
{:callback "https://…" ; where to ask for an invoice
:min-msat 1000
:max-msat 100000000
:comment-length 255 ; how long a comment can be, 0 for none
:description "Pay Ann" ; the text of the metadata
:identifier "ann@…" ; the address, as the metadata names it
:metadata "[[…]]" ; the metadata, as the service wrote it
:payer-data {:name {:mandatory? false}}} ; LUD-18
The callback is an https URL, or http for an onion service. It can be on
another host than the address. The :payer-data names the details of the
payer that the service takes: :name, :pubkey, :identifier and :email.(verification {pr :invoice :as invoice} response)What the response to the verify-request of invoice tells, or a map
with a diagnostic under :error: {:settled? false} while it's unpaid, and
{:settled? true :preimage "…"} once it's paid.
A payment counts only with the preimage that proves it, by bolt11/proves?, since the service writes the answer. A service that says that the invoice is paid without that proof is :value/unproven.
What the `response` to the verify-request of `invoice` tells, or a map
with a diagnostic under :error: {:settled? false} while it's unpaid, and
{:settled? true :preimage "…"} once it's paid.
A payment counts only with the preimage that proves it, by
bolt11/proves?, since the service writes the answer. A service that says
that the invoice is paid without that proof is :value/unproven.(verify! invoice)(verify! invoice opts)Ask the service of a Lightning address whether the invoice that
request-invoice! gave is paid, with the opts of request-invoice!, and
give what verification makes of the answer. On the JVM it gives the
answer, and in ClojureScript a promise of it.
A failure gives a map with a diagnostic under :error, and so does an invoice without a :verify URL, :value/unverifiable.
Ask the service of a Lightning address whether the `invoice` that request-invoice! gave is paid, with the `opts` of request-invoice!, and give what verification makes of the answer. On the JVM it gives the answer, and in ClojureScript a promise of it. A failure gives a map with a diagnostic under :error, and so does an invoice without a :verify URL, :value/unverifiable.
(verify-request {:keys [verify] :as invoice})The request to the service of a Lightning address for whether the
invoice that it gave is paid, to its :verify URL, or nil when it has
none.
The request to the service of a Lightning address for whether the `invoice` that it gave is paid, to its :verify URL, or nil when it has none.
cljdoc builds & hosts documentation for Clojure/Script libraries
| Ctrl+k | Jump to recent docs |
| ← | Move to previous article |
| → | Move to next article |
| Ctrl+/ | Jump to the search field |