1 files changed, 21 insertions, 0 deletions

diff --git a/63.md b/63.md
index fcecc98..a9c673a 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": "<something about the premium content, the price and other stuff, optionally>",
+  "tags": [
+    ["url", "<payment-page-url>"]
+  ]
+}
+```
+
+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.
+
+#### 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?