Enemies of nostr

Introduction: The Governance Imperative in Open Source

The future will be open source, or it won't be—it's that simple. Our security, sovereignty, and digital agency depend on it. Yet, the history of open source teaches us that code alone is not enough. Without intentional and resilient governance, the very protocols designed for freedom can become centralized and controlled. This is the challenge facing many open systems today, and Nostr is not an exception.

I've been around long enough to see Nostr evolve from a niche experiment into a burgeoning ecosystem. This growth brings new developers, teams, and stakeholders, and with them, new complexities. The informal processes that served the early community are now strained, and my concerns about Nostr's long-term sustainability have grown alongside the protocol.

The discussion around Nostr's governance is not new. For years, some people have highlighted the ambiguities in the Nostr Implementation Possibilities (NIP) process. The recent discourse, including fiatjaf's article, "The End of NIPs", signals a widespread recognition that these challenges exist.

This article explores how a weak or informal governance model can become the Achilles' heel of an otherwise promising open-source protocol. We will examine the political and influence-related risks threatening Nostr, analyze the historical precedents of protocol capture, and discuss how we can begin a crucial conversation about governance to ensure the long-term health of Nostr and other open systems.

Nostr's Governance Paradox

Nostr’s governance presents a paradox. The protocol’s permissionless design is its core strength, yet this very openness creates vulnerabilities if not supported by a clear framework for collaboration. To date, Nostr has not had a formal governance model. The guidelines for proposing, debating, and accepting new specifications (NIPs) have remained ambiguous.

The only documented criteria for NIP acceptance are in a brief section of the NIPs repository's README, which includes subjective measures and is at best unclear.

## Criteria for acceptance of NIPs

1. They should be fully implemented in at least two clients and one relay -- when applicable.
2. They should make sense.
3. They should be optional and backwards-compatible: care must be taken such that clients and relays that choose to not implement them do not stop working when interacting with the ones that choose to.
4. There should be no more than one way of doing the same thing.
5. Other rules will be made up when necessary.

Also, these criteria are optional in practice. NIPs have been merged by maintainers without broad discussion, while some widely implemented proposals have faced resistance and never made their way to the NIPs repository. We also had unexpected updates to merged NIPs, where maintainers removed or added parts without consensus. In some cases, these changes were more significant than just rewording for better clarification.

This ambiguity was compounded when author attribution was removed from NIPs. This change, while seemingly minor, had a significant impact on accountability. In contrast, Bitcoin's BIP-1 explicitly defines the author's role: "the BIP author is responsible for building consensus within the community and documenting dissenting opinions." This model ensures that proposals have dedicated champions who must engage with feedback. The removal of authorship in Nostr created a vacuum where it's unclear who is responsible for the quality and consequences of a specification.

This has led to a challenging environment for developers. Without clear attribution, the natural filter of reputation is diminished. In well-governed projects, developers build credibility through thoughtful contributions, helping the community assess future proposals. The lack of formal contribution tracking in Nostr makes it difficult to recognize work that drives the protocol forward. This, combined with inconsistent processes, has led to a sense of unpredictability, raising the barrier to entry for new contributors.

Don't get me wrong, I love Nostr and truly believe it's the way forward. Nothing changes its permissionless nature—no one can impose anything on you in Nostr. You can bypass the current specifications and create your own if you want; nothing can be imposed top-down. Nostr is a minimized-risk architecture by design, and that will never change. This is what truly makes Nostr permissionless: no one can stop you from creating, signing, transmitting, connecting, deploying, and being sovereign in your own stack.

But sovereignty alone is not enough. Nostr's other superpower is interoperability—the shared language that allows a vibrant, decentralized ecosystem to emerge. This is where the paradox lies. Our freedom to innovate is precisely what makes us vulnerable to political capture.

Imagine if a large corporation or influential group took over Nostr. They propose their own standards and well-defined, opinionated governance guidelines. With their resources and influence, they gain traction in the community, earning trust and notoriety. Then, in the blink of an eye, they achieve a network effect. Implementations of the original protocol become irrelevant because the community has moved on, and Nostr has been captured. Of course, no one can tell you how to use Nostr. However, it's better if it's interoperable.

The Ghosts of Protocols Past

This isn't theoretical. The internet is a graveyard of open protocols that slowly succumbed to centralization, and we must learn from their demise. These stories reveal two primary paths to capture: slow, organic decay and deliberate, corporate co-option.

The slow decay is powerfully illustrated by the history of email. As detailed in a comprehensive review by Jameson Lopp, what began as a decentralized, peer-to-peer messaging system has devolved into a centralized oligopoly. This wasn't the result of a malicious takeover. It was a death by a thousand cuts. The rise of spam led well-intentioned administrators to adopt pragmatic solutions like blacklists and reputation systems. Over time, these measures created a system where email deliverability became a privilege granted by a few large providers, not a right. This is what Lopp calls "commercial capture"—a process where a protocol's founding principles are eroded by the compounding effects of many small, reasonable decisions. See Jameson Lopp's analysis of email system centralization and spam impact.

The second path, deliberate co-option, is exemplified by the "Embrace, Extend, and Extinguish" strategy notoriously used by Microsoft in the 1990s. In this model, a dominant company enters an open ecosystem, extends a standard with proprietary features, and then leverages its market power to make its version the de facto standard, effectively extinguishing the original. See Microsoft's "Embrace, Extend, and Extinguish" strategy overview.

Other cautionary tales abound. DNS, the internet's addressing system, is now governed by ICANN, a centralized authority that has become a chokepoint for political pressure. OAuth, once an open standard for authorization, is now a federated system dominated by a few tech giants. In each case, a permissionless ideal was compromised by the gravitational pull of coordination, resources, and network effects. See ICANN and DNS governance and OAuth standard history and current centralized control.

This highlights the fatal flaw of the "bazaar" development model, famously contrasted with the top-down "cathedral" model by Eric S. Raymond. Nostr is a quintessential bazaar—a chaotic, bubbling marketplace of ideas. This model thrives on a small scale, but without a resilient governance structure, it struggles to withstand the pressures of growth. It either collapses or, as history shows, is quietly acquired by a cathedral. See Eric S. Raymond's "The Cathedral and the Bazaar".

The forces driving this centralization are predictable and relentless:

1. Resource Concentration: Organizations with deep pockets can out-invest independent contributors, gradually steering a project's direction.

2. Coordination Complexity: As a project grows, decentralized decision-making becomes exponentially harder, creating a vacuum that centralized actors are happy to fill.

3. Network Effects: Popularity creates pressure to standardize, giving dominant implementations disproportionate power to set de facto standards.

The history of open source is clear: informal governance is a luxury that successful projects cannot afford. As Nostr grows, we must choose: either we intentionally design a resilient governance framework, or we accept the slow, inevitable slide into centralization.

Modern Threats to Open Governance

I don't think Nostr has been captured yet, but it faces serious risks, especially if we overlook the potential damage of current trends.

Political attacks on open source projects exploit their collaborative and trust-based nature, targeting social and governance structures. These attacks are insidious and difficult to detect, as seen in the XZ Utils incident, where a malicious actor gained maintainer privileges through long-term social engineering.

State actors pose a significant threat, with the resources for sophisticated long-term influence operations. With 70% of software being open source, successful infiltration can have far-reaching consequences. These actors may create fake personas, steer project direction, or introduce divisive topics to fragment communities.

AI and LLMs add another dimension to these challenges. While they can accelerate development, they can also quickly analyze and replicate novel implementations, leading to "innovation appropriation." In ecosystems like Nostr, where value lies in both code and creative architectural insights, this dynamic can disincentivize grassroots innovation.

The psychological toll is severe. Seeing their work ignored or appropriated without credit is demoralizing for innovators, leading to burnout and a brain drain of creative minds. This creates a vicious cycle where established figures dominate the narrative, attract funding, and accumulate decision-making power, turning open source into an oligarchy of influence. Nostr's lack of attribution and formal governance makes it susceptible to this new form of capture.

These new tools also lower the cost of some attacks, making social engineering attacks like phishing more feasible. A recent example is the attack on the NPM registry, where a phishing attack was used to introduce malware into well-known and widely used packages.

A Blueprint for Resilient Governance

The challenges facing Nostr are not unique. By looking at other successful, long-standing open-source projects, we can find inspiration for a path forward. I think that the key is to establish clear guidelines for proposing, debating, and finalizing changes, fostering collaboration while preserving the freedom to innovate.

The Lightning Network, for example, offers an instructive model with its dual-layer governance. BOLTs define the core standards that all implementations must follow for interoperability. BLIPs, on the other hand, provide an experimental layer where new ideas can be tested. This separation allows ideas to mature in the real world before being considered for standardization.

Similarly, Bitcoin's BIP process, Python's PEPs, and Rust's RFCs all provide templates for successful governance. These projects are used globally by everyone from solo developers to large corporations because they have found a way to manage complexity and provide a stable foundation. Developers and companies can invest their time and resources with confidence, knowing that the process for evolution is clear and predictable. Without this clarity, a project risks brain drain and a loss of investment as stakeholders grow wary of instability.

From these examples, we can derive a set of potential components for a more resilient Nostr governance model. This is not a rigid proposal, but a starting point for discussion.

Key Governance Components

• Dual-Layer Specification Structure: Following the Lightning Network, we could establish a distinction between Core NIPs (foundational, interoperable standards) and Experimental NIPs (a space for innovation). This would allow new ideas to be developed and tested without destabilizing the network.

• Clear Specification Guidelines with Author Accountability: A formal NIP template could include standard sections like Abstract, Motivation, Rationale, Backward Compatibility, Reference implementation, and Inter-dependencies between standards. Crucially, restoring author attribution would make authors responsible for building consensus and documenting dissenting opinions, re-establishing a clear line of accountability and reputation.

• Defined Lifecycle Stages: A NIP could move through distinct stages (e.g., Draft, In-Review, Final). Each stage would have clear exit criteria, such as requiring multiple implementations before a NIP can be considered Final. This would prevent untested ideas from becoming de facto standards.

• Transparent Consensus Mechanisms: The process for reaching consensus should be clearly defined. This includes considering all relevant parties, such as maintainers, developers, experts, and stakeholders, and outlining how decisions are made. This transparency helps prevent power from concentrating and ensures that the evolution of the protocol reflects the broad interests of the community.

• Transparent Processes for Updates: Clear mechanisms for updating, superseding, or withdrawing specifications are needed. This would create a clear history of changes and prevent the kind of undocumented updates that currently break implementations.

• Reputation-Based Contribution Framework: A system for recognizing contributor history could help balance the influence of established experts with the need to welcome new participants. This is not about creating a rigid hierarchy, but about acknowledging expertise while remaining open to new ideas.

It's important to stress that such a framework should not limit experimentation. Nostr is permissionless by design. Specifications that don't follow a formal process can and should still exist. The goal is simply to provide a clear path for ideas that aim to become part of the interoperable, consensual core of the protocol, or for documented experimentation.

Conclusion: Securing Nostr's Future

The paradox of open-source governance lies in a fundamental tension: systems designed to be open and distributed often evolve toward centralization due to practical, economic, and political pressures. This phenomenon represents one of the most significant challenges facing foundational internet technologies today.

Nostr stands at a critical juncture. Its minimalist approach has been a key to its growth, but the absence of a formal governance process creates vulnerabilities that could lead to centralization. The challenge is not necessarily to prevent all forms of centralization, but to design a governance structure that enables effective coordination while preserving the open and permissionless nature of the protocol.

The lessons from DNS, OAuth, and other once-open systems serve as cautionary tales. The emergence of AI adds new urgency to this challenge, accelerating the dynamics of innovation appropriation and power concentration. Without intentional governance, Nostr risks following a similar path, where the forces of centralization gradually erode its founding principles.

This conversation is not just a thought exercise; it is a critical discussion for the future of the protocol. By addressing these governance challenges proactively, we can ensure that Nostr remains a vibrant, innovative ecosystem that empowers its users and ecosystem.