Better Tools for Open Standards

Standards editors carry too many roles at once. Here is how to separate them.

The structural problem

Standards repositories like the BIP process exist to coordinate open development. The people who maintain them do real, important, largely volunteer work: reviewing proposals, maintaining quality, keeping things organized. That work deserves respect.

The problem is not the people. The problem is that a single process is expected to handle too many distinct jobs at once: deciding whether a proposal gets published, assigning it a number, providing expert review, moderating discussion, and signaling legitimacy to the ecosystem.

When one process carries all of these responsibilities, every editorial decision is overloaded with meaning. A merge looks like endorsement. A rejection looks like erasure. An open PR sitting for years looks like neglect. None of those impressions may be accurate, but the architecture makes them inevitable.

Why another website is not the answer

When frustration arises, the instinct is to fork: make another repository, another website. But forks face a cold-start problem. The original process retains social gravity.

A better approach is not to compete with existing processes but to provide supplementary infrastructure that separates the roles they currently bundle. The existing process continues. Spectivity adds layers around it.

Separating the layers

Publication, review, curation, and adoption tracking are independent acts by independent parties, each with their own signed data:

  • Authors publish specs under their own keys.
  • Reviewers publish signed reviews — visible and attributable, but not controlling the spec's existence.
  • Curators maintain collections with optional numbering.
  • Implementers publish evidence of deployment, compatibility, or testing.
  • Readers choose which reviewers and curators they trust.

Expert review is elevated, not diminished. An ACK from a respected reviewer carries more weight when it is a signed, independent, unforgeable object rather than a comment buried in a thread.

How Spectivity works

Spectivity mirrors existing spec repositories (bitcoin/bips, nostr-protocol/nips, lightning/bolts, bittorrent/bittorrent.org) and presents them alongside direct publications in a unified registry with structured review, trust filtering, and threaded discussion.

Nobody needs to change their workflow. The existing processes continue exactly as they are. Spectivity adds a view layer that makes review sentiment, implementation status, and community opinion visible and filterable.

Every ecosystem

The same separation of concerns applies to every standards process — NIPs, BOLTs, BEPs, and any future protocol spec ecosystem. Each community does valuable coordination work. Each would benefit from infrastructure that lets editors focus on review quality rather than bearing the full weight of publication, numbering, legitimacy, and moderation simultaneously.