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:

```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.

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).

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:

```json
{
  "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 }]`