nips/00.md

NIP-XX

Access Control Upgrade

draft optional

This NIP defines how to upgrade a public event with the property of limiting access to itself.

Upgrading a Public Event

A public event (with no access control), such as of kind:1, must be published or updated with a full_event tag pointing to a kind:40042 event address.

It's data should be set to a warning that the event is private or to a preview version of the full event, in case the goal is to tease an user to pay for content, for example.

For example, a kind:1 event could have it's .content set to "This event is private." to be showed to users that don't have acces to the event or that are using clients that don't support this NIP. On the other hand, if the goal is to convince viewing users to pay for the full event, the .content could be set to a text excerpt like the following: "This is the first sentence of the full text. This text is trimmed to 5% of the character count of the full text... Subscribe to read the full text".

Taking the kind:1063 metadata event of an image as an example, it could had set its url tag to a blurred version of the image and/or use the .content (that according to NIP-94 means "caption") set to "This event is private".

How the public event data will be set is entirely up to the client offering the feature that requires event access control. Such feature could be a "Publish only to Close Friends" or "Publish to Paying Subscribers", for example.

Example:

{
  "kind": 1063,
  "tags": [
    ["full_event", "40042:<32-bytes lowercase hex of a pubkey>:abc", "<recommended relay URL, optional>"],
    ["url", "<string with PREVIEW url>"],
    ["dim", "800x600"]
  ],
  "content": "",
  ...
}

Full Event

A "Full Event" is of kind:40042. It has NIP-42 A tags the author can update at will with the pubkeys allowed to access it.

The .content and other tags aren't fixed. The structure depends on the kind of the public event it is protecting. For example, if it is protecting a kind:30023 event, it should have the structure defined on NIP-23.

An interesting side effect of this being an event separate from the public one is that it doesn't need to be owned by the public event author. This way an always online bot or DVM can update the A tag list in response to a detected payment, for example.

Example of a kind:40042 event using a kind:1063 event structure:

{
  "kind": 40042,
  "pubkey": "<author_pubkey>",
  "tags": [
    ["d", "<random>"], // act as parameterized replaceable event
    ["A", "<author_pubkey>"], // important to keep author access right
    ["A", "<buyer_1_pubkey>"],
    ["A", "<buyer_2_pubkey>"],
    ["url", "https://some.place/file.webp"],
    ["dim", "800x600"]
  ],
  "content": "Happy New Year, my dear supporters!!",
  ...
}

Requesting the Event

The client is expected to initially request the public event. For example, a microblogging client will request kind:1 events as usual.

If one of these events includes a full_event tag, supporting clients should request it with a filter that includes a #A filter key set to the client's user pubkey. Clients that don't understand this NIP, however, will show the kind:1 .content as usual and ignore the full_event tag.

If the user has rights to access the full event, the relay will send it after the NIP-42 authentication flow.

Example of how to request the full event:

["REQ", "sub_id", { "kinds": [40042], "authors": ["abc"], #d: ["xyz"], "#A": ["<client's user pubkey>"], "limit": 1 }]