NIP-91: Change channel tag from i to c in kind 9 to avoid conflict with NIP-73

Author: Anderson-Juhasc

91.md

@@ -16,7 +16,7 @@ NIP-29 provides group structure, membership, and relay-scoped moderation. As gro
 This NIP introduces channels:
 
 - Preserves NIP-29 group semantics
-- Adds per-group substreams (`i` tag)
+- Adds per-group substreams (`c` tag)
 - Enables efficient filtering and search
 - Remains fully compatible with clients that do not yet support channels
 
@@ -95,14 +95,14 @@ Relays MAY restrict who can create/update channels.
 
 | Tag | Description |
 |-----|-------------|
-| `i` | Channel ID (matches `c` in 39010) |
+| `c` | Channel ID (matches `c` in 39010) |
 
 ### Rules:
 
-- `i` MUST match `c` in a valid channel definition for the group
-- Messages with unknown `i` SHOULD be rejected by relays
-- Messages without `i` are not associated with any specific channel
-- Clients MAY treat messages without `i` as they see fit (e.g., show in all channels, show in a special "uncategorized" view, or hide them)
+- `c` MUST match `c` in a valid channel definition for the group
+- Messages with unknown `c` SHOULD be rejected by relays
+- Messages without `c` are not associated with any specific channel
+- Clients MAY treat messages without `c` as they see fit (e.g., show in all channels, show in a special "uncategorized" view, or hide them)
 
 ### Example:
 
@@ -112,7 +112,7 @@ Relays MAY restrict who can create/update channels.
   "content": "Hello from the general channel!",
   "tags": [
     ["h", "dev-nostr"],
-    ["i", "general"]
+    ["c", "general"]
   ],
   "created_at": 1234567890,
   "pubkey": "...",
@@ -142,7 +142,7 @@ Relays:
 
 - MAY enforce access control
 - SHOULD ensure `channel_id` uniqueness per group
-- SHOULD reject messages with unknown `i` tags
+- SHOULD reject messages with unknown `c` tags
 - MUST enforce group moderation rules from NIP-29
 
 ## Client Behavior
@@ -151,7 +151,7 @@ Clients:
 
 - SHOULD present channels per group as separate substreams
 - MAY hide private channels user lacks access to
-- SHOULD include `i` tag when posting to channels
+- SHOULD include `c` tag when posting to channels
 
 ## Backwards Compatibility
 
@@ -164,7 +164,7 @@ Clients:
 This NIP extends NIP-29:
 
 - Channels are relay-scoped, inside groups
-- `i` tag references channels (`c`)
+- `c` tag references channels
 - Introduces kind:39010 for channel metadata; messages remain kind:9
 - Compatible with existing NIP-29 clients
 
@@ -178,7 +178,7 @@ This NIP is independent from NIP-28 and does not reuse its event kinds or semant
 
 ## Indexers and Search Relays
 
-Indexers SHOULD index `h` (group) and `i` (channel) for efficient queries.
+Indexers SHOULD index `h` (group) and `c` (channel) for efficient queries.
 
 - Queries can filter by group or channel without duplicating events
 - Backfill from existing kind:9 messages is straightforward
@@ -194,7 +194,7 @@ Indexers SHOULD index `h` (group) and `i` (channel) for efficient queries.
 **Messages in specific channel:**
 
 ```json
-{"kinds":[9],"#h":["dev-nostr"],"#i":["general"]}
+{"kinds":[9],"#h":["dev-nostr"],"#c":["general"]}
 ```
 
 ## Edge Cases
@@ -204,7 +204,7 @@ Indexers SHOULD index `h` (group) and `i` (channel) for efficient queries.
 - **Message sent to unknown channel** → relay SHOULD reject
 - **Forked relay** → channels may differ; clients SHOULD NOT assume equivalence across relays
 - **Client without support** → sees all messages in single timeline
-- **Reactions** (kind 7) → SHOULD include same `i` tag as parent message to maintain context
+- **Reactions** (kind 7) → SHOULD include same `c` tag as parent message to maintain context
 
 ## Conclusion