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 "You don't have access to this event." to be showed
to users that don't have acces to the event or that are using a client that doesn't support this NIP. On the other hand,
if the goal is to convince an user 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..."

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
or simply use the `.content` (that according to NIP-94 means "caption") set to "You don't have access to this event".

Example:

```json
{
  "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](42.md) `A` tags the author
can update at will with the pubkeys allowed to access it.

It uses the custom NIP-42 event serialization for events that require `AUTH`.

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](23.md).

Example:

```json
{
  "kind": 40042,
  "pubkey": "<author_pubkey>",
  "tags": [
    ["d", "<random>"],
    ["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 }]`