From 40ec29f826977e0622f4040864bec0605f85e2dc Mon Sep 17 00:00:00 2001 From: Niel Liesmons <130457889+NielLiesmons@users.noreply.github.com> Date: Tue, 4 Mar 2025 16:26:29 +0100 Subject: [PATCH 1/4] NIP-C0: Communi-keys --- C0.md | 138 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 138 insertions(+) create mode 100644 C0.md diff --git a/C0.md b/C0.md new file mode 100644 index 0000000000..5cb67272af --- /dev/null +++ b/C0.md @@ -0,0 +1,138 @@ +NIP-C0 +====== + +Communi-keys +------------------------------------------------- + +`draft` `optional` + +This NIP defines a standard for creating, managing and publishing to communities by leveraging existing key pairs and relays, introducing the concept of "Communi-keys". This approach allows any existing npub to become a community (identity + manager) while maintaining compatibility with existing relay infrastructure. + +## Motivation + +Current community management solutions on Nostr often require complex relay-specific implementations, lack proper decentralization and don't allow publications to be targeted at more than one community. + +This proposal aims to simplify community management by utilizing existing Nostr primitives (key pairs and relays) while adding minimal new event kinds. + +## Specification + +### Community Creation Event + +A community is created when a key pair publishes a `kind:32221` event with the following structure: + +```json +{ + "kind": 32221, + "content": "", + "tags": [ + ["relay", ""], + ["relay", "", "backup"], + ["relay", "", "backup"], + ["blossom", ""], + ["blossom", "", "backup"], + ["p", "", ""], + ["mint", ""], + ["welcome", ""] + ] +} +``` + +Tag definitions: +- `relay`: URLs of relays where community content should be published. First one is considered main relay. +- `blossom`: URLs of blossom servers for additional community features (optional). +- `p`: Community role assignments. Multiple allowed. Format: `["p", "", ""]`. +- `mint`: URL of community mint for token/payment features (optional). +- `welcome`: Event ID of a welcome/introduction post (optional). + +The pubkey of the key pair that creates this event serves as the unique identifier for the community. This means: +1. Each key pair can only represent one community +2. Communities can be easily discovered by querying for the most recent `kind:32221` event for a given pubkey +3. Community managers can update their settings by publishing a new `kind:32221` event + +### Community Identifier Format + +Communities can be referenced using an "ncommunity" format: +`ncommunity://?relay=&relay=` + +This format follows the same principles as nprofile, but specifically for community identification. While the ncommunity format is recommended for complete relay information, the standard pubkey format can also be used when relay discovery is not needed. + + +### Targeted Publication Event + +To target an existing publication at specific communities, users create a `kind:32222` event: + +```json +{ + "kind": 32222, + "content": "", + "tags": [ + ["e", ""], + ["p", ""], + ["c", ""], + ["r", ""] + ] +} +``` + +The event must be found on the community's specified main relay to be considered valid. The `e` tag references the original publication event that is being targeted at the communities. Communities can be referenced either using: +- The `p` tag with the community's pubkey (for simple cases where relay discovery is not needed) +- The `c` tag with a bech32-encoded ncommunity identifier (which includes both the community pubkey and its relay information) + +### Community Chat Messages + +For chat messages within a community, users should use `kind:9` events with a community tag: + +```json +{ + "kind": 9, + "content": "", + "tags": [ + ["h", ""] + ] +} +``` + +## Implementation Notes + + +1. Clients SHOULD verify that targeted publications (`kind:32222`) are present on the community's main relays. The main relay specified in the community creation event SHOULD be considered authoritative for community-related events. Clients MAY, however, fall back on a backup relay (as the authority) when the main relay is offline. +2. Clients MAY cache community metadata (`kind:30003`) events to reduce relay queries. +3. Relay operators MAY implement/automate additional filtering or moderation based on community specifications. +4. When encountering a `p` tag without corresponding relay information, clients SHOULD attempt to discover the community's relays through other means (e.g., known community relays, cached metadata). + +## Benefits + +1. Any existing npub can become a community +2. Communities are not permanently tied to specific relays +3. Simplified relay operator implementation compared to other community proposals +4. Supports relay-per-community model while remaining flexible +5. Enables cross-community interaction through targeted publications +6. Flexible referencing allows for both simple and complete community identification + +## Security Considerations + +1. Clients MUST verify event signatures from community managers +2. Relays SHOULD implement rate limiting for community-related events +3. Clients SHOULD respect the relay hierarchy specified in community creation events +4. When using simple pubkey references, clients should be aware of potential relay discovery challenges + +## Use Case for Private Groups and DMs + +The Communi-keys structure naturally extends to private groups and DMs by leveraging relay-side authentication: + +### Private Groups +- The community's profile metadata and relay address remain publicly readable +- All content (chats, posts, articles, polls, etc.) is only readable by npubs that meet the group's conditions +- The relay handles authentication and access control based on the community's member list +- Perfect for team channels, private clubs, or any group that needs controlled access + +### Direct Messages (DMs) +- A DM is simply a private group of two people +- The npub representing the DM "room" doesn't need public metadata +- Clients can display the room using the other participant's name +- The room's npub can be stored locally or in encrypted form elsewhere for multi-device access +- Provides a clean separation between the chat identity and the participants' identities + +This approach unifies community, group, and DM management under a single model while maintaining privacy through relay-side authentication. + + From 5adcdda2e6030f5e9fb420aecfebd1d9762a9625 Mon Sep 17 00:00:00 2001 From: Niel Liesmons <130457889+NielLiesmons@users.noreply.github.com> Date: Tue, 4 Mar 2025 16:28:57 +0100 Subject: [PATCH 2/4] Add NIP-C0: Communi-keys --- C0.md | 135 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 135 insertions(+) create mode 100644 C0.md diff --git a/C0.md b/C0.md new file mode 100644 index 0000000000..3a6401fb59 --- /dev/null +++ b/C0.md @@ -0,0 +1,135 @@ +NIP-C0 +====== + +Communi-keys +------------------------------------------------- + +`draft` `optional` + +This NIP defines a standard for creating, managing and publishing to communities by leveraging existing key pairs and relays, introducing the concept of "Communi-keys". This approach allows any existing npub to become a community (identity + manager) while maintaining compatibility with existing relay infrastructure. + +## Motivation + +Current community management solutions on Nostr often require complex relay-specific implementations, lack proper decentralization and don't allow publications to be targeted at more than one community. + +This proposal aims to simplify community management by utilizing existing Nostr primitives (key pairs and relays) while adding minimal new event kinds. + +## Specification + +### Community Creation Event + +A community is created when a key pair publishes a `kind:32221` event with the following structure: + +```json +{ + "kind": 32221, + "content": "", + "tags": [ + ["relay", ""], + ["relay", "", "backup"], + ["relay", "", "backup"], + ["blossom", ""], + ["blossom", "", "backup"], + ["p", "", ""], + ["mint", ""], + ["welcome", ""] + ] +} +``` + +Tag definitions: +- `relay`: URLs of relays where community content should be published. First one is considered main relay. +- `blossom`: URLs of blossom servers for additional community features (optional). +- `p`: Community role assignments. Multiple allowed. Format: `["p", "", ""]`. +- `mint`: URL of community mint for token/payment features (optional). +- `welcome`: Event ID of a welcome/introduction post (optional). + +The pubkey of the key pair that creates this event serves as the unique identifier for the community. This means: +1. Each key pair can only represent one community +2. Communities can be easily discovered by querying for the most recent `kind:32221` event for a given pubkey +3. Community managers can update their settings by publishing a new `kind:32221` event + +### Community Identifier Format + +Communities can be referenced using an "ncommunity" format: +`ncommunity://?relay=&relay=` + +This format follows the same principles as nprofile, but specifically for community identification. While the ncommunity format is recommended for complete relay information, the standard pubkey format can also be used when relay discovery is not needed. + + +### Targeted Publication Event + +To target an existing publication at specific communities, users create a `kind:32222` event: + +```json +{ + "kind": 32222, + "content": "", + "tags": [ + ["e", ""], + ["p", ""], + ["c", ""], + ["r", ""] + ] +} +``` + +The event must be found on the community's specified main relay to be considered valid. The `e` tag references the original publication event that is being targeted at the communities. Communities can be referenced either using: +- The `p` tag with the community's pubkey (for simple cases where relay discovery is not needed) +- The `c` tag with a bech32-encoded ncommunity identifier (which includes both the community pubkey and its relay information) + +### Community Chat Messages + +For chat messages within a community, users should use `kind:9` events with a community tag: + +```json +{ + "kind": 9, + "content": "", + "tags": [ + ["h", ""] + ] +} +``` + +## Implementation Notes + + +1. Clients SHOULD verify that targeted publications (`kind:32222`) are present on the community's main relays. The main relay specified in the community creation event SHOULD be considered authoritative for community-related events. Clients MAY, however, fall back on a backup relay (as the authority) when the main relay is offline. +2. Clients MAY cache community metadata (`kind:30003`) events to reduce relay queries. +3. Relay operators MAY implement/automate additional filtering or moderation based on community specifications. +4. When encountering a `p` tag without corresponding relay information, clients SHOULD attempt to discover the community's relays through other means (e.g., known community relays, cached metadata). + +## Benefits + +1. Any existing npub can become a community +2. Communities are not permanently tied to specific relays +3. Simplified relay operator implementation compared to other community proposals +4. Supports relay-per-community model while remaining flexible +5. Enables cross-community interaction through targeted publications +6. The abilty to target publications to more than one community and the access to any desired content type eliminates the need for #channels or rooms +7. Flexible referencing allows for both simple and complete community identification + +## Security Considerations + +1. Clients MUST verify event signatures from community managers +2. Relays SHOULD implement rate limiting for community-related events +3. Clients SHOULD respect the relay hierarchy specified in community creation events +4. When using simple pubkey references, clients should be aware of potential relay discovery challenges + +## Use Case for Private Groups and DMs + +The Communi-keys structure naturally extends to private groups and DMs by leveraging relay-side authentication: + +### Private Groups +- The community's profile metadata and relay address remain publicly readable +- All content (chats, posts, articles, polls, etc.) is only readable by npubs that meet the group's conditions + +### Direct Messages (DMs) +- DMs are simply a private groups of two +- The npub representing the DM "room" doesn't need public metadata +- Clients can display the room using the other participant's name +- The room's npub can be stored locally or in encrypted form elsewhere for multi-device access +- Provides a clean separation between the chat identity and the participants' identities + +This approach unifies community, group, and DM management under a single model while maintaining privacy through relay-side authentication. From f1fd0236a3c3798d12f79761eb3a9126035a8139 Mon Sep 17 00:00:00 2001 From: Niel Liesmons <130457889+NielLiesmons@users.noreply.github.com> Date: Tue, 27 May 2025 12:34:39 +0200 Subject: [PATCH 3/4] Updated to latest working version --- C0.md | 138 ----------------------------------------------- CC.md | 171 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 171 insertions(+), 138 deletions(-) delete mode 100644 C0.md create mode 100644 CC.md diff --git a/C0.md b/C0.md deleted file mode 100644 index 5cb67272af..0000000000 --- a/C0.md +++ /dev/null @@ -1,138 +0,0 @@ -NIP-C0 -====== - -Communi-keys -------------------------------------------------- - -`draft` `optional` - -This NIP defines a standard for creating, managing and publishing to communities by leveraging existing key pairs and relays, introducing the concept of "Communi-keys". This approach allows any existing npub to become a community (identity + manager) while maintaining compatibility with existing relay infrastructure. - -## Motivation - -Current community management solutions on Nostr often require complex relay-specific implementations, lack proper decentralization and don't allow publications to be targeted at more than one community. - -This proposal aims to simplify community management by utilizing existing Nostr primitives (key pairs and relays) while adding minimal new event kinds. - -## Specification - -### Community Creation Event - -A community is created when a key pair publishes a `kind:32221` event with the following structure: - -```json -{ - "kind": 32221, - "content": "", - "tags": [ - ["relay", ""], - ["relay", "", "backup"], - ["relay", "", "backup"], - ["blossom", ""], - ["blossom", "", "backup"], - ["p", "", ""], - ["mint", ""], - ["welcome", ""] - ] -} -``` - -Tag definitions: -- `relay`: URLs of relays where community content should be published. First one is considered main relay. -- `blossom`: URLs of blossom servers for additional community features (optional). -- `p`: Community role assignments. Multiple allowed. Format: `["p", "", ""]`. -- `mint`: URL of community mint for token/payment features (optional). -- `welcome`: Event ID of a welcome/introduction post (optional). - -The pubkey of the key pair that creates this event serves as the unique identifier for the community. This means: -1. Each key pair can only represent one community -2. Communities can be easily discovered by querying for the most recent `kind:32221` event for a given pubkey -3. Community managers can update their settings by publishing a new `kind:32221` event - -### Community Identifier Format - -Communities can be referenced using an "ncommunity" format: -`ncommunity://?relay=&relay=` - -This format follows the same principles as nprofile, but specifically for community identification. While the ncommunity format is recommended for complete relay information, the standard pubkey format can also be used when relay discovery is not needed. - - -### Targeted Publication Event - -To target an existing publication at specific communities, users create a `kind:32222` event: - -```json -{ - "kind": 32222, - "content": "", - "tags": [ - ["e", ""], - ["p", ""], - ["c", ""], - ["r", ""] - ] -} -``` - -The event must be found on the community's specified main relay to be considered valid. The `e` tag references the original publication event that is being targeted at the communities. Communities can be referenced either using: -- The `p` tag with the community's pubkey (for simple cases where relay discovery is not needed) -- The `c` tag with a bech32-encoded ncommunity identifier (which includes both the community pubkey and its relay information) - -### Community Chat Messages - -For chat messages within a community, users should use `kind:9` events with a community tag: - -```json -{ - "kind": 9, - "content": "", - "tags": [ - ["h", ""] - ] -} -``` - -## Implementation Notes - - -1. Clients SHOULD verify that targeted publications (`kind:32222`) are present on the community's main relays. The main relay specified in the community creation event SHOULD be considered authoritative for community-related events. Clients MAY, however, fall back on a backup relay (as the authority) when the main relay is offline. -2. Clients MAY cache community metadata (`kind:30003`) events to reduce relay queries. -3. Relay operators MAY implement/automate additional filtering or moderation based on community specifications. -4. When encountering a `p` tag without corresponding relay information, clients SHOULD attempt to discover the community's relays through other means (e.g., known community relays, cached metadata). - -## Benefits - -1. Any existing npub can become a community -2. Communities are not permanently tied to specific relays -3. Simplified relay operator implementation compared to other community proposals -4. Supports relay-per-community model while remaining flexible -5. Enables cross-community interaction through targeted publications -6. Flexible referencing allows for both simple and complete community identification - -## Security Considerations - -1. Clients MUST verify event signatures from community managers -2. Relays SHOULD implement rate limiting for community-related events -3. Clients SHOULD respect the relay hierarchy specified in community creation events -4. When using simple pubkey references, clients should be aware of potential relay discovery challenges - -## Use Case for Private Groups and DMs - -The Communi-keys structure naturally extends to private groups and DMs by leveraging relay-side authentication: - -### Private Groups -- The community's profile metadata and relay address remain publicly readable -- All content (chats, posts, articles, polls, etc.) is only readable by npubs that meet the group's conditions -- The relay handles authentication and access control based on the community's member list -- Perfect for team channels, private clubs, or any group that needs controlled access - -### Direct Messages (DMs) -- A DM is simply a private group of two people -- The npub representing the DM "room" doesn't need public metadata -- Clients can display the room using the other participant's name -- The room's npub can be stored locally or in encrypted form elsewhere for multi-device access -- Provides a clean separation between the chat identity and the participants' identities - -This approach unifies community, group, and DM management under a single model while maintaining privacy through relay-side authentication. - - diff --git a/CC.md b/CC.md new file mode 100644 index 0000000000..5a066ae00b --- /dev/null +++ b/CC.md @@ -0,0 +1,171 @@ +# NIP-CC: Communi-keys + +This NIP defines a standard for creating, managing and publishing to communities by leveraging existing key pairs and relays. + +This approach uniquely allows: + +* any existing npub to become a community (identity + manager). +* any existing publication to be targeted at any community. +* communities to have their own selected content types. + +## Motivation + +Current community management solutions on Nostr often require complex relay-specific implementations, lack proper decentralization and don't allow publications to be targeted at more than one community. + +This proposal aims to simplify community management by utilizing existing Nostr primitives (key pairs and relays) while adding minimal new event kinds. + +## Specification + +### Community Creation Event + +A community is created when a key pair publishes a `kind:10222` event. The pubkey of this key pair becomes the unique identifier for that community. One key pair can only represent one community. + +The community's name, picture, and description are derived from the pubkey's `kind:0` metadata event. + +```json +{ + "kind": 10222, + // The name, picture and description of the community are derived from the pubkey's kind 0 + "pubkey": , + "tags": [ + // at least one relay for the community + ["r", ], + + // one or more blossom servers + ["blossom", ], + + // one or more ecash mints + ["mint", , "cashu"], + + // one or more content sections: ["content", ] + ["content", "Chat"], + ["k", "9"], + + ["content", "Post"], + ["k", "1"], + ["k", "11"], + ["fee", "10", "sat"], + ["exclusive", "true"], // true if this event kind can ONLY be targeted to this community, not others + + ["content", "Article"], + ["k", "30023"], + ["k", "30040"], + ["role", "admin", "team"] // only admins and team can post Articles + + // Optional terms of service, points to another event + ["tos", , ], + + // Optional location + ["location", ""], + ["g", ""], + + // Optional description + ["description", "A description text that overwrites the profile's description, if needed"], + ] +} +``` + +#### Tag definitions + +| Tag | Description | +|-----|-------------| +| r | URLs of relays where community content should be published. First one is considered main relay. | +| blossom | URLs of blossom servers for additional community features (optional). | +| mint | URL of community mint for token/payment features (optional). | +| content | Name of Content Type section that the Communikey works with | +| k | Event kind, within a content type section. | +| retention | Retention policy in format [kind, value, type] where type is either "time" (seconds) or "count" (number of events). | +| fee | Admission fee in format [kind, amount, unit] where unit is typically "msats". | +| exclusive | boolean that specifies if this content type can be targeted to other communities too. | +| role | Publishing permission in format [kind, role1, role2, ...] where roles are plain text labels like "admin", "team", "CEO", etc. | +| tos | URL to the community's posting policy. | +| location | Location of the community. | +| g | Geo hash of the community. | +| description | Description of the community. | + +The pubkey of the key pair that creates this event serves as the unique identifier for the community. This means: + +1. Each key pair can only represent one community +2. Communities can be easily discovered by querying for the most recent `kind:10222` event for a given pubkey +3. Community managers can update their settings by publishing a new `kind:10222` event + +### Community Identifier Format + +Communities can be referenced using an "ncommunity" format: + +``` +ncommunity://?relay=&relay= +``` + +This format follows the same principles as nprofile, but specifically for community identification. While the ncommunity format is recommended for complete relay information, the standard pubkey format can also be used when relay discovery is not needed. + +### Targeted Publication Event + +To target an existing publication at specific communities, users create a `kind:30222` event: + +```json +{ + "kind": 30222, + "content": "", + "tags": [ + ["d", ""], // or maybe equate to "e" tag, but then we run into trouble for the "a" tags + ["e" , ""], // Or ["a" , ""] + ["k", ""], + ["p", ""], + ["r", ""] + ] +} +``` + +The targeted publication event can reference the original publication in two ways: +1. Using an `e` tag with the event ID, relay hint, and pubkey hint +2. Using an `a` tag with the event address and relay hint + +The `k` tag specifies the kind of the original publication, and the `p` tags list the communities that this publication is targeting. + +**IMPORTANT**: For publishing new events clients SHOULD create a targeted Publication event first (that only has an id) and reference it with an h-tag in the main event. + +### Community-Exclusive Publications + +Some content types should be exclusive by default: Chat, Labels, Forum, ... + +For these we don't need a Targeted Publication event and can just use an h-tag instead. + +For chat messages within a community, users should use `kind:9` events with a community tag: + +```json +{ + "kind": 9, + "content": "", + "tags": [ + ["h", ""] + ] +} +``` + +The same pattern applies to Labels, Forum posts, ... + +## Implementation Notes + +1. Clients SHOULD verify that targeted publications (`kind:32222`) are present on the community's main relays. The main relay specified in the community creation event SHOULD be considered authoritative for community-related events. Clients MAY, however, fall back on a backup relay (as the authority) when the main relay is offline. +2. Clients MAY cache community metadata events to reduce relay queries. +3. Relay operators MAY implement/automate additional filtering or moderation based on community specifications. + +## Benefits + +1. Any existing npub can become a community +2. Communities are not permanently tied to specific relays +3. Simplified relay operator implementation compared to other community proposals +4. Supports relay-per-community model while remaining flexible +5. Enables cross-community interaction through targeted publications +6. The ability to target publications to more than one community and the access to any desired content type eliminates the need for #channels or rooms +7. Flexible referencing allows for both simple and complete community identification + +## Security Considerations + +1. Clients MUST verify event signatures from community managers +2. Relays SHOULD implement rate limiting for community-related events +3. Clients SHOULD respect the relay hierarchy specified in community creation events +4. When using simple pubkey references, clients should be aware of potential relay discovery challenges + + From ca3863a539a9fc3a41eccba8a78f6e26935d4d48 Mon Sep 17 00:00:00 2001 From: Niel Liesmons <130457889+NielLiesmons@users.noreply.github.com> Date: Tue, 27 May 2025 12:46:21 +0200 Subject: [PATCH 4/4] Deeleted C0 --- C0.md | 204 ---------------------------------------------------------- 1 file changed, 204 deletions(-) delete mode 100644 C0.md diff --git a/C0.md b/C0.md deleted file mode 100644 index f405d44090..0000000000 --- a/C0.md +++ /dev/null @@ -1,204 +0,0 @@ -NIP-C0 -====== - -<<<<<<< HEAD -Code Snippets -------------- - -`draft` `optional` - -## Abstract - -This NIP defines a new event kind for sharing and storing code snippets. Unlike regular text notes (`kind:1`), code snippets have specialized metadata like language, extension, and other code-specific attributes that enhance discoverability, syntax highlighting, and improved user experience. - -## Event Kind - -This NIP defines `kind:1337` as a code snippet event. - -The `.content` field contains the actual code snippet text. - -## Optional Tags - -- `l` - Programming language name (lowercase). Examples: "javascript", "python", "rust" -- `name` - Name of the code snippet, commonly a filename. Examples: "hello-world.js", "quick-sort.py" -- `extension` - File extension (without the dot). Examples: "js", "py", "rs" -- `description` - Brief description of what the code does -- `runtime` - Runtime or environment specification (e.g., "node v18.15.0", "python 3.11") -- `license` - License under which the code is shared (e.g., "MIT", "GPL-3.0", "Apache-2.0") -- `dep` - Dependency required for the code to run (can be repeated) -- `repo` - Reference to a repository where this code originates - -## Format - -```json -{ - "id": "<32-bytes lowercase hex-encoded SHA-256 of the the serialized event data>", - "pubkey": "<32-bytes lowercase hex-encoded public key of the event creator>", - "created_at": , - "kind": 1337, - "content": "function helloWorld() {\n console.log('Hello, Nostr!');\n}\n\nhelloWorld();", - "tags": [ - ["l", "javascript"], - ["extension", "js"], - ["name", "hello-world.js"], - ["description", "A basic JavaScript function that prints 'Hello, Nostr!' to the console"], - ["runtime", "node v18.15.0"], - ["license", "MIT"], - ["repo", "https://github.com/nostr-protocol/nostr"] - ], - "sig": "<64-bytes signature of the id>" -} -``` - -## Client Behavior - -Clients that support this NIP SHOULD: - -1. Display code snippets with proper syntax highlighting based on the language. -2. Allow copying the full code snippet with a single action. -3. Render the code with appropriate formatting, preserving whitespace and indentation. -4. Display the language and extension prominently. -5. Provide "run" functionality for supported languages when possible. -6. Display the description (if available) as part of the snippet presentation. - -Clients MAY provide additional functionality such as: - -1. Code editing capabilities -2. Forking/modifying snippets -3. Creating executable environments based on the runtime/dependencies -4. Downloading the snippet as a file using the provided extension -5. Sharing the snippet with attribution -======= -Communi-keys -------------------------------------------------- - -`draft` `optional` - -This NIP defines a standard for creating, managing and publishing to communities by leveraging existing key pairs and relays, introducing the concept of "Communi-keys". This approach allows any existing npub to become a community (identity + manager) while maintaining compatibility with existing relay infrastructure. - -## Motivation - -Current community management solutions on Nostr often require complex relay-specific implementations, lack proper decentralization and don't allow publications to be targeted at more than one community. - -This proposal aims to simplify community management by utilizing existing Nostr primitives (key pairs and relays) while adding minimal new event kinds. - -## Specification - -### Community Creation Event - -A community is created when a key pair publishes a `kind:32221` event with the following structure: - -```json -{ - "kind": 32221, - "content": "", - "tags": [ - ["relay", ""], - ["relay", "", "backup"], - ["relay", "", "backup"], - ["blossom", ""], - ["blossom", "", "backup"], - ["p", "", ""], - ["mint", ""], - ["welcome", ""] - ] -} -``` - -Tag definitions: -- `relay`: URLs of relays where community content should be published. First one is considered main relay. -- `blossom`: URLs of blossom servers for additional community features (optional). -- `p`: Community role assignments. Multiple allowed. Format: `["p", "", ""]`. -- `mint`: URL of community mint for token/payment features (optional). -- `welcome`: Event ID of a welcome/introduction post (optional). - -The pubkey of the key pair that creates this event serves as the unique identifier for the community. This means: -1. Each key pair can only represent one community -2. Communities can be easily discovered by querying for the most recent `kind:32221` event for a given pubkey -3. Community managers can update their settings by publishing a new `kind:32221` event - -### Community Identifier Format - -Communities can be referenced using an "ncommunity" format: -`ncommunity://?relay=&relay=` - -This format follows the same principles as nprofile, but specifically for community identification. While the ncommunity format is recommended for complete relay information, the standard pubkey format can also be used when relay discovery is not needed. - - -### Targeted Publication Event - -To target an existing publication at specific communities, users create a `kind:32222` event: - -```json -{ - "kind": 32222, - "content": "", - "tags": [ - ["e", ""], - ["p", ""], - ["c", ""], - ["r", ""] - ] -} -``` - -The event must be found on the community's specified main relay to be considered valid. The `e` tag references the original publication event that is being targeted at the communities. Communities can be referenced either using: -- The `p` tag with the community's pubkey (for simple cases where relay discovery is not needed) -- The `c` tag with a bech32-encoded ncommunity identifier (which includes both the community pubkey and its relay information) - -### Community Chat Messages - -For chat messages within a community, users should use `kind:9` events with a community tag: - -```json -{ - "kind": 9, - "content": "", - "tags": [ - ["h", ""] - ] -} -``` - -## Implementation Notes - - -1. Clients SHOULD verify that targeted publications (`kind:32222`) are present on the community's main relays. The main relay specified in the community creation event SHOULD be considered authoritative for community-related events. Clients MAY, however, fall back on a backup relay (as the authority) when the main relay is offline. -2. Clients MAY cache community metadata (`kind:30003`) events to reduce relay queries. -3. Relay operators MAY implement/automate additional filtering or moderation based on community specifications. -4. When encountering a `p` tag without corresponding relay information, clients SHOULD attempt to discover the community's relays through other means (e.g., known community relays, cached metadata). - -## Benefits - -1. Any existing npub can become a community -2. Communities are not permanently tied to specific relays -3. Simplified relay operator implementation compared to other community proposals -4. Supports relay-per-community model while remaining flexible -5. Enables cross-community interaction through targeted publications -6. The abilty to target publications to more than one community and the access to any desired content type eliminates the need for #channels or rooms -7. Flexible referencing allows for both simple and complete community identification - -## Security Considerations - -1. Clients MUST verify event signatures from community managers -2. Relays SHOULD implement rate limiting for community-related events -3. Clients SHOULD respect the relay hierarchy specified in community creation events -4. When using simple pubkey references, clients should be aware of potential relay discovery challenges - -## Use Case for Private Groups and DMs - -The Communi-keys structure naturally extends to private groups and DMs by leveraging relay-side authentication: - -### Private Groups -- The community's profile metadata and relay address remain publicly readable -- All content (chats, posts, articles, polls, etc.) is only readable by npubs that meet the group's conditions - -### Direct Messages (DMs) -- DMs are simply a private groups of two -- The npub representing the DM "room" doesn't need public metadata -- Clients can display the room using the other participant's name -- The room's npub can be stored locally or in encrypted form elsewhere for multi-device access -- Provides a clean separation between the chat identity and the participants' identities - -This approach unifies community, group, and DM management under a single model while maintaining privacy through relay-side authentication. ->>>>>>> 5adcdda2e6030f5e9fb420aecfebd1d9762a9625