Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adding lightning address to Boost reply #524

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Adding lightning address to Boost reply #524

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
892fad6
Adding lightning address to Bosst reply
brianoflondon Apr 29, 2023
3c0c77c
typo fix in cross ref to value.md
brianoflondon Apr 30, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
30 changes: 15 additions & 15 deletions docs/1.0.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -586,7 +586,7 @@ Using this pattern, podcasts can maintain a consistent identity across the open
**Tips:**
* All podcasts in the Podcast Index have already been assigned a GUID; but if one exists in the RSS feed, that value is canonical.
* You can programmatically spot a GUID: it is 36 characters long, and contains four hyphen characters.
* Be aware that Amazon Music also uses separate UUIDv5 identifiers within their podcast directory, which are calculated differently and unrelated to this specification.
* Be aware that Amazon Music also uses separate UUIDv5 identifiers within their podcast directory, which are calculated differently and unrelated to this specification.
* The following regular expression (regex) will match a GUID:
```re
[0-9a-fA-F]{8}\-[0-9a-fA-F]{4}\-[0-9a-fA-F]{4}\-[0-9a-fA-F]{4}\-[0-9a-fA-F]{12}`
Expand Down Expand Up @@ -689,8 +689,8 @@ this tag works and what it is capable of.

### Attributes
- **name** (recommended) A free-form string that designates who or what this recipient is.
- **customKey** (optional) The name of a custom record key to send along with the payment.
- **customValue** (optional) A custom value to pass along with the payment. This is considered the value that belongs to the `customKey`.
- **customKey** (optional) The name of a custom record key to send along with the payment. In conjuction with `customValue`, this is used by a receiving service to redirect payments to a specific end user.
- **customValue** (optional) A custom value to pass along with the payment. This is considered the value that belongs to the `customKey`. This is used by a receiving service to redirect payments to a specific end user.
- **type** (required) A slug that represents the type of receiving address that will receive the payment.
- **address** (required) This denotes the receiving address of the payee.
- **split** (required) The number of shares of the payment this recipient will receive.
Expand Down Expand Up @@ -921,16 +921,16 @@ The node value is a free form string meant to explain to the user where this con
<br><br><br><br><!-- Tag block -->
## Social Interact
`<podcast:socialInteract>`<br><br>
The `socialInteract` tag allows a podcaster to attach the url of a "root post" of a comment thread to an episode. This "root post"
is treated as the canonical location of where the comments and discussion around this episode will take place. This can be thought
The `socialInteract` tag allows a podcaster to attach the url of a "root post" of a comment thread to an episode. This "root post"
is treated as the canonical location of where the comments and discussion around this episode will take place. This can be thought
of as the "official" social media comment space for this episode. If a protocol such as "activitypub" is used, or some other
protocol that allows programmatic API access, these comments can be directly pulled into the app, and replies can be posted back to
protocol that allows programmatic API access, these comments can be directly pulled into the app, and replies can be posted back to
the thread from the app itself.

If multiple `socialInteract` tags are given for an `<item>`, the `priority` attribute is strongly recommended to give the app an
If multiple `socialInteract` tags are given for an `<item>`, the `priority` attribute is strongly recommended to give the app an
indication as to which comments to display first.

This tag can also be used as a signal to platforms and apps that the podcaster does not want public comments shown alongside this
This tag can also be used as a signal to platforms and apps that the podcaster does not want public comments shown alongside this
episode. For this purpose a `protocol` value of "disabled" can be specified, with no other attributes or node value present.

### Parent
Expand Down Expand Up @@ -1036,22 +1036,22 @@ like [SPF](https://en.wikipedia.org/wiki/Sender_Policy_Framework#Implementation)
&nbsp; Multiple

### Attributes
- **purpose** (optional) A service specific string that will be used to denote what purpose this tag serves. This could
be something like "example.com" if it's a third party hosting platform needing to insert this
data, or something like "verify", "release" or any other free form bit of info that is
useful to the end consumer that needs it. The free form nature of this tag requires that this
- **purpose** (optional) A service specific string that will be used to denote what purpose this tag serves. This could
be something like "example.com" if it's a third party hosting platform needing to insert this
data, or something like "verify", "release" or any other free form bit of info that is
useful to the end consumer that needs it. The free form nature of this tag requires that this
attribute is also free formed. This value should not exceed `128 characters`.

### Purposes
The following are a list of strings known to be in common use. This list is in no way exhaustive. As new purposes come into
common use, this list will be updated by the community to reflect that.

- `verify` - The node value is expected to contain a string that is given by a third party platform to a podcaster in
order to prove that they are the owner of the feed and are in control of it. This is meant to replace the
- `verify` - The node value is expected to contain a string that is given by a third party platform to a podcaster in
order to prove that they are the owner of the feed and are in control of it. This is meant to replace the
need for emails to exist in feeds. See example section below.

### Node value
&nbsp; This is a free form string. Please do not exceed `4000 characters` for the node value or it may be truncated by
&nbsp; This is a free form string. Please do not exceed `4000 characters` for the node value or it may be truncated by
aggregators.

### Examples
Expand Down
81 changes: 61 additions & 20 deletions value/blip-0010.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -35,7 +35,7 @@ Simple Example:

## Specification

The sender of a bLIP-10 payment (i.e. - the podcast app) needs to include some metadata so the podcast host can
The sender of a bLIP-10 payment (i.e. - the podcast app) needs to include some metadata so the podcast host can
identify for whom the payment is for. Most fields are optional.

<br>
Expand All @@ -44,7 +44,7 @@ identify for whom the payment is for. Most fields are optional.

A flat, key-value json structure is used where the keys listed below can be set. The json string is then encoded
into `utf8` and attached to the Lightning payment. Most of the time, the payment will be a `keysend` payment, but this
TLV data can be used in standard BOLT11 and BOLT12 payments also. Receivers of messages must be aware that there
TLV data can be used in standard BOLT11 and BOLT12 payments also. Receivers of messages must be aware that there
is no guarantee for the order of the keys.

A more complex example:
Expand Down Expand Up @@ -80,7 +80,7 @@ Treated as `utf-8`, the hex value of the above json record would be:

### Types

If a field is indicated to be a `str` in the fields-list, that means it is a JSON string (within quotes). An `int` is
If a field is indicated to be a `str` in the fields-list, that means it is a JSON string (within quotes). An `int` is
a plain number.

<br>
Expand Down Expand Up @@ -115,50 +115,91 @@ Information about time within the episode **recommended**: use one of `ts` or `t

Other fields that are strongly recommended:

* `action` **recommended**: (str) "boost", "stream" or "auto". See Appending B of the
[value](/value.md#appendix-b---payment-actions) spec for details.
* `action` **recommended**: (str) "boost", "stream" or "auto". See Appending B of the
[value](value.md#appendix-b---payment-actions) spec for details.
* `app_name`: **recommended** (str) Name of sending app
* `sender_name` **recommended** (str) Name of the sender (free text, not validated in any way)
* `value_msat_total`: **recommended** (int) TOTAL Number of millisats for the payment before any fees are subtracted.
This should be the number the listener entered into the app. Preserving
this value is important for numerology reasons. Certain numeric values can
have significance to the sender and/or receiver, so giving a way to show
have significance to the sender and/or receiver, so giving a way to show
this is critical.

<br>

Other optional fields:

* `message` (str) Text message to add to the payment. When this field is present, the payment is known as a
* `message` (str) Text message to add to the payment. When this field is present, the payment is known as a
"boostagram".
* `app_version`: (str) Version of sending app
* `boost_link`: (str) App specific URL containing route to podcast, episode, and/or timestamp at time of the action.
The use case for this is sending a link along with the payment that will take the recipient to
* `boost_link`: (str) App specific URL containing route to podcast, episode, and/or timestamp at time of the action.
The use case for this is sending a link along with the payment that will take the recipient to
the exact playback position within the episode where the payment was sent.
* `name` (str) Name for this split in value tag
* `sender_id` (str) Static random identifier for users, not displayed by apps to prevent abuse. Apps can set this
per-feed or app-wide. A GUID-like random identifier or a hash works well. Max 32 bytes (64 ascii
per-feed or app-wide. A GUID-like random identifier or a hash works well. Max 32 bytes (64 ascii
characters). This can be a Nostr hex encoded pubkey (not NIP-19) for purposes of sender attribution.
* `signature` (str) Optionally, this field can contain a signature for the payment, to be able to verify that the
user who sent it is actually who they claim in the `sender_id` field. If the `sender_id` contains
a Nostr public key, this field should contain a Nostr `sig` value as a 64-byte encoded hex string.
For the purpose of generating the Nostr signature, the following data should be serialized:
[0,`sender_id`,`ts`,1,[],`message`] to conform to the
[NIP-01](https://github.com/nostr-protocol/nips/blob/master/01.md) specification. The resulting
a Nostr public key, this field should contain a Nostr `sig` value as a 64-byte encoded hex string.
For the purpose of generating the Nostr signature, the following data should be serialized:
[0,`sender_id`,`ts`,1,[],`message`] to conform to the
[NIP-01](https://github.com/nostr-protocol/nips/blob/master/01.md) specification. The resulting
serialized string should be hashed with `sha256` to obtain the value.
* `speed` (str) Speed in which the podcast was playing, in decimal notation at the time the payment was sent. So 0.5
* `speed` (str) Speed in which the podcast was playing, in decimal notation at the time the payment was sent. So 0.5
is half speed and 2 is double speed.
* `uuid` (str) Unique UUID of the payment.
* `reply_address` (str) The pubkey of the lightning node that can receive payments for the sender. The node given
* `reply_lnaddress` (str) Taking the form of a Lightning Address `[email protected]` this address should be resolvable as described in the section [Lightning Address](#lightning-address) below.
* `reply_address` (str) The pubkey of the lightning node that can receive payments on behalf of the sender. The node given
must be capable of receiving keysend payments.
* `reply_custom_key` (str) The custom key for routing a reply payment to the sender. This field should not be present
if it is not required for payment routing.
* `reply_custom_value` (str) The custom value for routing a reply payment to the sender. This field should not be present
if it is not required for payment routing.
* `reply_custom_key` (str) The custom key for redirecting payments to an end user. This field should not be present
if it is not required for payment redirection.
* `reply_custom_value` (str) The custom value for redirecting payments to an end user. This field should not be present
if it is not required for payment redirection.


<br>

### Lightning Address {lightning-address}

Providers (say, `example.com`) supporting `.well-known/keysend` lookup scheme should implement the following:

`GET` request to

`https://example.com/.well-known/keysend`

should return HTTP status code 200 and a JSON with at least the following fields

* `status` (required): "OK"
* `message` (required): string describing what information is returned through this lookup scheme

`GET` request to

`https://example.com/.well-known/keysend/{lightningUsername}`

should return the following based on the value of `{lightningUsername}`:

* If Ligthning address `{lightningUsername}@example.com` exists, HTTP status code 200 and a JSON with at least the following fields should be returned:

* `status` (required): "OK"
* `tag` (required): "keysend"
* `pubkey` (required): string representing destination node's public key
* `customData` (optional): array of `CustomData`, which has fields

* `customKey` (required): number
* `customValue` (required): string

* Optionally, if the syntax for the Lightning address at `example.com` does not allow username `{lightningUsername}`, HTTP status code 422 and a JSON with at least the following fields should be returned:

* `status` (required): "UNPROCESSABLE_ENTITY"
* `tag` (required): "keysend"
* `message` (optional): string describing why the username is invalid

* In any other case, HTTP status code 404 and a JSON with at least the following fields should be returned:
* `status` (required): "NOT_FOUND"
* `tag` (required): "keysend"



## Reference Implementations

Expand Down