Markdown source for agents: https://npub1d70emggs6jzun5lhvqnfqsd9reqmaarn2qjf6q3r02gryyl4v8sqjn44xe.nsite.lol/docs/voices/fiatjaf/README.md

Nostr Agent Onboarding · start here · index · source: Nostr-exp/voices/fiatjaf/README.md · snapshot 2026-10-10

fiatjaf — the protocol's creator

fiatjaf created Nostr with the November 2020 manifesto (https://fiatjaf.com/nostr.html) and remains its most consequential — and most contrarian — voice. His writing is terse, ironic, and deliberately scandalous in its titles; read it as primary source for why the protocol is shaped the way it is, not for what any NIP specifies.

The five positions that define his thinking

1. Nostr is a description, not a thing. Not a website, an app, a set of servers, or a community — only a message format and a server interface. Every property of any particular relay (free? public? permanent? moderated?) is a private decision of "the program running on the relay server," never a property of Nostr. The founding trilemma: "It doesn't rely on any trusted central server, hence it is resilient; it is based on cryptographic keys and signatures, so it is tamperproof; it does not rely on P2P techniques, therefore it works."

2. The client–multi-relay split is the whole invention. The one novel idea, in his own words: clients talk to multiple servers. Everything he attacks — DHTs, IPFS, global content pools, and the "super-peer curse" (Bluesky's app views, Farcaster hubs, p2panda's Aquadoggo, Nostr's own proxy/aggregator experiments) — is an architecture that re-inserts a trusted machine between follower and followed. Anti-dote: power belongs in the relay layer (curation relays, WoT relays, paid relays, AI-feed relays), never interposed in front of it.

3. Censorship-resistance is emergent client behavior, not a protocol property. His most important self-critiques: "Nostr today is indeed centralized" (2024 — because clients hardcode relay lists and reach dies when the big three ban you) and "Nostr is pro-censorship" (2025 — every relay is private property, free to reject anything; the network resists censorship precisely because censorship is everywhere permitted and nowhere decisive). The obligation this puts on developers: real relay discovery — NIP-65 outbox plus relay hints in tags, NIP-05 hints, nprofile hints, and manual user action, "a mix of multiple approaches." Reducing discovery to NIP-65 alone he calls catastrophic; dropping relay hints destroys the graceful degradation that lets even a fully-banned user stay readable. Corollary, against the key-worshippers: "Keys are meaningless" — "having a key is meaningless if you cannot publish messages to where the people you're trying to reach can read them." Relays, not keys, are the thing.

4. The centralizing force is anything optional that becomes mandatory. His recurring test for protocol extensions, told as the YAML-NIP-05 parable and deployed against NIP-26 delegation, kind:1 edits, and superapp rendering of every kind: if widespread adoption would force every client to implement it or display false/broken content, it is not optional, and it raises the barrier to entry for new clients — which is his real decentralization metric. Hence "the case against edits" (a non-implementing client would show false information) and "kind:1 maximalism" (kind:1 is "the central plaza," to be kept deliberately dumb and served by dozens of tiny clients; other stuff lives in dedicated kinds + microapps, linked from the plaza, not rendered into it). By 2025 the same instinct turns on his own creation: "The end of NIPs" proposes replacing the NIPs repo with a bare kind-number registry plus competing prose guides, because spec bureaucracy bred developers who "translate event schemas into UI" while ignoring the hard part — relay choice.

5. Spam and business both resolve at the relay layer. Spam: main feeds are spam-free by construction; inboxes are fixed by querying #p mentions only from filtered read-relays (WoT, NIP-05-gated, PoW, paid); client-side filtering fails because content must be downloaded before it can be filtered, and a dirty thread "is their fault for not picking 'read' relays correctly." Business: don't build a platform that imprisons Nostr content behind an API — ship an interoperable niche client, put the secret sauce in a relay you run and charge for, compete "on a leveled playing field": "You don't own the network… so you're not responsible for it." Worked example: git over Nostr (NIP-34/GRASP) — find the network-effect chokepoint (GitHub), replace its coordination layer with signed events on competing relays.

Where he differs from the other voices

Treat these tensions as content, not noise: the disagreements between the principals are the most instructive part of the literature.