upleb.uk

Public git repos — served from a NIP-34 GRASP relay at git.upleb.uk

summaryrefslogtreecommitdiff
path: root/52.md
diff options
context:
space:
mode:
Diffstat (limited to '52.md')
-rw-r--r--52.md209
1 files changed, 209 insertions, 0 deletions
diff --git a/52.md b/52.md
new file mode 100644
index 0000000..c601412
--- /dev/null
+++ b/52.md
@@ -0,0 +1,209 @@
1NIP-52
2======
3
4Calendar Events
5---------------
6
7`draft` `optional` `author:tyiu`
8
9This specification defines calendar events representing an occurrence at a specific moment or between moments. These calendar events are replaceable and referenceable per [NIP-33](33.md) and deletable per [NIP-09](09.md).
10
11Unlike the term `calendar event` specific to this NIP, the term `event` is used broadly in all the NIPs to describe any Nostr event. The distinction is being made here to discern between the two terms.
12
13## Calendar Events
14
15There are two types of calendar events represented by different kinds: date-based and time-based calendar events. Calendar events are not required to be part of a [calendar](#calendar).
16
17### Date-Based Calendar Event
18
19This kind of calendar event starts on a date and ends before a different date in the future. Its use is appropriate for all-day or multi-day events where time and time zone hold no significance. e.g., anniversary, public holidays, vacation days.
20
21#### Format
22
23The format uses a parameterized replaceable event kind `31922`.
24
25The `.content` of these events is optional and should be a detailed description of the calendar event.
26
27The list of tags are as follows:
28* `d` (required) universally unique identifier (UUID). Generated by the client creating the calendar event.
29* `name` (required) name of the calendar event
30* `start` (required) inclusive start date in ISO 8601 format (YYYY-MM-DD). Must be less than `end`, if it exists.
31* `end` (optional) exclusive end date in ISO 8601 format (YYYY-MM-DD). If omitted, the calendar event ends on the same date as `start`.
32* `location` (optional) location of the calendar event. e.g. address, GPS coordinates, meeting room name, link to video call
33* `g` (optional) [geohash](https://en.wikipedia.org/wiki/Geohash) to associate calendar event with a searchable physical location as suggested as an example by [NIP-12](12.md)
34* `p` (optional, repeated) 32-bytes hex pubkey of a participant, optional recommended relay URL, and participant's role in the meeting
35* `t` (optional, repeated) hashtag to categorize calendar event
36* `r` (optional, repeated) references / links to web pages, documents, video calls, recorded videos, etc.
37
38```json
39{
40 "id": <32-bytes lowercase hex-encoded SHA-256 of the the serialized event data>,
41 "pubkey": <32-bytes lowercase hex-encoded public key of the event creator>,
42 "created_at": <Unix timestamp in seconds>,
43 "kind": "31922",
44 "content": "<description of calendar event>",
45 "tags": [
46 ["d", "<UUID>"],
47
48 ["name", "<name of calendar event>"],
49
50 // Dates
51 ["start", "<YYYY-MM-DD>"],
52 ["end", "<YYYY-MM-DD>"],
53
54 // Location
55 ["location", "<location>"],
56 ["g", "<geohash>"],
57
58 // Participants
59 ["p", "<32-bytes hex of a pubkey>", "<optional recommended relay URL>", "<role>"],
60 ["p", "<32-bytes hex of a pubkey>", "<optional recommended relay URL>", "<role>"],
61
62 // Hashtags
63 ["t", "<tag>"],
64 ["t", "<tag>"],
65
66 // Reference links
67 ["r", "<url>"],
68 ["r", "<url>"]
69 ]
70}
71```
72
73### Time-Based Calendar Event
74
75This kind of calendar event spans between a start time and end time.
76
77#### Format
78
79The format uses a parameterized replaceable event kind `31923`.
80
81The `.content` of these events is optional and should be a detailed description of the calendar event.
82
83The list of tags are as follows:
84* `d` (required) universally unique identifier (UUID). Generated by the client creating the calendar event.
85* `name` (required) name of the calendar event
86* `start` (required) inclusive start Unix timestamp in seconds. Must be less than `end`, if it exists.
87* `end` (optional) exclusive end Unix timestamp in seconds. If omitted, the calendar event ends instantaneously.
88* `start_tzid` (optional) time zone of the start timestamp, as defined by the IANA Time Zone Database. e.g., `America/Costa_Rica`
89* `end_tzid` (optional) time zone of the end timestamp, as defined by the IANA Time Zone Database. e.g., `America/Costa_Rica`. If omitted and `start_tzid` is provided, the time zone of the end timestamp is the same as the start timestamp.
90* `location` (optional) location of the calendar event. e.g. address, GPS coordinates, meeting room name, link to video call
91* `g` (optional) [geohash](https://en.wikipedia.org/wiki/Geohash) to associate calendar event with a searchable physical location as suggested as an example by [NIP-12](12.md)
92* `p` (optional, repeated) 32-bytes hex pubkey of a participant, optional recommended relay URL, and participant's role in the meeting
93* `t` (optional, repeated) hashtag to categorize calendar event
94* `r` (optional, repeated) references / links to web pages, documents, video calls, recorded videos, etc.
95
96```json
97{
98 "id": <32-bytes lowercase hex-encoded SHA-256 of the the serialized event data>,
99 "pubkey": <32-bytes lowercase hex-encoded public key of the event creator>,
100 "created_at": <Unix timestamp in seconds>,
101 "kind": "31923",
102 "content": "<description of calendar event>",
103 "tags": [
104 ["d", "<UUID>"],
105
106 ["name", "<name of calendar event>"],
107
108 // Timestamps
109 ["start", "<Unix timestamp in seconds>"],
110 ["end", "<Unix timestamp in seconds>"],
111
112 ["start_tzid", "<IANA Time Zone Database identifier>"],
113 ["end_tzid", "<IANA Time Zone Database identifier>"],
114
115 // Location
116 ["location", "<location>"],
117 ["g", "<geohash>"],
118
119 // Participants
120 ["p", "<32-bytes hex of a pubkey>", "<optional recommended relay URL>", "<role>"],
121 ["p", "<32-bytes hex of a pubkey>", "<optional recommended relay URL>", "<role>"],
122
123 // Hashtags
124 ["t", "<tag>"],
125 ["t", "<tag>"],
126
127 // Reference links
128 ["r", "<url>"],
129 ["r", "<url>"]
130 ]
131}
132```
133
134## Calendar
135
136A calendar is a collection of calendar events, represented as a custom replaceable list event using kind `31924`. A user can have multiple calendars. One may create a calendar to segment calendar events for specific purposes. e.g., personal, work, travel, meetups, and conferences.
137
138### Format
139
140The format uses a custom replaceable list of kind `31924` with a list of tags as described below:
141* `d` (required) calendar name
142* `a` (repeated) reference tag to kind `31922` or `31923` calendar event being responded to per [NIP-33](33.md)
143
144```json
145{
146 "kind": 31924,
147 "tags": [
148 ["d", "<calendar name>"],
149 ["a", "<31922 or 31923>:<calendar event author pubkey>:<d-identifier of calendar event>", "<optional relay url>"],
150 ["a", "<31922 or 31923>:<calendar event author pubkey>:<d-identifier of calendar event>", "<optional relay url>"]
151 ]
152}
153```
154
155## Calendar Event RSVP
156
157A calendar event RSVP is a response to a calendar event to indicate a user's attendance intention.
158
159If a calendar event tags a pubkey, that can be interpreted as the calendar event creator inviting that user to attend. Clients MAY choose to prompt the user to RSVP for the calendar event.
160
161Any user may RSVP, even if they were not tagged on the calendar event. Clients MAY choose to prompt the calendar event creator to invite the user who RSVP'd. Clients also MAY choose to ignore these RSVPs.
162
163This NIP is intentionally not defining who is authorized to attend a calendar event if the user who RSVP'd has not been tagged. It is up to the calendar event creator to determine the semantics.
164
165This NIP is also intentionally not defining what happens if a calendar event changes after an RSVP is submitted.
166
167### Format
168
169The format uses a parameterized replaceable event kind `31925`.
170
171The `.content` of these events is optional and should be a free-form note that adds more context to this calendar event response.
172
173The list of tags are as follows:
174* `a` (required) reference tag to kind `31922` or `31923` calendar event being responded to per [NIP-33](33.md)
175* `d` (required) universally unique identifier. Generated by the client creating the calendar event RSVP.
176* `L` (required) label namespace of `status` per [NIP-32](32.md)
177* `l` (required) label of `accepted`, `declined`, or `tentative` under the label namespace of `status` per [NIP-32](32.md). Determines attendance status to the referenced calendar event.
178* `L` (optional) label namespace of `freebusy` per [NIP-32](32.md). Exists if and only if corresponding `l` tag under the same label namespace exists.
179* `l` (optional) label of `free` or `busy` under the label namespace of `freebusy` per [NIP-32](32.md). 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`. Exists if and only if corresponding `l` tag under the same label namespace exists.
180
181```json
182{
183 "id": <32-bytes lowercase hex-encoded SHA-256 of the the serialized event data>,
184 "pubkey": <32-bytes lowercase hex-encoded public key of the event creator>,
185 "created_at": <Unix timestamp in seconds>,
186 "kind": "31925",
187 "content": "<note>",
188 "tags": [
189 ["a", "<31922 or 31923>:<calendar event author pubkey>:<d-identifier of calendar event>", "<optional relay url>"],
190 ["d", "<UUID>"],
191 ["L", "status"],
192 ["l", "<accepted/declined/tentative>", "status"],
193 ["L", "freebusy"],
194 ["l", "<free/busy>", "freebusy"]
195 ]
196}
197```
198
199## Unsolved Limitations
200
201* No private events
202
203## Intentionally Unsupported Scenarios
204
205### Recurring Calendar Events
206
207Recurring calendar events come with a lot of complexity, making it difficult for software and humans to deal with. This complexity includes time zone differences between invitees, daylight savings, leap years, multiple calendar systems, one-off changes in schedule or other metadata, etc.
208
209This NIP intentionally omits support for recurring calendar events and pushes that complexity up to clients to manually implement if they desire. i.e., individual calendar events with duplicated metadata represent recurring calendar events.