diff --git a/63.md b/63.md index fcecc98c..a9c673a4 100644 --- a/63.md +++ b/63.md @@ -54,8 +54,29 @@ After that, any `REQ`s should include premium content automatically and transpar A client may decide to display these events differently if they have the `["nip63"]` tag. +### Announcement + +Optionally a _content-creator_ can announce that they have premium content available by publishing an event: + +``` +{ + "kind": 10163, + "content": "", + "tags": [ + ["url", ""] + ] +} +``` + +Where `` 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. + +#### Zap relationship + +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_. + ### Future additions - 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. - 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. - 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. +- relays for premium content different from the outbox relays?