diff options
| author | fiatjaf <fiatjaf@gmail.com> | 2025-12-12 01:41:02 -0300 |
|---|---|---|
| committer | fiatjaf <fiatjaf@gmail.com> | 2026-02-02 00:08:24 -0300 |
| commit | cef73cc4218801c5740e7a0de112378dac05bf97 (patch) | |
| tree | d473b12233d79e49f0468e398caaf5f7b3046c6b /63.md | |
| parent | 92cac52f1c4a05d5286418886f72d88c8e70b0ef (diff) | |
fix grammar and clarify future stuff.
Diffstat (limited to '63.md')
| -rw-r--r-- | 63.md | 6 |
1 files changed, 3 insertions, 3 deletions
| @@ -20,7 +20,7 @@ Because normal relays won't care about these tags it's enough for the _content-c | |||
| 20 | 20 | ||
| 21 | ### Membership Event | 21 | ### Membership Event |
| 22 | 22 | ||
| 23 | Membership events must be sent directly to the relays that will implement the paywall. By default relays should not serve these events to anyone, only to the _content-creator_ directly. Because of this, these lists can be kept reasonably private as long as the _content-creator_ is discrete in their publishing, but can also be made public by being published to other relays. | 23 | Membership events must be sent directly to the relays that will implement the paywall. By default relays should not serve these events to anyone, only to the _content-creator_ directly. Because of this, these lists can be kept reasonably private as long as the _content-creator_ is discreet in his publishing, but can also be made public by being published to other relays. |
| 24 | 24 | ||
| 25 | The lists are constituted of one event for each _premium-reader_, and their removal/update must be done with a [NIP-09](09.md) deletion request. | 25 | The lists are constituted of one event for each _premium-reader_, and their removal/update must be done with a [NIP-09](09.md) deletion request. |
| 26 | 26 | ||
| @@ -77,6 +77,6 @@ This NIP is payment agnostic, but that doesn't mean one shouldn't use zaps or nu | |||
| 77 | ### Future additions | 77 | ### Future additions |
| 78 | 78 | ||
| 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. | 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. |
| 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. | 80 | - tiered membership: custom tiers for fine-grained content access control can be added by adding a tag like `["tier", "a"]` to the `kind:1163` event and using a `["nip63", "a"]` tag in the events, for example. |
| 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. | 81 | - teaser events: perhaps a `["nip63", "", "-"]` (negative) 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? | 82 | - relays for premium content different from the outbox relays? |