nostr/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2024-11-09 22:09:06 -05:00
Code Issues Actions Packages Projects Releases Wiki Activity

Revise NIP-52 amendments so that they are backwards compatible

Browse Source
This commit is contained in:
Terry Yiu 2024-08-08 01:04:25 -04:00
parent 8d451b3dc3
commit d36b24c82a
No known key found for this signature in database
GPG Key ID: 108645AE8A19B71A
1 changed files with 7 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
52.md
View File

@ -187,9 +187,11 @@ This NIP is intentionally not defining who is authorized to attend a calendar ev
This NIP is also intentionally not defining what happens if a calendar event changes after an RSVP is submitted. This NIP is also intentionally not defining what happens if a calendar event changes after an RSVP is submitted.
The RSVP MUST tag the calendar event it is in response to with an `e` tag on the calendar event's id. The RSVP MUST have at least one of an `a` tag of the event coordinates to the calendar event, or `e` tag of the id of the specific calendar event revision.
The RSVP MAY tag use an `a` tag to the calendar event's event coordinates to indicate that the RSVP response could hold trueregardless of any future revisions to the calendar event. If the `a` tag is omitted, the author of the RSVP is explicitly indicating that its response holds true for only that specific revision of the calendar event from the `e` tag. If an `e` tag is present, clients SHOULD interpret it as an indication that the RSVP is a response to that revision of the calendar event.
If an `a` tag is present, clients SHOULD interpret it as an indication that the RSVP may hold true for all revisions of the calendar event.
The RSVP MAY tag the author of the calendar event it is in response to using a `p` tag so that clients can easily query all RSVPs that pertain to the author. The RSVP MAY tag the author of the calendar event it is in response to using a `p` tag so that clients can easily query all RSVPs that pertain to the author.
@ -200,12 +202,12 @@ The format uses a parameterized replaceable event kind `31925`.
The `.content` of these events is optional and should be a free-form note that adds more context to this calendar event response. The `.content` of these events is optional and should be a free-form note that adds more context to this calendar event response.
The list of tags are as follows: The list of tags are as follows:
* `e` (required) event tag to kind `31922` or `31923` calendar event being responded to. * `e` (optional) event id of a kind `31922` or `31923` calendar event being responded to. This tag is required if `a` is omitted.
* `a` (optional) reference tag to kind `31922` or `31923` calendar event being responded to. * `a` (optional) coordinates to a kind `31922` or `31923` calendar event being responded to. This tag is required if `e` is omitted.
* `d` (required) universally unique identifier. Generated by the client creating the calendar event RSVP. * `d` (required) universally unique identifier. Generated by the client creating the calendar event RSVP.
* `status` (required) `accepted`, `declined`, or `tentative`. Determines attendance status to the referenced calendar event. * `status` (required) `accepted`, `declined`, or `tentative`. Determines attendance status to the referenced calendar event.
* `fb` (optional) `free` or `busy`. Determines if the user would be free or busy for the duration of the calendar event. This tag must be omitted or ignored if the `status` label is set to `declined`. * `fb` (optional) `free` or `busy`. Determines if the user would be free or busy for the duration of the calendar event. This tag must be omitted or ignored if the `status` label is set to `declined`.
* `p` (optional) author of the calendar event being responded to. * `p` (optional) pubkey of the author of the calendar event being responded to.
```json ```json
{ {