topical communities

05.md

@@ -0,0 +1,126 @@
+Simple topical communities
+=======================
+
+
+### Problem Statement
+
+Nostr today is like a large bitcoin meetup. Bitcoiners find it easy to find their people and join in on the conversation by default find their people. However, for *non*-bitcoiners, it is not trivial to find interesting people to follow or conversations to join in.
+
+We have observed that new users who are not Bitcoin enthusiasts often cannot find people or content that is interesting for them. Since most of the content is overwhelmingly Bitcoin
+/Nostr oriented, they often leave within a few minutes of joining Nostr — thinking it is not "for them".
+
+This is can be a major roadblock for adoption of public-square/Twitter-style/`kind:1` clients outside Bitcoiner circles.
+
+On the flip side, veteran Nostr users often have multiple different interests, but often hold back on talking about them as they believe their followers might not be interested.
+
+
+This DIP aims to solve this problem by introducing a simple spec for open communities that can be easily implemented by `kind:1` clients, enabling:
+- veteran nostr/bitcoin users to talk about other specific interests or topics that might be too specific for global timelines (e.g. Linux, Gardening, Homelabbing, Physics, Math, specific cities, etc)
+- new non-Bitcoiner users to easily find content that they are interested in and engage, within 5 minutes of downloading the app.
+
+This DIP aims to achieve that in a way that:
+- fits well with the general open "public-square" nature of `kind:1` clients.
+- reuses existing NIPs and keeps things simple.
+
+
+It is hypothesized that if new to nostr people are joining with or without invite to a nostr community, the ability to easily find interesting conversations outside Bitcoin topics will improve retention of new users on `kind:1` clients.
+
+
+### One day prototype/proof of concept
+
+This is a quick proof of concept made in a single day to illustrate the general concept:
+
+https://github.com/user-attachments/assets/59a4de53-fa3d-4df5-8f8f-386cef3ae70c
+
+### Spec 
+
+These open communities can be based around different things. For example:
+1. Topics (similar to subreddits — but with no owners/moderators)
+2. Relays (More customizable moderation rules can be set by the relay operator — i.e. there is clear ownership)
+3. Geohashes (For people connecting to others in their area — no owners/moderators)
+
+Each community is simply defined via [NIP-73](https://github.com/nostr-protocol/nips/blob/master/73.md) identifiers:
+1. Topic communities are defined by NIP-73 hashtag ids
+2. Relay communities are defined by NIP-73 URL ids pointing to a Nostr relay 
+3. Geohash communities are defined by NIP-73 geohash ids
+
+Each community has a timeline. To build a timeline for an open community, clients MAY simply fetch `kind:1111` posts with a root `I` tag for that community. See [NIP-22](https://github.com/nostr-protocol/nips/blob/master/22.md) for details.
+
+If it is a relay community, clients MAY provide the user the option to fetch events from several relays (censorship resistance), or from the referenced relay (moderated experience).
+
+Each post can have its own thread. Threads are simply NIP-22 comments with root `E` and `e` tags (pointing to the root thread post, and the parent response — respectively).
+
+### Community Subscriptions
+
+  Users track which communities they've subscribed to using a dedicated event `kind:30073`.
+
+  Event Structure
+```
+  {
+    "kind": 30073,
+    "tags": [
+      ["d", ""],
+      ["I", "#gardening"],
+      ["I", "#photography"],
+      ["I", "#cooking"]
+    ],
+    "content": "<optional: NIP-44 encrypted private entries>",
+    "created_at": <unix timestamp>
+  }
+```
+```
+  Tags
+  ┌─────┬────────────────────────────────────────────────────────────┐
+  │ Tag │                        Description                         │
+  ├─────┼────────────────────────────────────────────────────────────┤
+  │ d   │ Empty string (single list per user)                        │
+  ├─────┼────────────────────────────────────────────────────────────┤
+  │ I   │ NIP-73 community identifier (one per subscribed community) │
+  └─────┴────────────────────────────────────────────────────────────┘
+```
+
+Privacy
+
+  Community subscriptions can be public, private, or mixed:
+
+  Public entries are stored in I tags, visible to anyone querying the event.
+
+  Private entries are stored in content field, encrypted using https://github.com/nostr-protocol/nips/blob/master/44.md with the user encrypting to themselves (same pubkey for sender and recipient). This follows the same pattern as NIP-51 private entries.
+
+  Encrypted content format:
+  {
+    "communities": ["#private-topic", "#another-private"]
+  }
+
+  Clients MUST merge both public (from tags) and private (from decrypted content) entries when displaying the user's subscribed communities.
+
+  Client Behavior
+
+  On Login:
+  1. Fetch kind:30073 event for the user's pubkey
+  2. Parse I tags for public community subscriptions
+  3. If content is non-empty, decrypt and merge private subscriptions
+  4. Display combined list as "Your Communities"
+
+  On Subscribe/Unsubscribe:
+  1. Update the community list (add/remove from tags or encrypted content)
+  2. Publish updated kind:30073 event
+  3. Being a parameterized replaceable event, only the latest version is kept
+
+  Example Query
+
+  {
+    "kinds": [30073],
+    "authors": ["<pubkey>"],
+    "#d": [""]
+  }
+
+
+
+## Isn't this just NIP-22?
+
+Yes, strictly speaking this is part of NIP-22. However, NIP-22 could have some slight different interpretations and implementation differences based on the use case (e.g. Which tags to use for constructing threads, how to semantically interpret different `I` tags, etc). This DIP aims to specify one specific interpretation for a specific use case.
+1m
+
+
+