mirror of
https://github.com/nostr-protocol/nips.git
synced 2024-12-23 00:45:53 -05:00
78 lines
2.1 KiB
Markdown
78 lines
2.1 KiB
Markdown
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:30042` event address.
|
|
|
|
It may include one of the following tags holding a preview of the full event content:
|
|
`summary`, `image`, `audio`, `video`. The first holds a text excerpt while the others an URL.
|
|
|
|
Example:
|
|
|
|
```json
|
|
{
|
|
"kind": 1063,
|
|
"tags": [
|
|
["full_event", "30042:<32-bytes lowercase hex of a pubkey>:abc", "<recommended relay URL, optional>"],
|
|
["image", "<string with preview URI>"],
|
|
["dim", "800x600"]
|
|
],
|
|
"content": "",
|
|
...
|
|
}
|
|
```
|
|
|
|
## Full Event
|
|
|
|
A "Full Event" is of `kind:30042`. 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": 30042,
|
|
"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,
|
|
the client should request it with a filter that includes
|
|
a `#A` filter key set to the client's user pubkey.
|
|
|
|
If the user has rights to access the full event, the relay will send it
|
|
after the NIP-42 authentication flow.
|
|
|
|
For example: `{ kinds: [30042], authors: ["abc"], #d: ["xyz"], #A: ["<client's user pubkey>"], limit: 1 }`
|