The recipients of the value blocks of a feed: what's wrong with them, what their Lightning addresses answer, and paying them all at once.
A host or a validator checks a feed with problems and check!, and an app pays a boost or a stretch of a stream with pay!, through the wallet of the listener.
The recipients of the value blocks of a feed: what's wrong with them, what their Lightning addresses answer, and paying them all at once. A host or a validator checks a feed with problems and check!, and an app pays a boost or a stretch of a stream with pay!, through the wallet of the listener.
(check! feed)(check! feed opts)Ask the domain of each Lightning address among the recipients of feed
for its terms of LNURL-pay and its node for keysend, with opts, and
give what they answered, in a future or a promise:
{:addresses {"ann@example.org" {:terms {…} :node {…}}}
:report [...]} ; what failed, with the :path of the recipient
An address without a node for keysend is reported at the level info,
since an app pays it with an invoice instead. The opts are those of
lnaddress/fetch-terms!, and the addresses are asked once each, four at a
time.
Ask the domain of each Lightning address among the recipients of `feed`
for its terms of LNURL-pay and its node for keysend, with `opts`, and
give what they answered, in a future or a promise:
{:addresses {"ann@example.org" {:terms {…} :node {…}}}
:report [...]} ; what failed, with the :path of the recipient
An address without a node for keysend is reported at the level info,
since an app pays it with an invoice instead. The `opts` are those of
lnaddress/fetch-terms!, and the addresses are asked once each, four at a
time.(pay! recipients sats payment opts)Pay sats to the recipients of a value block, divided as
value/payments divides them, with the payment that goes with each,
through the wallet of the listener, as the opts below say. It gives an
entry for each recipient, in a future or a promise.
An entry has the :recipient, the :sats, and a :status of :paid, with the :preimage, :failed or :skipped, with the :error. A share of less than a sat is skipped, and so is a recipient without a way to pay its type, or one whose custom record wouldn't reach its wallet. A payment to an invoice is :proven? when the preimage proves it.
The payments go one at a time, so the wallet sees no burst, and the
:total-sats of each is the whole sats, as bLIP-10 has it. When the
payment has a :group, the id of the boost or the stretch of a stream,
the payment to each recipient has the :id of that group and its place,
e.g. "b7e1…/2", as RSS Payment Metadata has it, and so does its entry.
Pay `sats` to the `recipients` of a value block, divided as value/payments divides them, with the `payment` that goes with each, through the wallet of the listener, as the `opts` below say. It gives an entry for each recipient, in a future or a promise. - :keysend-fn, a function of a payment with its :sats and a recipient of the type node, which pays it and gives what the wallet answered, e.g. with nwc/ask! of nwc/pay-keysend, or webln/pay-keysend! - :invoice-fn, a function of an invoice, which pays it and gives what the wallet answered, e.g. webln/pay-invoice! - :invoice-opts, the options of lnaddress/request-invoice! for the recipients of the type lnaddress, e.g. a :comment - :sending-fn, a function called with each entry just before it goes to the wallet, so that you can record it, e.g. with profile.payments, and not send it again after a crash An entry has the :recipient, the :sats, and a :status of :paid, with the :preimage, :failed or :skipped, with the :error. A share of less than a sat is skipped, and so is a recipient without a way to pay its type, or one whose custom record wouldn't reach its wallet. A payment to an invoice is :proven? when the preimage proves it. The payments go one at a time, so the wallet sees no burst, and the :total-sats of each is the whole `sats`, as bLIP-10 has it. When the `payment` has a :group, the id of the boost or the stretch of a stream, the payment to each recipient has the :id of that group and its place, e.g. "b7e1…/2", as RSS Payment Metadata has it, and so does its entry.
(problems feed)The diagnostics of the value blocks of feed, of its channel and of its
items, that would send a payment where the podcaster doesn't mean it to
go. Each has the :path of the block, the time split or the recipient.
They're those of these checks, which the validator leaves out, since they're about payments rather than the form of the feed:
The diagnostics of the value blocks of `feed`, of its channel and of its items, that would send a payment where the podcaster doesn't mean it to go. Each has the :path of the block, the time split or the recipient. They're those of these checks, which the validator leaves out, since they're about payments rather than the form of the feed: - a block without recipients - fees of more than 100 percent, or no recipient with a share - two recipients with the same wallet - an address that doesn't have the form of the type of its recipient - a time split without recipients or a remote item, or with both - time splits that overlap
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 |