diff options
| author | fiatjaf <fiatjaf@gmail.com> | 2025-12-11 14:07:01 -0300 |
|---|---|---|
| committer | fiatjaf <fiatjaf@gmail.com> | 2026-02-02 00:08:24 -0300 |
| commit | 92cac52f1c4a05d5286418886f72d88c8e70b0ef (patch) | |
| tree | f09665a5ba9f50eb7212194989fdbb1f307c651d | |
| parent | 09d43929063b0c54c53c0f744e588da01c0e69a0 (diff) | |
add optional announcement with payment url.
| -rw-r--r-- | 63.md | 21 |
1 files changed, 21 insertions, 0 deletions
| @@ -54,8 +54,29 @@ After that, any `REQ`s should include premium content automatically and transpar | |||
| 54 | 54 | ||
| 55 | A client may decide to display these events differently if they have the `["nip63"]` tag. | 55 | A client may decide to display these events differently if they have the `["nip63"]` tag. |
| 56 | 56 | ||
| 57 | ### Announcement | ||
| 58 | |||
| 59 | Optionally a _content-creator_ can announce that they have premium content available by publishing an event: | ||
| 60 | |||
| 61 | ``` | ||
| 62 | { | ||
| 63 | "kind": 10163, | ||
| 64 | "content": "<something about the premium content, the price and other stuff, optionally>", | ||
| 65 | "tags": [ | ||
| 66 | ["url", "<payment-page-url>"] | ||
| 67 | ] | ||
| 68 | } | ||
| 69 | ``` | ||
| 70 | |||
| 71 | Where `<payment-page-url>` is a normal webpage that may have anything in it. From there on, payments are handled off-protocol. The entity that handled the payment is expected to somehow modify the list of _premium-readers_ or enable the user to modify it later. | ||
| 72 | |||
| 73 | #### Zap relationship | ||
| 74 | |||
| 75 | This NIP is payment agnostic, but that doesn't mean one shouldn't use zaps or nutzaps for this. Clients or third-party services may offer a feature to read all zaps, compute their sums according to any criteria and use that information to modify the list of _premium-readers_. | ||
| 76 | |||
| 57 | ### Future additions | 77 | ### Future additions |
| 58 | 78 | ||
| 59 | - more private list membership: perhaps doing an HMAC with the public key of the reader and a key that is shared with the relays will be enough for this. | 79 | - more private list membership: perhaps doing an HMAC with the public key of the reader and a key that is shared with the relays will be enough for this. |
| 60 | - tiered membership: custom tiers for fine-grained content access control can be added by adding more tags to the `kind:1163` event and more items to the `["nip63"]` tag. | 80 | - tiered membership: custom tiers for fine-grained content access control can be added by adding more tags to the `kind:1163` event and more items to the `["nip63"]` tag. |
| 61 | - teaser events: perhaps a `["nip63", "teaser"]` special tag could cause an event to be displayed only to those that do not have access to its premium counterpart, this would also be managed by the relay. | 81 | - teaser events: perhaps a `["nip63", "teaser"]` special tag could cause an event to be displayed only to those that do not have access to its premium counterpart, this would also be managed by the relay. |
| 82 | - relays for premium content different from the outbox relays? | ||