• Summary
• Motivation
• Why a new kind
  • Notes (kind:1)
  • Long-form or parameterised kinds
  • Conventions alone
• Event definition
  • Kind
  • Replacement semantics
• Required tags
• Strongly recommended tags
• Optional tags
• Content
• Lifecycle model
• Proposal profiles
  • type = nip
• Companion kinds (optional)
  • Proposal comments and reviews
  • Endorsements (implementation signals)
  • Registries and indexes
• Client expectations
• Non-authority disclaimer

§Summary

This document proposes a new Nostr event kind representing protocol-level proposals, modelled explicitly on the semantics of a pull request. These events act as protocol-native PR containers used to propose, revise, and reference conventions, new kinds, or other Nostr protocol behaviours directly on Nostr.

The proposal kind encodes intent, structure, and lifecycle, but not authority, consensus, or approval. It provides a stable artefact around which discussion, tooling, and experimentation can coherently form.

Status: Draft
Kind number: provisional

§Motivation

Today, Nostr protocol proposals are fragmented across GitHub repositories, chat platforms, and ad-hoc notes. There is no canonical, on-protocol object representing a proposal itself.

This fragmentation:

• Makes protocol evolution difficult to discover or index
• Forces governance and discussion off-protocol
• Prevents tooling from observing proposal lifecycles in a structured way

This proposal introduces a protocol-native coordination artefact that mirrors how pull requests function in software development, without importing centralised governance.

§Why a new kind

§Notes (kind:1)

• Are conversational and ephemeral
• Appear in social timelines by default
• Do not encode proposal lifecycle or supersession semantics

§Long-form or parameterised kinds

• Encode content, not process
• Cannot reliably distinguish proposals from essays or documentation
• Lack a consistent revision and lifecycle model for governance artefacts

§Conventions alone

• Rely on implicit semantics
• Are difficult for relays and clients to filter or index
• Blur governance artefacts into content kinds

Protocol proposals are a distinct epistemic object, not a variation of notes or articles. A dedicated kind provides a clean semantic boundary.

§Event definition

§Kind

• Replaceable, addressable
• Range: 30000–39999
• Provisional assignment: kind:31992

§Replacement semantics

• Addressed by pubkey + d
• Latest event replaces prior versions with the same identifier

§Required tags

• d
  Stable proposal identifier (PR-like slug). Immutable once chosen.

• type
  Proposal profile. Defines specialised semantics.
  Examples: nip, kind, convention, governance

• status
  Base lifecycle state:
  draft | active | superseded | withdrawn

• t
  Classification labels. Must include proposal.

§Strongly recommended tags

• title
  One-line proposal title (PR title equivalent).

• summary
  Short proposal summary (PR description opening).

§Optional tags

• stage
  Profile-specific process stage.
  Example values for type=nip:
  review | last-call | accepted | final | deprecated | rejected

• relates-to
  Referenced kinds, NIPs, or conventions.

• supersedes
  Identifier or event id of a replaced proposal.

• discussion
  Event id or URL of the primary discussion thread.

• repo
  External repository or document, if applicable.

• client
  Publishing client identifier.

§Content

The content field represents the PR body.

Recommended structure:

• Problem statement
• Proposed change
• Scope and non-goals
• Open questions or feedback requested

Markdown is permitted. No enforced structure beyond readability.

§Lifecycle model

Notes:

• There is no accepted or rejected base status.
• Consensus and adoption remain external.
• Supersession must be explicit.

§Proposal profiles

§type = nip

When type is nip, the proposal follows additional conventions:

Recommended tags:

• version (semver)
• depends (other NIPs or proposals)
• replaces (prior NIP identifiers)

Process-heavy progression such as review, last call, or finalisation must be expressed via the stage tag, not status.

This preserves the base kind’s non-authoritative stance while allowing NIP-specific workflows.

§Companion kinds (optional)

§Proposal comments and reviews

Discussion may occur via normal kind:1 replies, or via a dedicated companion kind for structured review tooling.

§Endorsements (implementation signals)

A separate, optional kind may be used to signal implementation or support, referencing proposals via an a tag. These signals:

• Are non-binding
• Do not imply acceptance
• Exist purely for visibility and coordination

§Registries and indexes

Curated proposal lists may be published as replaceable index events. These are explicitly non-canonical and reflect the curator’s perspective only.

§Client expectations

• Do not show proposal events in social timelines by default
• Index proposals separately from notes and articles
• Resolve replaceable proposals to their latest version
• Optionally surface status, stage, and labels

§Non-authority disclaimer

Publishing or interacting with a proposal event:

• Does not imply endorsement or approval
• Does not assign kind numbers
• Does not create consensus
• Does not replace NIPs or other coordination processes

This kind provides a coordination layer only. Governance remains social and decentralised.