quoting
naddr1qv…3nzyThis week, Alex Gleason announced the release of NostrHub 2.0, a nostr-native place for nostr protocol documents (affectionately referred to as “NIP”s). This is a significant step forward in aligning the process of protocol development with the radically decentralized and relativistic ethos of the nostr development community.
I thought I’d take this opportunity to try to articulate what I have considered the key weakness and dysfunction of nostr for several years now: an unwillingness to be political. This deficiency in the nostr community affects everything: from interoperability and coordination of work, to funding and marketing. But in this post I will be focusing mostly on governance of the protocol itself.
The Necessity of Politics
I have to begin by defining my use of the term “politics”. This term has a connotation of endless parliamentary debates, arbitrary statute, and the grinding, corrupt, mindless mechanics of the State. But the word itself comes from “polis”, which is Greek for “city”.
This, not the nation-state, is what Aristotle had in mind when he wrote that "the city is best governed which has the greatest opportunity of obtaining happiness" (Politics, VII.13). Aristotle goes on to say that "happiness is the realization and perfect exercise of virtue", and that "virtue and goodness in the state are not a matter of chance but a result of knowledge and purpose."
In other words, people get together for a purpose, and it requires deliberate effort and virtue to accomplish that purpose, whether in the context of a family, neighborhood, community, chat group, social network, activist movement, business, or protocol standardization process.
“Government” does not imply democracy, monarchy, or any other scheme in particular — but it does imply that some scheme for government is in play. Just as there is not such thing as a place without an architecture (even if that architecture is “everyone builds whatever he wants”), there is no such thing as a group of people without governance.
Politics is collective meta-action for the purpose of organizing purposeful collective action. Choosing some particular form of government (or, to connect my metaphors, a social architecture) allows a community to accomplish something its members would not be able to do on their own. This meta-action is performed in any group by definition, even if by accident or default. Politics is inescapable.
For and Against
Let’s set aside the much more popular authoritarian vs anti-authoritarian debate for now, because it’s not really relevant. The ideal end state for self-governance on nostr is not to have a benevolent dictator, mega-corporation sponsors or working groups dictate what the protocol is or how it should be used, but to allow grassroots participation in the standardization process.
But that doesn’t mean we’re not allowed to build institutions.
There is an attitude prevalent on nostr that any kind of stewardship, funding, rule, content filtering, or social status directly contradicts the plebeian ethos of the community and protocol.
At best, this type of thinking is unable to build anything influential or lasting because it relies entirely on good people contributing to the mission voluntarily in their free time without coordination. Ironically, this is its own kind of elitism, because these people are only able to do so because they have the personal and material means to participate in such idealistic purism.
This mentality has a darker side though. Because it can’t stand any appearance of centralization, authority, or control, it is essentially corrosive to any institution it comes into contact with. It sees any kind of collective action, however aligned or small-scale as a threat. This happens when revolutionaries who are dissatisfied by the status quo don’t have a long-term vision for what they want to build instead — all they can do is identify targets to destroy. Ironically, this results inevitably in nepotism and consolidation of power if the movement succeeds.
This approach to self-government is essentially Marxist (whether the revolutionaries know it or not). It is an application of the Hegelian conception of history to material conditions, and seeks for ideological purity in material terms. But Marxism isn’t limited to establishmentarian solutions like Communism; later Marxist thought makes it clear that the obligation of every human being (a sort of psychological proletariat) is to subvert “the superstructure” in order for “justice” and “authenticity” to emerge.
The problem is, the superstructure (which includes pretty much anything that would be recognizable as an institution) is what keeps the wheels from flying off. An engineer has to practice discipline, learn his art, understand his materials, and plan for success. Success does not happen automatically. In order to accomplish anything worthwhile at all, deliberate, structured work has to be done.
Organization is not authoritarianism.
Cooperative Institutions
In Elinor Ostrom’s Governing the Commons she describes “common pool resources” and the ways in which they are governed. Without institutions in place to restrain the destructive actions of self-interested individuals, common pool resources suffer a “tragedy of the commons” which ultimately degrades or destroys the shared resource. The classic example is that of shared fishing areas — if over-fished by a single party, the yield ultimately drops for the entire community that depends on the resource.
Ostrom explains the ways in which solutions to common pool resource problems that depend entirely on resource privatization or state intervention fail to address the problem, advocating instead for localized cooperative institutions that are established and maintained by the community itself to safeguard the common pool resource.
Inevitably, these small-scale institutions establish codes of conduct and standards for how to access the common pool resource, or contribute to its governance. This is, in a certain sense, a type of “gatekeeping.” But unlike a form of gatekeeping in which rent-seekers exploit a common pool resource for personal profit, a healthy institution will maximize the benefit for all participants while also protecting the resource itself. In Ostrom’s words:
At the most general level, the problem facing CPR appropriators is one of organizing: how to change the situation from one in which appropriators act independently to one in which they adopt coordinated strategies to obtain higher join benefits or reduce their join harm.
In order to accomplish commons governance, a number of political techniques may be employed: voting, fees, laws, ostracism, shame, testimony, authority, status, and expertise to name a few. Not all of these techniques have to be employed, but some of them must be.
Nostr as a Commons
Nostr is several different things: it is a community, infrastructure, and a protocol. Each of these things requires its own form of governance. The first two facets are actually pretty easily solved, because nostr is itself a solution to the problem of governing a social network by privatizing the infrastructure to support a multitude of different content moderation policies expressed through relay and client implementations.
Governance of a protocol is more difficult because in order for it to exist, it must be singular. In other words, it requires consistency. In the past I’ve argued that nostr when viewed as a database is AP — it’s available and partition tolerant, but it is not consistent. In political terms, nostr itself cannot facilitate consensus. This is why nostr can’t solve problems like transfer of digital property — you need a blockchain to solve the double-spend problem.
A protocol needs consistency by definition — a protocol is essentially a definition of terms. In order for a language to function, there has to be agreement on what words mean. My client cannot validate events if the author signed them using a ed25519 key instead of a sec256k1 key. Likewise, we have to agree on how encryption works, what schema a kind supports, what the semantics of a given kind are, how to hash events, and what relays to send a particular event to in order for anything to work. Divergence undermines interoperability.
So what would a “tragedy” of this commons look like? Commons are ruined when the incentives of individuals don’t align with the incentives of the community. The value proposition for developers is access to network effect through interoperability, which means the incentive of the community as a whole is to maximize compatibility. The lack of or instability of a canonical specification undermines this value proposition.
Meanwhile, individual developers have two perverse incentives: to support their own feature set without compromise (leading to divergent specs), and to offload the work required to maintain interoperability to other participants in the community.
The goal, therefore, of an institution built to safeguard the protocol for the good of the entire community should do two things:
- Facilitate the discovery and repair of interoperability gaps against a canonical specification (nostrability has done some good work here).
- Facilitate the maintenance of a canonical spec by lowering the cost to individuals to participate in the process (the NIPs repos maintains a spec, but it’s neither comprehensive nor cheap to contribute to).
Divergence will necessarily exist in a decentralized permissionless network. Non-conforming implementations will compete for network effect, and convergence might not happen for some time. But this isn’t an argument against having a single spec — it’s proof that we need one.
Consensus is a political process. Contention over a single event kind cannot be resolved without a meta layer of communication about the protocol. Solipsistic “specs” published to a project’s repository or as a nostr event are anti-specs. They completely punt on the (very difficult) problem of building consensus, leaving implementation divergence in perpetuity.
What We Have
This problem has a simple solution: publish a canonical spec. This is the solution we have today. By combining the techniques of expertise (how involved has a person been with nostr and for how long), status (how popular is this person or his implementation), rules (a NIP has to have at least 2 implementations), access controls (only certain people can merge a NIP), protocols (open a PR in order to get a NIP merged), rhetoric and logic (argue ad nauseam with the maintainers), and others, we have been able to compile a 78,636 word canonical specification that implementers can use as a reference for well-established protocol features.
This is a real accomplishment. This is a functioning, local, community-led institution. Although it has taken the “privatization of public property” route that Ostrom rejects, it is far better than nothing. And the charges of nepotism and gatekeeping are overblown — in practice, it’s like any other open source project. Anyone can contribute if they follow the social norms established by the community. It’s not perfect, but it does work.
Maintaining an institution is tedious, thankless work. In exchange for making consensus possible, the maintainers have to read reams of human and AI-generated slop, make difficult judgment calls, and get called names by the people using the protocol they help maintain. I personally got so sick of it that a few months ago I asked to have my merge access removed so I could focus on building my own project. But that just leaves more work for the remaining maintainers to do.
If you’ve ever been irritated at the governance of the NIPs repo, let me just appeal to you to remember Hanlon’s razor. The maintainers of the NIPs repository frequently do a sub-optimal job. But they are not power-tripping as some would suggest; they’re just getting in and out quickly because maintaining the repo is a pain in the ass.
Today, if you want your spec to be adopted by other people (increasing the influence your implementation has on the network), the best place to put it is in the NIPs repository. This is where most people look first, and is what shows up most readily in search engine results. Publishing anywhere else degrades the fidelity of the spec, and sabotages your own effort to publicize your work.
I can identify two reasons why people might choose not to participate in the NIPs process. One is the muddled and dogmatic anti-institutionalism I mentioned above. The other is simply a reasonable aversion to the political process. Depending on who you are, you might be intimidated by process, bored by the endless arguments, or resent maintainers for not merging your spec. In any case, I think this just boils down to laziness. You want your ideas to be acknowledged, but you’re unwilling to do the crappy work of getting other people on board. You don’t want to open a PR because you hate the maintainers, or you’re afraid of it getting rejected, or you don’t want to bother defending your position. If that’s the case, you’re a freeloader, not an anarchist.
The reason the NIPs repository currently has 443 open pull requests is twofold: the maintainers don’t want to waste their time going through old PRs and closing them or nudging people. Some things just aren’t worth fixing. The other is that the authors have abandoned them (or at least don’t advocate for them), or have otherwise failed to get community buy-in. I personally have 20 open PRs. This isn’t because the maintainers are “gatekeeping”, it’s because my implementations are the only ones that exist so far, and I haven’t been able or willing to convince other people to adopt them. It’s my fault. I take responsibility. It doesn’t bother me that no one else cares about my ideas. Maybe they’re not good, or Flotilla isn’t popular enough.
I know you won’t, but take my word for it: the NIPs process is open to anyone. Some NIPs get merged faster than others, and yes, maintainers are sometimes assholes. Resort to back channels. Canvas support for your idea. Open PRs to other people’s projects. Post updates. It’s not that hard, but I don’t see very many people doing the work.
Where We’re Going
I want to return now to Gleason’s NostrHub project. Zero people, maintainers or otherwise, would claim that the NIPs repo is the ideal way to govern the protocol. But the people who are loudest about it have done nothing to propose something better. Instead, they spend their time on character assassinations and projects no one uses. It reminds me of Dennis: “help, help, I’m being repressed!”
Alex, on the other hand, has stepped up and built something that moves the NIPs off of a Microsoft product and onto nostr itself. Instead of setting himself up in competition with the NIPs repository, he has imported the existing NIPs, and created a default list of nostr “experts” which respects the 3+ years of contributions the NIPs repo maintainers have put in. This is politics at its best. He’s coalition building. He’s virtue signaling equally to all the different stakeholder groups. He’s solving the problem without burning down the institutions.
I have reservations about NostrHub. I think Alex’s vision of NIP forking is still too permissive of spec divergence, social proof features notwithstanding. And a new piece of software does not replace the inherently social process of building consensus. Arguably it makes it more complex, at least until the meta-consensus has materialized around NostrHub. Unless someone (or many someones) put in the work to synchronize not only specification documents but also conversations across the NIPs repo and NostrHub, merge NIP forks into the upstream, and curate “community NIPs”, this will only add more noise and confusion.
For that reason, I think it’s important to expedite this process. Here are some action items that I would like to see from Alex, as well as anyone else who is eager to dispense with the Nostr Priesthood:
- For Alex (or anyone who wants to contribute to NostrHub): define “canonical” on NostrHub. Forking is good as a way to propose changes, but the purpose of a fork is to be merged in (or to supersede the original). There has to be a way to determine which version of a NIP is the one that should be implemented, and how to push provisional divergence forward toward convergence. A single word cannot have two meanings. If we want plurality, then naming the top-level forks should be supported. I’d also like to see a story for keeping updates to the NIPs repo in sync with NostrHub.
- For nostr “experts”: go to NostrHub and endorse the NIPs you care about. Stress test Alex’s new system by proposing stuff there instead of on github.
- For other developers: get involved. Whether on the NIPs repo or on NostrHub, I don’t care. But don’t let your spec rot in your application’s repository. Post it somewhere, tell people about it, open PRs to projects, contribute to Sherlock. Be like Elsat. If you are willing to help maintain the NIPs, become a maintainer (either by asking fiatjaf or by somehow becoming a NostrHub “expert”).
- For users: report interoperability bugs and unexpected behavior. We can’t fix things if you don’t tell us they’re broken.
Nostr is just as much a social experiment as a technical one. Pulling both levers at once increases the risk of failure in some critical area. Let’s incrementally improve our existing institutions instead of burning them down.
hodlbod on Nostr: Something that's been on my mind for a few years now. I wish people could just think ...
Something that's been on my mind for a few years now. I wish people could just think the best of each other instead of splintering into tribes over dumb stuff.