Value for value: the arithmetic of podcast:value blocks, and the record of a payment.
The functions here give who is paid at a moment of playback, with the time splits of valueTimeSplit. They divide an amount into shares and fees, and make no payment, which is up to you.
Value blocks and recipients are maps of the feed model, e.g.:
{:type "lightning"
:method "keysend"
:suggested 0.00000005
:recipients [{:type "node" :address "…" :split 99 :fee false}]
:time-splits [...]}
A payment is a map of what an app sends with a payment to one recipient. It has one shape for the bLIP-10 record of a keysend payment and for the RSS Payment Metadata of the podcast namespace:
{:action :boost ; :boost, :stream or :auto
:msat 25000 ; to this recipient
:total-msat 100000 ; of the whole payment, before the splits
:message "Great episode!"
:position 754 ; seconds into the episode
:feed-guid "…" :feed-title "…"
:item-guid "…" :item-title "…"
:app-name "…" :sender-name "…"
:recipient-name "…"}
The texts of a payment are as its sender wrote them. Hiccup escapes them, but an app that writes HTML as text must escape them itself.
Value for value: the arithmetic of podcast:value blocks, and the record
of a payment.
The functions here give who is paid at a moment of playback, with the
time splits of valueTimeSplit. They divide an amount into shares and
fees, and make no payment, which is up to you.
Value blocks and recipients are maps of the feed model, e.g.:
{:type "lightning"
:method "keysend"
:suggested 0.00000005
:recipients [{:type "node" :address "…" :split 99 :fee false}]
:time-splits [...]}
A payment is a map of what an app sends with a payment to one recipient.
It has one shape for the bLIP-10 record of a keysend payment and for the
RSS Payment Metadata of the podcast namespace:
{:action :boost ; :boost, :stream or :auto
:msat 25000 ; to this recipient
:total-msat 100000 ; of the whole payment, before the splits
:message "Great episode!"
:position 754 ; seconds into the episode
:feed-guid "…" :feed-title "…"
:item-guid "…" :item-title "…"
:app-name "…" :sender-name "…"
:recipient-name "…"}
The texts of a payment are as its sender wrote them. Hiccup escapes
them, but an app that writes HTML as text must escape them itself.(as-received payment {:keys [msat address] :as received})The payment, as its sender claims it, with the amount that the node of
the recipient received, the :msat of received.
The report tells where a claim differs from what the node knows: another
amount, or another recipient than the :address of received. Anyone
can send a record, or name metadata, with a payment of one satoshi, so
what the node received is the fact.
The `payment`, as its sender claims it, with the amount that the node of the recipient received, the :msat of `received`. The report tells where a claim differs from what the node knows: another amount, or another recipient than the :address of `received`. Anyone can send a record, or name metadata, with a payment of one satoshi, so what the node received is the fact.
(boostagram {:keys [position action speed] :as payment})The bLIP-10 record of payment, which an app attaches to a keysend
payment as the custom record 7629169. It's a map with the string keys
of the record, to write as JSON.
The keys of the payment become these:
Nil values are left out.
The bLIP-10 record of `payment`, which an app attaches to a keysend payment as the custom record 7629169. It's a map with the string keys of the record, to write as JSON. The keys of the payment become these: - :position, seconds into the episode, becomes ts and time - :action becomes action, boost when it's absent - :msat and :total-msat become value_msat and value_msat_total, and :sats and :total-sats count in sats in their place - :speed becomes text, as bLIP-10 writes it - the other keys of a payment get the names of the record, any other key its snake_case, and a string key stays as it is Nil values are left out.
(parse-boostagram record)The payment that the bLIP-10 record describes.
The record is JSON text, or the UTF-8 bytes of that text, as a node gives the custom record 7629169. It can also be the JSON object as a map with string keys.
The fields that bLIP-10 defines become the keys of a payment, and the other fields keep their names. The report tells what the reader forgave. Real apps write numbers as text, amounts with a fraction, and fields under other names. They write the guid of the episode as the itemID, and the action under another name. A record that isn't a JSON object reads as no payment.
The record is what the sender claims, not what the node received.
The payment that the bLIP-10 `record` describes. The record is JSON text, or the UTF-8 bytes of that text, as a node gives the custom record 7629169. It can also be the JSON object as a map with string keys. The fields that bLIP-10 defines become the keys of a payment, and the other fields keep their names. The report tells what the reader forgave. Real apps write numbers as text, amounts with a fraction, and fields under other names. They write the guid of the episode as the itemID, and the action under another name. A record that isn't a JSON object reads as no payment. The record is what the sender claims, not what the node received.
(payments recipients amount)The shares of amount that recipients get, as the podcast:value
specification prescribes in its part Payment calculation. The amount
is a whole number of the smallest unit, e.g. sats.
Each fee recipient takes its split as a percentage off the top, and the others share the rest by their splits. The result is a vector of maps of the :recipient and its :amount in whole units. A rounding remainder goes to the largest share. So that no amount is negative:
The shares of `amount` that `recipients` get, as the podcast:value specification prescribes in its part Payment calculation. The `amount` is a whole number of the smallest unit, e.g. sats. Each fee recipient takes its split as a percentage off the top, and the others share the rest by their splits. The result is a vector of maps of the :recipient and its :amount in whole units. A rounding remainder goes to the largest share. So that no amount is negative: - a split that isn't a number counts as none - a fee takes at most all - the fees stop where the amount runs out
(recipients-at block seconds)(recipients-at block seconds remotes)Who is paid seconds into the playback of media under block, as a
map of :recipients, with the value blocks of remotes folded in.
Outside a time split, they're the recipients of the block. Inside one,
they're its fee recipients and those of the split. Inside a split that
points at a remote item, :remote holds the :remote-item, :percentage,
:start-time and :offset. The remotes map each remote item to its value
block, or to nil when it has none, and that block is folded in.
Without remotes, or when they lack the remote item, the recipients are
the fee recipients alone.
Who is paid `seconds` into the playback of media under `block`, as a map of :recipients, with the value blocks of `remotes` folded in. Outside a time split, they're the recipients of the block. Inside one, they're its fee recipients and those of the split. Inside a split that points at a remote item, :remote holds the :remote-item, :percentage, :start-time and :offset. The `remotes` map each remote item to its value block, or to nil when it has none, and that block is folded in. Without `remotes`, or when they lack the remote item, the recipients are the fee recipients alone.
(records payment
{recipient-name :name :keys [custom-key custom-value] :as recipient})The custom records of a keysend payment of payment to recipient, as
a map from the type of each record to its text.
They're the bLIP-10 record under 7629169, with the name of the recipient, and the custom key and value of the recipient. A node that holds many wallets finds the wallet by these.
The feed chooses the custom key. So the records leave out a key below 65536, which BOLT 1 keeps for the Lightning protocol. They also leave out the type of the bLIP-10 record, and the type of the preimage of keysend, 5482373484.
The report says when the records leave out the custom key or the custom value of the recipient. A payment with such records reaches the node, and not the wallet, so don't send it.
The custom records of a keysend payment of `payment` to `recipient`, as a map from the type of each record to its text. They're the bLIP-10 record under 7629169, with the name of the recipient, and the custom key and value of the recipient. A node that holds many wallets finds the wallet by these. The feed chooses the custom key. So the records leave out a key below 65536, which BOLT 1 keeps for the Lightning protocol. They also leave out the type of the bLIP-10 record, and the type of the preimage of keysend, 5482373484. The report says when the records leave out the custom key or the custom value of the recipient. A payment with such records reaches the node, and not the wallet, so don't send it.
(report payment)The diagnostics recorded while reading payment.
The diagnostics recorded while reading `payment`.
(sats block)The :suggested amount of block, given in BTC, as whole satoshis, or
nil when it has none.
The :suggested amount of `block`, given in BTC, as whole satoshis, or nil when it has none.
(share-total recipients)The sum of the splits of the non-fee recipients.
The sum of the splits of the non-fee `recipients`.
(with-remote block paid remote)The recipients of paid, who is paid at a moment under block, with
the remote value block that a time split pointed at folded in.
The result is paid with :recipients that hold the fees of both blocks,
and it keeps :remote, so that a payment can name the remote item. The
non-fee recipients of the remote block get the percentage of the split,
and those of the block get the rest. Their splits are rescaled to whole
shares that express this. Without a remote block, the recipients of
the block apply. Outside a remote split, paid stays as it is.
The recipients of `paid`, who is paid at a moment under `block`, with the `remote` value block that a time split pointed at folded in. The result is `paid` with :recipients that hold the fees of both blocks, and it keeps :remote, so that a payment can name the remote item. The non-fee recipients of the remote block get the percentage of the split, and those of the block get the rest. Their splits are rescaled to whole shares that express this. Without a `remote` block, the recipients of the block apply. Outside a remote split, `paid` stays as it is.
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 |