From b565e7020200f199198c5d901ea4f62b01d6b954 Mon Sep 17 00:00:00 2001 From: kehiy Date: Thu, 12 Sep 2024 17:27:46 +0330 Subject: [PATCH] update: charset and uuids --- 29.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/29.md b/29.md index 43817a1..82e7e75 100644 --- a/29.md +++ b/29.md @@ -10,14 +10,16 @@ This NIP defines a standard for groups that are only writable by a closed set of Groups are identified by a random string of any length that serves as an _id_, generated by client. -_id_: is restricted to the characters `a-z0-9-_.`, case-insensitive. +_id_: is restricted to the characters `a-z0-9-_`, case-insensitive. -the relays MUST decide to reject creation of a group if an _id_ issued by client is not following the above restriction or MAY reject the creation if it's already exist or that's not acceptable based on their policies. (e.g. length of _id_ is too long). +The relays MUST decide to reject creation of a group if an _id_ issued by client is not following the above restriction or MAY reject the creation if it's already exist or that's not acceptable based on their policies. (e.g. length of _id_ is too long). There is no way to create a group, what happens is just that relays (most likely when asked by users) will create rules around some specific ids so these ids can serve as an actual group, henceforth messages sent to that group will be subject to these rules. Normally a group will originally belong to one specific relay, but the community may choose to move the group to other relays or even fork the group so it exists in different forms -- still using the same _id_ -- across different relays. +Since relays can reject a specific _id_ based on their policies or when it's already exist, it's RECOMMENDED to use UUIDs for this purpose. + ## Relay-generated events Relays are supposed to generate the events that describe group metadata and group admins. These are _addressable_ events signed by the relay keypair directly, with the group _id_ as the `d` tag.