1 files changed, 24 insertions, 23 deletions

diff --git a/63.md b/63.md
index 732df18..e865f23 100644
--- a/63.md
+++ b/63.md
@@ -1,35 +1,35 @@
 NIP-63
 ======
 
-Relay-based Paywalls
---------------------
+Exclusive Content
+-----------------
 
 `draft` `optional`
 
-This NIP specifies how relays can support _paywalled content_. Well, "paywall" is a misnomer as this NIP doesn't imply payment necessarily, it's agnostic about that, so better call it **premium content**.
+This NIP specifies how to do paywalled/gated/locked/privileged/protected/paid/subscriber/restricted/premium content on Nostr.
 
-The idea is that a _content-creator_ should be able to manage a list of _premium-reader_ who have access to their premium content, then choose some specific relays to publish their content based on their known support for this NIP.
+The idea is that a _content-creator_ should be able to manage a list of _exclusive-readers_ who have access to their exclusive content, then choose some specific relays to publish their content based on their known support for this NIP.
 
 Relays that support this NIP (as they could indicate in their [NIP-11](11.md) responses) should receive the list of users and use it together with [NIP-42](42.md) authentication in order to decide what content will be readable by each requester.
 
-### Premium event
+### Exclusive event
 
-Any event can be premium, all it needs is a [NIP-70](70.md) `["-"]` tag and another tag `["nip63"]` that clearly indicates its situation.
+Any event can be _exclusive_, all it needs is a [NIP-70](70.md) `["-"]` tag and another tag `["nip63"]` that clearly indicates its status.
 
-Because normal relays won't care about these tags it's enough for the _content-creator_ to release the event to these relays in order to make it "public" to everybody.
+(Because normal relays won't care about these tags it's enough for the _content-creator_ to release the event to these relays in order to make it "public" to everybody.)
 
 ### Membership Event
 
-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.
+Membership events must be sent directly to the relays that hold the exclusive content. 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.
 
-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.
+The lists are constituted of one event for each _exclusive-reader_, and their removal/update must be done with a [NIP-09](09.md) deletion request.
 
 ```yaml
 {
   "kind": 1163,
   "pubkey": "<content-creator>",
   "tags": [
-    ["p", "<premium-reader>"]
+    ["p", "<exclusive-reader>"]
   ],
   // ...other fields
 }
@@ -50,9 +50,9 @@ Besides marking individual public keys as readers it's also possible to tag a re
 
 This allows for an easy way to, for example, automatically mark all the people the _content-creator_ follows as allowed to read. Or people who are in a specific `kind:30000` follow-set.
 
-More importantly, it allows the _content-creator_ to delegate inclusion of readers to, for example, a payment provider, such that someone can pay and immediately become a _premium-reader_ without having to wait until the _content-creator_ is online again to update sign a new event.
+More importantly, it allows the _content-creator_ to delegate inclusion of readers to, for example, a payment provider, such that someone can pay and immediately become a _exclusive-reader_ without having to wait until the _content-creator_ is online again to update sign a new event.
 
-It remains a requirement that lists referenced in `"a"` tags here are sent directly to the relays that will implement the paywall, although such relays may try to fetch those in a best-effort basis.
+It remains a requirement that lists referenced in `"a"` tags here are sent directly to the relays that hold the exclusive content, such that these relays don't have to go around trying to find such lists.
 
 ### Relay behavior
 
@@ -60,43 +60,44 @@ A relay that implements this NIP should:
 
 - signal `63` in its `supported_nips` NIP-11 field;
 - accept `kind:1163` events and not serve them to anyone except to their creator;
+- accept events referenced by `"a"` tags in `kind:1163` events it has accepted;
 - accept deletion requests for such events;
-- accept premium events containing `["-"]` and `["nip63"]` tags only from their creator;
-- only serve the premium events to users that have a matching `kind:1163`;
+- accept exclusive events containing `["-"]` and `["nip63"]` tags only from their creator;
+- only serve the exclusive events to users that have a matching `kind:1163` (directly or indirectly);
 - serve an `AUTH` challenge to any client opening a connection immediately.
 
 ### Client behavior
 
-A client doesn't have to do much in order to access premium content: if a client is already very liberal with its authentication policies it will automatically perform NIP-42 AUTH whenever it connects to the relay; otherwise it may want to check if such relay supports `63` before deciding.
+A client doesn't have to do much in order to access exclusive content: if a client is already very liberal with its authentication policies it will automatically perform NIP-42 `AUTH` whenever it connects to the relay; otherwise it may want to check if such relay supports `63` before deciding.
 
-After that, any `REQ`s should include premium content automatically and transparently. This means that while constructiing a normal "following" feed a client will get the premium content automatically and place it in front of the user.
+After that, any `REQ`s should include exclusive content automatically and transparently. This means that while constructiing a normal "following" feed a client will get the exclusive content automatically and place it in front of the user.
 
 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:
+Optionally a _content-creator_ can announce that they have exclusive content available by publishing an event:
 
-```
+```yaml
 {
   "kind": 10163,
-  "content": "<something about the premium content, the price and other stuff, optionally>",
+  "content": "<something about the exclusive 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.
+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 _exclusive-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_.
+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 _exclusive-readers_.
 
 ### Future additions
 
 - private group announcements: NIP-29 closed groups for subscribers can be announced on the `kind:10163`.
 - 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.
-- 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.
-- relays for premium content different from the outbox relays?
+- teaser events: perhaps a `["nip63", "", "-"]` (negative) tag could cause an event to be displayed only to those that do not have access to its exclusive counterpart, this would also be managed by the relay.
+- relays for exclusive content different from the outbox relays?
 - individual "pay-per-view" content.