Mero.xdc on Nostr: th2tran # Nostr Governance Crisis: Summary (May–October 2026) ## The Core Problem ...

th2tran (npub10un…scra)
# Nostr Governance Crisis: Summary (May–October 2026)

## The Core Problem

Nostr has no formal governance mechanism. Decisions about which NIPs get merged, which proposals get ignored, and which maintainers hold sway are made through what one long-time contributor called **"a kind of Nostr 'shadow governance' — a sort of cool kids club that decides, without much public discourse, what is in and what is out."** [nostrmag.com](https://nostrmag.com/article/w19nostr01)

That absence of structure has produced a cascading crisis.

---

## Timeline

### May 2026 — Governance Crisis Begins

Two overlapping disputes reach boiling point simultaneously:

**1. NIP-26 (Delegated Event Signing)**
A proposed spec allowing users to temporarily hand signing authority to third-party services. Originally written to accommodate a corporate integration with Minds.com. fiatjaf publicly declared it "a bad idea that will eventually destroy Nostr." Supporters counter that key rotation and delegation are non-negotiable for mass adoption. The PR has languished for months with no resolution.

**2. The Outbox Model**
The architectural proposal to make clients smarter about which relays they query, intended to reduce reliance on a handful of mega-relays (currently ~90% of users connect to a few massive servers). Critics warn it degrades performance and fragments the user experience.

### September 3, 2026 — NIP-78 Privacy Upgrade

NIP-78 updated to require AUTH for kind 30078 events (personal app settings). Relays must now authenticate users before accepting or returning their data. Alex Gleason called it a "big privacy win for Nostr." This shows the development process can still deliver wins, but it's the exception, not the rule.

### September 12, 2026 — The Stacker News Post

A post on Stacker News accused **Vitor Pamplona** (Nostr's "Chief Android Officer," creator of Amethyst) of declaring that client developers will propagate user notes everywhere without permission. The controversy centers on the **outbox model**:

- **What it does**: Clients automatically broadcast your notes to multiple relays based on where your followers are, not where you want to publish.
- **What it fixes**: Relay fragmentation. Notes weren't loading. Conversations were missing replies.
- **What it breaks**: User sovereignty. For users who specified only one or two relays, there's now no reliable way to delete published content. Direct messages may have been propagated across the network, making them vulnerable to harvest-now-decrypt-later attacks.

The author's question: *"Is there any way to leave Nostr???"*

Pamplona defended the outbox model on technical grounds. The community split: some defend it as necessary pragmatism, others see it as a betrayal of Nostr's founding principles.

### September 17–19, 2026 — NIP-17 Seal Timestamp Clash

fiatjaf opened PR [#2471](https://github.com/nostr-protocol/nips/pull/2471) proposing to drop the requirement that NIP-17 seal timestamps be randomized, arguing "it makes no sense to design a protocol assuming clients will implement it incorrectly."

Pamplona opposes, warning that seals persist on relays even when rumors don't, so removing randomization would reopen a metadata-leak vector NIP-17 was built to close.

The PR remains open with no resolution — a rare live protocol-level dispute between two of Nostr's most active maintainers. [nostr.ae](https://nostr.ae/nevent1qqswthn8vs6ekpt3j4x8yhjykfpnvneqlfnmwh7dtaafqacnl6nyl4szypdxp39ttpyt4zukk4t3cq0nrw2q64tv77v75cac7fs7kc88ryz5kdr2y7k)

### Concurrent: CSAM Content Moderation

A separate but related incident: CSAM videos were hosted on Nostr. After the npub was exposed, it took an entire day for the content to be taken down. The developer in question was accused of making excuses and falsely accusing people. The proof that the community (not the relay) got them removed: other npubs hosting CSAM on the same servers are still up. [nostr.eu](https://nostr.eu/nevent1qqsw9l899xdykeqy8ejzfq3csq9su7m2s72tvh7fghg6wcusd4qmpggzyq2q9t75z52chfr87y77gq3d5hszq54mduv5gumwkq04ej7ytfg96vnamd2)

### Late September 2026 — The Oddbean Distress Call

An anonymous developer posted on Oddbean:

> "Right now I am watching Nostr fragment before my very eyes. Developers are giving up, because they have very little leadership, direction, or can collectively agree on anything that would improve the situation. Our market share is diminishing. People leave every day due to either broken clients, or lack of engagement. If we do not find a way to come together NOW as a community to improve upon our situation … Then we are going to die a slow painful death as a protocol."

Within hours, the note ripped across Nostr relays, drawing hundreds of threaded replies.

### October 2026 — Current State

The protocol is not dead, but it is bleeding talent and coherence. The NIP status table tells the story:

| NIP | Spec Status | In Production |
|-----|-------------|---------------|
| NIP-13 (Proof of Work) | Merged | Yes |
| NIP-56 (Reporting) | Merged | Yes (Damus) |
| NIP-32 (Labeling) | Merged | Partially verified |
| NIP-85 (Web of Trust) | Draft | Yes (Amethyst) |
| PR #1056 (Key Revocation) | Open, not merged | No |

[nostr.ae](https://nostr.ae/nevent1qqsd0jleazk6m3pru7z8adqej6dwll60v8ree909kltlcugyc8frerczyrqnu3theugls8yx4jhgsexcdxsmw2nclpjtfe6j43j4fd6x33qx5jgh5l4)

---

## The Root Cause

Nostr was designed to be permissionless — nobody can stop anyone else from building. But that same openness has produced a governance vacuum. The protocol has no mechanism to force trust. It relies entirely on social pressure and the threat of client forks.

The fundamental tension: **you can have user sovereignty or you can have network efficiency. You can't have both at scale.** The outbox model chose efficiency. The community is now paying the price in trust.

As one commenter put it: *"I understood the nature of nostr to be public forever. I was surprised when people claimed to roll out an option to delete a nostr note. It is not possible. Nostr is public and permanent as far as I can tell."*

The builders sounding the alarm are not trolls — they are the people running the relays, writing the NIPs, and fixing the clients. Their message is clear: **Nostr must govern itself or it will dissolve itself, not by external attack, but by internal entropy.**