upleb.uk

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

summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--01.md5
-rw-r--r--16.md5
-rw-r--r--22.md3
3 files changed, 9 insertions, 4 deletions
diff --git a/01.md b/01.md
index f503860..8d16433 100644
--- a/01.md
+++ b/01.md
@@ -98,10 +98,7 @@ This NIP defines no rules for how `NOTICE` messages should be sent or treated.
98## Basic Event Kinds 98## Basic Event Kinds
99 99
100 - `0`: `set_metadata`: the `content` is set to a stringified JSON object `{name: <username>, about: <string>, picture: <url, string>}` describing the user who created the event. A relay may delete past `set_metadata` events once it gets a new one for the same pubkey. 100 - `0`: `set_metadata`: the `content` is set to a stringified JSON object `{name: <username>, about: <string>, picture: <url, string>}` describing the user who created the event. A relay may delete past `set_metadata` events once it gets a new one for the same pubkey.
101 * Where `<username>` is a string that matches the pattern: `\w[\w\-]+\w` (java regular expression). Or, in other words, a sequence of the following 101 - `1`: `text_note`: the `content` is set to the text content of a note (anything the user wants to say). Non-plaintext notes should instead use kind 1000-10000 as described in [NIP-16](16.md).
102 characters: `[a-zA-Z_0-9][a-zA-Z_\-0-9]+[a-zA-Z_0-9]`. <br>
103 Thus `George-Washington-1776` is a valid `<username>`, but `George Washington` is not. Clients may reject metadata that does not comply.
104 - `1`: `text_note`: the `content` is set to the text content of a note (anything the user wants to say).
105 - `2`: `recommend_server`: the `content` is set to the URL (e.g., `https://somerelay.com`) of a relay the event creator wants to recommend to its followers. 102 - `2`: `recommend_server`: the `content` is set to the URL (e.g., `https://somerelay.com`) of a relay the event creator wants to recommend to its followers.
106 103
107A relay may choose to treat different message kinds differently, and it may or may not choose to have a default way to handle kinds it doesn't know about. 104A relay may choose to treat different message kinds differently, and it may or may not choose to have a default way to handle kinds it doesn't know about.
diff --git a/16.md b/16.md
index c34452d..80a6b3d 100644
--- a/16.md
+++ b/16.md
@@ -8,6 +8,11 @@ Event Treatment
8 8
9Relays may decide to allow replaceable and/or ephemeral events. 9Relays may decide to allow replaceable and/or ephemeral events.
10 10
11Regular Events
12------------------
13A *regular event* is defined as an event with a kind `1000 <= n < 10000`.
14Upon a regular event being received, the relay SHOULD send it to all clients with a matching filter, and SHOULD store it. New events of the same kind do not affect previous events in any way.
15
11Replaceable Events 16Replaceable Events
12------------------ 17------------------
13A *replaceable event* is defined as an event with a kind `10000 <= n < 20000`. 18A *replaceable event* is defined as an event with a kind `10000 <= n < 20000`.
diff --git a/22.md b/22.md
index e4cea51..9ab601d 100644
--- a/22.md
+++ b/22.md
@@ -26,6 +26,9 @@ The event `created_at` field is just a unix timestamp and can be set to a time i
26 26
27A wide adoption of this nip could create a better user experience as it would decrease the amount of events that appear wildly out of order or even from impossible dates in the distant past or future. 27A wide adoption of this nip could create a better user experience as it would decrease the amount of events that appear wildly out of order or even from impossible dates in the distant past or future.
28 28
29Keep in mind that there is a use case where a user migrates their old posts onto a new relay. If a relay rejects events that were not recently created, it cannot serve this use case.
30
31
29Python Example 32Python Example
30-------------- 33--------------
31 34