\"]`\n- `[\"published_at\",\"<unix-seconds>\"]`\n\n#### Optional tags\n- `[\"summary\",\"<text>\"]`\n- `[\"t\",\"<topic>\"]` (repeatable)\n- `[\"lang\",\"<bcp47>\"]`\n- `[\"version\",\"<string>\"]`\n- `[\"supersedes\",\"ncc-YY\"]` (repeatable)\n- `[\"license\",\"<id-or-url>\"]`\n- `[\"authors\",\"<npub-or-pubkey>\"]` (editorial credit only)\n\n#### Content\n- MUST be human-readable Markdown\n- MUST contain the full convention text\n\n#### Replaceable semantics\nFor a given author pubkey and `d`, later events replace earlier ones.\n\n---\n\n### A.2 NCC Succession Record (`kind:30051`)\n\n#### Required tags\n- `[\"d\",\"ncc-XX\"]`\n- `[\"authoritative\",\"event:<event_id>\"]`\n\n#### Optional tags\n- `[\"steward\",\"pubkey:<hex>\"]` or `[\"steward\",\"npub:<bech32>\"]`\n- `[\"previous\",\"event:<event_id>\"]`\n- `[\"reason\",\"<short-text>\"]`\n- `[\"effective_at\",\"<unix-seconds>\"]`\n\n#### Content\n- SHOULD be short and plain language\n- Describes the handover intent\n\nSuccession records are coordination signals, not enforcement mechanisms.\n\n---\n\n## Appendix B – Client Resolution Guidance (Non-Normative)\n\n1. Identify origin NCC by earliest timestamp.\n2. If a recognised succession record exists, follow it.\n3. Otherwise allow de-facto authority based on adoption and trust.\n4. Label authority clearly:\n - “Steward-acknowledged”\n - “De-facto (adopted)”\n\n---\n\n## Appendix C – State Model (Non-Normative)\n\nThis appendix describes a practical mental model for how NCC identifiers evolve over time. It is guidance only.\n\n### States\n\n```text\nNCC-ID (e.g. ncc-01)\n\n[ORIGIN]\n Earliest published NCC for d=ncc-01 establishes the identifier and initial steward (npub).\n\n |\n | anyone publishes a superseding NCC (proposal)\n v\n\n[PROPOSED]\n One or more superseding NCCs exist (alternative candidates).\n\n | \\\n | steward publishes \\ community adoption\n | succession record \\ (clients/users choose)\n v v\n\n[STEWARD-ACKNOWLEDGED] [DE-FACTO]\n Current steward explicitly A superseding NCC becomes\n recognises a new authoritative dominant through adoption,\n NCC document. even without succession.\n\n \\ /\n \\ further succession / continued adoption shift\n \\ or adoption shift /\n v\n[CURRENT]\n The NCC document treated as authoritative at this time.\n```\n\n\n##### Interpretation\n\nSupersession is permissionless and produces candidates.\nSuccession is a signed coordination record produced by the current steward.\nDe-facto adoption may still select a current document without succession.\nClients should label outcomes clearly so users can distinguish:\nSteward-acknowledged authority\nDe-facto (adopted) authority\n\n##### Implementation note\n\nClients should avoid treating any single signal as absolute. Where succession is absent, clients should default to user trust signals (follows, curated lists) and visible adoption indicators.\n\n---\n\n## Appendix D – Endorsement Signals (Non-Normative)\n\nThis appendix defines an optional, explicit signal for expressing support, adoption, or implementation of an NCC.\n\nEndorsement events make **community adoption legible**, without creating authority, approval, or enforcement.\n\n---\n\n## Purpose\n\nEndorsement events allow authors, client developers, and users to publicly state support for a specific NCC document.\n\nThey are intended to:\n- Make adoption visible and queryable\n- Distinguish interest from implementation\n- Support de-facto authority resolution when succession is absent\n- Improve transparency around ecosystem behaviour\n\nEndorsement does **not** imply authority, approval, or correctness.\n\n---\n\n## Event Kind\n\n- **NCC Endorsement Record:** `kind:30052`\n\nThis kind is reserved by convention for NCC endorsement signalling and may be reassigned if conflicts emerge.\n\n---\n\n## Required Tags\n\n- `[\"d\",\"ncc-XX\"]`\n - The NCC identifier being endorsed.\n- `[\"endorses\",\"event:<event_id>\"]`\n - References the specific NCC document event (kind:30050) being endorsed.\n\nEndorsements SHOULD reference a concrete NCC document, not just an identifier.\n\n---\n\n## Optional Tags\n\n- `[\"role\",\"author\"]`\n- `[\"role\",\"client\"]`\n- `[\"role\",\"user\"]`\n - Indicates the perspective of the endorser.\n- `[\"implementation\",\"<client-name-or-url>\"]`\n - Indicates an implementation or planned implementation.\n- `[\"note\",\"<short-text>\"]`\n - Brief rationale or context.\n- `[\"t\",\"<topic>\"]` (repeatable)\n\nThese tags are informational only and carry no inherent weight.\n\n---\n\n## Content\n\n- Content SHOULD be short and human-readable.\n- Examples:\n - “Implemented in Client X”\n - “Endorsed for personal journaling use”\n - “Using this convention internally”\n\nClients MAY ignore content entirely.\n\n---\n\n## Semantics\n\nAn endorsement event represents a **signed statement of support**.\n\nIt:\n- Does not supersede any NCC\n- Does not establish stewardship\n- Does not override succession\n- Does not bind other clients or users\n\nMultiple endorsements may coexist, including endorsements of competing NCCs.\n\n---\n\n## Client Guidance\n\nClients MAY:\n- Surface endorsement counts or summaries\n- Weight endorsements using local trust graphs\n- Distinguish endorsements by role (author, client, user)\n- Use endorsements as adoption signals in de-facto authority resolution\n\nClients MUST NOT:\n- Treat endorsements as approval or certification\n- Require endorsements for visibility or usage\n- Block or suppress unendorsed NCCs\n\nEndorsements are signals, not votes.\n\n---\n\n## Interaction with Succession and Adoption\n\n- Succession records remain the clearest signal of steward acknowledgement.\n- Endorsements provide evidence of adoption when succession is absent or contested.\n- High adoption via endorsements MAY inform de-facto authority, but does not mandate it.\n\nEndorsements improve clarity; they do not confer control.\n\n---\n\n## Design Rationale\n\nThis approach:\n- Avoids introducing governance or voting systems\n- Leverages existing Nostr trust and follow graphs\n- Makes ecosystem behaviour observable\n- Preserves permissionless participation\n\nIf endorsements are ignored, nothing breaks.\n\n---\n\n## Status\n\nEndorsement signalling is optional and experimental.\n\nClients and users are encouraged to treat endorsements as **context**, not authority.\n","created_at",1766313277,"id","fe4b84bcbf6481fd65ff43d786ed0355821af861768562567c670216cc9140e9","kind",30023,"pubkey","b5d34eedc7d8f81ceaa5ed377b5a2d534ee949fae0c5ab3bae0a576aa7475cbf","sig","d253fa80dec359baacb3fe8e728e2889b12947ab232445a9d6b52c38c3dcecc6f17fc28662b5c9dd77ed3f097994c2071f92160f19312e6219d603d0e081b54c","tags",[28,29,30,31,32,33,34,35,36,37,38,39,40],[58,59,60],[56,57],[54,55],[52,53],[50,51],[48,49],[41,12],[41,47],[41,46],[41,45],[41,44],[41,43],[41,42],"t","#community","#development","#proposal","#grownostr","#ncc","#nostr","published_at","1766264537","summary","NCCs are lightweight, Nostr-native conventions for client and ecosystem behaviour. Not protocol rules, not enforced standards. Just documented patterns that emerge, get copied, and evolve.","title","NCC-00: Publishing Nostr Community Conventions on Nostr\n","image","","d","c348f5e17ca74827","client","YakiHonne","31990:20986fb83e775d96d188ca5c9df10ce6d613e0eb7e5768a0f0b12b37cdac21b3:1700732875747"] </article></body></html>

[{"_1":2,"_3":-5,"_4":-5},"loaderData",{"_5":6},"actionData","errors","routes/hashtag",{"_7":8,"_9":10,"_11":12},"articles",[13],"authors",{},"tag","#nostrdevs",{"_14":15,"_16":17,"_18":19,"_20":21,"_22":23,"_24":25,"_26":27},"content","\n## Summary\n\nThis convention defines how **Nostr Community Conventions (NCCs)** are published, discovered, revised, and evolved **using Nostr itself**.\n\nNCC-00 establishes Nostr as the primary medium for documenting and coordinating community conventions that describe ecosystem and client behaviour, without altering the Nostr protocol.\n\n---\n\n## Purpose\n\nNostr Community Conventions exist to document **shared usage patterns** of existing Nostr primitives where protocol-level standardisation is unnecessary or undesirable.\n\nNCCs aim to:\n- Improve interoperability between clients\n- Reduce duplicated design work\n- Make emerging norms visible and copyable\n- Allow decentralised evolution without gatekeeping\n\n---\n\n## Scope\n\nNCCs MAY describe:\n- Event usage patterns\n- Kind selection semantics\n- Tag conventions\n- Content lifecycle and revision models\n- Client behaviour expectations\n- Social or coordination norms\n\nNCCs DO NOT define:\n- Relay enforcement rules\n- Cryptography, signing, or transport\n- Mandatory behaviour\n- Protocol-level requirements\n\n---\n\n## Relationship to NIPs\n\n- **NIPs** define protocol and wire behaviour.\n- **NCCs** define convention and ecosystem behaviour.\n\nNCCs are:\n- Optional\n- Backwards-compatible\n- Non-enforcing\n- Composable\n\nAn NCC may inform a future NIP, but this is neither required nor implied.\n\n---\n\n## Publication Model\n\nNCCs are published directly on Nostr as long-form, parameterised replaceable events.\n\nThere is:\n- No central registry\n- No approval process\n- No authoritative host\n\nDiscovery, relevance, and authority emerge through usage.\n\n---\n\n## Numbering and Authority\n\nThere is no central authority responsible for assigning NCC numbers.\n\nFor any NCC identifier (for example `ncc-01`):\n- The **earliest published NCC event by timestamp** establishes the identifier\n- That author is considered the **initial steward**\n\nNumbers reflect publication order, not permission.\n\n---\n\n## Supersession and Succession\n\nNCC evolution occurs through two distinct mechanisms.\n\n### Supersession (proposal)\n\nAny author MAY publish an NCC that declares it supersedes an existing NCC.\n\n- Supersession represents a proposed improvement or alternative\n- It does not transfer authority by itself\n- Superseding NCCs compete through adoption\n\nSupersession is expressed using a `supersedes` tag.\n\n---\n\n### Succession (steward acknowledgement)\n\nSuccession is the explicit transfer of stewardship from the current steward to a superseding NCC.\n\n- A succession event is authored by the current steward\n- It references the superseding NCC\n- It signals recognition, not enforcement\n\nSuccession provides a clear, signed record of handover.\n\n---\n\n### Succession is declarative, not mandatory\n\nSuccession cannot be forced. \nHowever, authority in practice may still shift through community adoption.\n\nSuccession events:\n- Improve clarity\n- Reduce ambiguity\n- Are not required for progress\n\nIf the network moves on, the network moves on.\n\n---\n\n## Authority in Practice\n\nAuthority over an NCC identifier emerges from a combination of:\n- First publication timestamp\n- Signed authorship\n- Client support\n- Community adoption\n\nClients SHOULD:\n- Prefer NCCs referenced by a valid succession event when one exists\n- Otherwise allow de-facto authority based on trust and adoption signals\n- Avoid treating succession as a hard requirement\n\n---\n\n## Governance Model\n\nNCCs are maintained through:\n- Open publication\n- Signed authorship\n- Public discussion\n- Adoption by clients\n\nThere is no central authority. \nForking is valid and expected.\n\n---\n\n## Design Principles\n\n- Minimalism over abstraction\n- Behaviour over theory\n- Interoperability over purity\n- Evolution through practice\n\nIf a convention is useful, it will be adopted.\n\n---\n\n## Status\n\nNCCs are community conventions. \nThey are living documents, not standards.\n\n---\n## Recommended Convention Structure (Non-Normative)\n\nNCCs are intentionally lightweight and flexible. \nThere is no mandatory template for authoring a convention.\n\nHowever, authors are encouraged to follow a broadly consistent structure to improve clarity, comparability, and client implementability.\n\nA typical NCC document may include:\n\n- **Title and status**\n - For example: Informal, Draft, In Use\n- **Scope**\n - What the convention applies to, and what it does not\n- **Standards or NIPs referenced**\n - Explicitly list any existing NIPs relied upon\n- **Overview**\n - A short description of the problem and intent\n- **Design principles**\n - Constraints or values guiding the convention\n- **Core approach**\n - The behavioural or structural model being proposed\n- **Event schema**\n - Required and optional fields or tags\n- **Examples**\n - Representative event examples where useful\n- **Client behaviour guidance**\n - Expected handling by supporting clients\n- **Privacy and security considerations**\n - What metadata remains visible and what does not\n- **Non-goals**\n - Explicit exclusions to prevent scope creep\n- **FAQ or rationale**\n - Optional clarifications for common questions\n- **Status and next steps**\n - Adoption expectations and future formalisation notes\n\nThis structure is illustrative only. \nAuthors may omit, reorder, or adapt sections as appropriate.\n\nConventions that are clear, scoped, and ignorable by default are preferred over exhaustive or prescriptive specifications.\n\n---\n\n## Appendix A – Event Definitions (Normative)\n\n### Reserved kinds\n\n- **NCC Document:** `kind:30050`\n- **NCC Succession Record:** `kind:30051`\n\nThese kinds are reserved by convention for NCC use and may be reassigned if conflicts emerge.\n\n---\n\n### A.1 NCC Document Event (`kind:30050`)\n\n#### Required tags\n- `[\"d\",\"ncc-XX\"]`\n- `[\"title\",\"\"]`\n- `[\"published_at\",\"<unix-seconds>\"]`\n\n#### Optional tags\n- `[\"summary\",\"<text>\"]`\n- `[\"t\",\"<topic>\"]` (repeatable)\n- `[\"lang\",\"<bcp47>\"]`\n- `[\"version\",\"<string>\"]`\n- `[\"supersedes\",\"ncc-YY\"]` (repeatable)\n- `[\"license\",\"<id-or-url>\"]`\n- `[\"authors\",\"<npub-or-pubkey>\"]` (editorial credit only)\n\n#### Content\n- MUST be human-readable Markdown\n- MUST contain the full convention text\n\n#### Replaceable semantics\nFor a given author pubkey and `d`, later events replace earlier ones.\n\n---\n\n### A.2 NCC Succession Record (`kind:30051`)\n\n#### Required tags\n- `[\"d\",\"ncc-XX\"]`\n- `[\"authoritative\",\"event:<event_id>\"]`\n\n#### Optional tags\n- `[\"steward\",\"pubkey:<hex>\"]` or `[\"steward\",\"npub:<bech32>\"]`\n- `[\"previous\",\"event:<event_id>\"]`\n- `[\"reason\",\"<short-text>\"]`\n- `[\"effective_at\",\"<unix-seconds>\"]`\n\n#### Content\n- SHOULD be short and plain language\n- Describes the handover intent\n\nSuccession records are coordination signals, not enforcement mechanisms.\n\n---\n\n## Appendix B – Client Resolution Guidance (Non-Normative)\n\n1. Identify origin NCC by earliest timestamp.\n2. If a recognised succession record exists, follow it.\n3. Otherwise allow de-facto authority based on adoption and trust.\n4. Label authority clearly:\n - “Steward-acknowledged”\n - “De-facto (adopted)”\n\n---\n\n## Appendix C – State Model (Non-Normative)\n\nThis appendix describes a practical mental model for how NCC identifiers evolve over time. It is guidance only.\n\n### States\n\n```text\nNCC-ID (e.g. ncc-01)\n\n[ORIGIN]\n Earliest published NCC for d=ncc-01 establishes the identifier and initial steward (npub).\n\n |\n | anyone publishes a superseding NCC (proposal)\n v\n\n[PROPOSED]\n One or more superseding NCCs exist (alternative candidates).\n\n | \\\n | steward publishes \\ community adoption\n | succession record \\ (clients/users choose)\n v v\n\n[STEWARD-ACKNOWLEDGED] [DE-FACTO]\n Current steward explicitly A superseding NCC becomes\n recognises a new authoritative dominant through adoption,\n NCC document. even without succession.\n\n \\ /\n \\ further succession / continued adoption shift\n \\ or adoption shift /\n v\n[CURRENT]\n The NCC document treated as authoritative at this time.\n```\n\n\n##### Interpretation\n\nSupersession is permissionless and produces candidates.\nSuccession is a signed coordination record produced by the current steward.\nDe-facto adoption may still select a current document without succession.\nClients should label outcomes clearly so users can distinguish:\nSteward-acknowledged authority\nDe-facto (adopted) authority\n\n##### Implementation note\n\nClients should avoid treating any single signal as absolute. Where succession is absent, clients should default to user trust signals (follows, curated lists) and visible adoption indicators.\n\n---\n\n## Appendix D – Endorsement Signals (Non-Normative)\n\nThis appendix defines an optional, explicit signal for expressing support, adoption, or implementation of an NCC.\n\nEndorsement events make **community adoption legible**, without creating authority, approval, or enforcement.\n\n---\n\n## Purpose\n\nEndorsement events allow authors, client developers, and users to publicly state support for a specific NCC document.\n\nThey are intended to:\n- Make adoption visible and queryable\n- Distinguish interest from implementation\n- Support de-facto authority resolution when succession is absent\n- Improve transparency around ecosystem behaviour\n\nEndorsement does **not** imply authority, approval, or correctness.\n\n---\n\n## Event Kind\n\n- **NCC Endorsement Record:** `kind:30052`\n\nThis kind is reserved by convention for NCC endorsement signalling and may be reassigned if conflicts emerge.\n\n---\n\n## Required Tags\n\n- `[\"d\",\"ncc-XX\"]`\n - The NCC identifier being endorsed.\n- `[\"endorses\",\"event:<event_id>\"]`\n - References the specific NCC document event (kind:30050) being endorsed.\n\nEndorsements SHOULD reference a concrete NCC document, not just an identifier.\n\n---\n\n## Optional Tags\n\n- `[\"role\",\"author\"]`\n- `[\"role\",\"client\"]`\n- `[\"role\",\"user\"]`\n - Indicates the perspective of the endorser.\n- `[\"implementation\",\"<client-name-or-url>\"]`\n - Indicates an implementation or planned implementation.\n- `[\"note\",\"<short-text>\"]`\n - Brief rationale or context.\n- `[\"t\",\"<topic>\"]` (repeatable)\n\nThese tags are informational only and carry no inherent weight.\n\n---\n\n## Content\n\n- Content SHOULD be short and human-readable.\n- Examples:\n - “Implemented in Client X”\n - “Endorsed for personal journaling use”\n - “Using this convention internally”\n\nClients MAY ignore content entirely.\n\n---\n\n## Semantics\n\nAn endorsement event represents a **signed statement of support**.\n\nIt:\n- Does not supersede any NCC\n- Does not establish stewardship\n- Does not override succession\n- Does not bind other clients or users\n\nMultiple endorsements may coexist, including endorsements of competing NCCs.\n\n---\n\n## Client Guidance\n\nClients MAY:\n- Surface endorsement counts or summaries\n- Weight endorsements using local trust graphs\n- Distinguish endorsements by role (author, client, user)\n- Use endorsements as adoption signals in de-facto authority resolution\n\nClients MUST NOT:\n- Treat endorsements as approval or certification\n- Require endorsements for visibility or usage\n- Block or suppress unendorsed NCCs\n\nEndorsements are signals, not votes.\n\n---\n\n## Interaction with Succession and Adoption\n\n- Succession records remain the clearest signal of steward acknowledgement.\n- Endorsements provide evidence of adoption when succession is absent or contested.\n- High adoption via endorsements MAY inform de-facto authority, but does not mandate it.\n\nEndorsements improve clarity; they do not confer control.\n\n---\n\n## Design Rationale\n\nThis approach:\n- Avoids introducing governance or voting systems\n- Leverages existing Nostr trust and follow graphs\n- Makes ecosystem behaviour observable\n- Preserves permissionless participation\n\nIf endorsements are ignored, nothing breaks.\n\n---\n\n## Status\n\nEndorsement signalling is optional and experimental.\n\nClients and users are encouraged to treat endorsements as **context**, not authority.\n","created_at",1766313277,"id","fe4b84bcbf6481fd65ff43d786ed0355821af861768562567c670216cc9140e9","kind",30023,"pubkey","b5d34eedc7d8f81ceaa5ed377b5a2d534ee949fae0c5ab3bae0a576aa7475cbf","sig","d253fa80dec359baacb3fe8e728e2889b12947ab232445a9d6b52c38c3dcecc6f17fc28662b5c9dd77ed3f097994c2071f92160f19312e6219d603d0e081b54c","tags",[28,29,30,31,32,33,34,35,36,37,38,39,40],[58,59,60],[56,57],[54,55],[52,53],[50,51],[48,49],[41,12],[41,47],[41,46],[41,45],[41,44],[41,43],[41,42],"t","#community","#development","#proposal","#grownostr","#ncc","#nostr","published_at","1766264537","summary","NCCs are lightweight, Nostr-native conventions for client and ecosystem behaviour. Not protocol rules, not enforced standards. Just documented patterns that emerge, get copied, and evolve.","title","NCC-00: Publishing Nostr Community Conventions on Nostr\n","image","","d","c348f5e17ca74827","client","YakiHonne","31990:20986fb83e775d96d188ca5c9df10ce6d613e0eb7e5768a0f0b12b37cdac21b3:1700732875747"] </article></body></html>