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

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

fiatjaf on Nostr: annotated bibliography of his web essays

Research pass over https://fiatjaf.com (essay hub: https://fiatjaf.com/nostr.html, full Nostr tag index: https://fiatjaf.com/-/tags/nostr). All 24 Nostr-tagged essays were fetched and read in full on 2026-08-31; the 21 most substantive are annotated below, grouped by theme. Dates are the ones printed on each page.

Synthesis: fiatjaf's philosophy of Nostr

Across these essays, fiatjaf's Nostr is not a network, a platform, or even a set of servers — it is a description: a minimal message format (signed events) plus a minimal server interface (relays), and nothing else. Everything he values follows from that minimalism. The founding manifesto's one-liner still governs everything he writes: no trusted central server (resilient), cryptographic signatures (tamperproof), and — the deliberately contrarian third leg — no P2P techniques, therefore it works. He is openly hostile to DHTs, global content pools, blockchains-for-social, and "super-peer" architectures (Bluesky/ATProto, Farcaster, p2panda, IPFS), all of which he sees as either physically unworkable or as re-smuggling a trusted server in through the back door. The alternative he insists on is the multi-relay client: a genuinely independent "user agent" that talks to many dumb, private, mutually-independent servers, assumes any of them may be evil, and does the hard work of figuring out where to read and write. Censorship resistance, in his telling, is not a property of the protocol at all — it is an emergent property of clients doing relay discovery properly (relay hints, NIP-05 hints, NIP-65 outbox lists, manual action, "a mix of multiple approaches"). Hence his most striking self-criticisms: "Nostr is not decentralized nor censorship-resistant" (today, because clients hardcode relay lists) and "Nostr is pro-censorship" (every relay is private property free to reject anything; freedom lives in the reader's ability to look elsewhere). Even keys, the thing newcomers worship, he calls "meaningless" — an unnecessary burden that exists only to enable relays.

His design guidance for developers is a consistent ethic of keeping it simple to write a client, because the barrier to entry for clients is, to him, the real decentralization metric. Anything that starts optional but becomes de-facto mandatory once widespread — NIP-26 delegation, note edits, YAML variants of NIP-05, superapp rendering of every event kind inside kind:1 feeds — is a "centralizing force" to be resisted, however innocent it looks. He wants kind:1 microblogging kept as a deliberately dumb, neutral "central plaza" served by dozens of small clients, with "other stuff" (recipes, music, git, calendar events) living in dedicated kinds, dedicated microapps, and topical or curated relays, linked from the plaza rather than absorbed into it. Businesses should not build platforms that imprison Nostr content behind an API; they should ship an interoperable client and run a value-adding relay that competes "on a leveled playing field" — the magic sauce goes in the relay, the network stays owned by no one. By 2025 this anti-ossification instinct extends to the standards process itself: "The end of NIPs" proposes abandoning the NIPs repository for a bare kind-number registry plus competing prose guides, because spec bureaucracy was producing developers who translate event schemas into UI while ignoring the actually-hard part, relay choice.

The temperamental throughline is an embrace of chaos and markets over guarantees and committees. Nostr "can't ever promise perfect reachability, no protocol can"; relays are houses, and if someone's thread is full of spam "that is their fault" for choosing bad read-relays; users who lose keys can painfully rebuild, unlike money, so key management needs no mandatory scheme. He is ironic, self-deprecating ("I hope you got my point and agreed because this article is ended"), and dismissive of slogans — including Nostr-community slogans like "not your keys, not your notes" and "self-sovereign identity". But the irony sits on top of a rigid core conviction: the client–multi-relay split is the only social-network architecture that has ever aligned incentives with censorship-resistance, and nearly every proposed "improvement" is an attempt to reintroduce the platform.

Theme 1 — Foundational vision: what Nostr is (and is not)

nostr - Notes and Other Stuff Transmitted by Relays

The founding manifesto, written before any implementation existed. It defines Nostr as clients and relays only: users sign posts with their keys and send them to multiple relays; readers query multiple relays; relays are "very simple and dumb," never talk to each other, and are never trusted (signatures are verified client-side). The bulk of the document is a demolition of the alternatives: Twitter (ads, addiction techniques, bans, shadowbans); Mastodon (identities attached to third-party domain names, server despotism, lost followers on migration, no incentive to run servers, painful server-to-server pushing); SSB (great idea, but over-complicated protocol quirks like ECMA-262 JSON signing and a mandatory per-user chain of updates); and everyone-runs-their-own-server schemes (people won't, and domains get censored). It then argues Nostr solves banning (identity is a key, not an account; move relays and followers follow via relay recommendations), censorship (paid relays: "there will always be some Russian server willing to take your money"), spam (relays can charge or authenticate), and heavy content (relays can reject or charge for it). A prescient FAQ already concedes the discovery problem: if you share no relay with someone you cannot see them, hints can help, and "we can't ever promise perfect reachability, no protocol can." The famous answer on why nobody built this before: companies want money, P2P activists want zero servers, and "they both fail to see the specific mix of both worlds that Nostr uses."

"The simplest open protocol that is able to create a censorship-resistant global 'social' network once and for all." — https://fiatjaf.com/nostr.html

"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." — https://fiatjaf.com/nostr.html

Nostr: a quick introduction, attempt #1

The first of three attempts at explaining Nostr to normal people, each with a different emphasis. Here Nostr "doesn't have a material existence, it is not a website or an app" — it is a description of messages computers can exchange, which lets different apps connect to different servers automatically with no contracts or behind-the-scenes coordination. He compares it to the internet itself: millions of websites, anyone can run one, but with one shared "language" that makes switching relays clean — so a ban just moves the author, and conversely no relay has to "uphold a moral ground of 'absolute free speech'": relays may delete or ban for no reason and nobody is entitled to complain. He is candid about the costs: no guarantee any relay has the notes you want, users may see different reply sets and be confused, and malicious relays could edit notes — which is the actual reason for signatures, whose price is the dreaded nsec the user must guard. The signature "fix is perfect" except for that key burden, which at least yields portable identity and third-party-free login.

"To conclude: Nostr is like the internet (or the internet of some decades ago): a little chaotic, but very open." — https://fiatjaf.com/d0b15ac7.html

Nostr: a quick introduction, attempt #2

The shortest and most political framing. Nostr explicitly does not subscribe to "free speech" ideals, which he says belong to politics and presuppose a powerful government enforcing a common rule. Instead, Nostr says servers are private property and provides "a generalized framework for people to connect to all these servers, creating a true free market" — Nostr is the public road, relays are the private stores along it. Concretely it is just data-format definitions over WebSocket with signatures, a base on which sub-protocols (microblogging, group chat, "recipe sharing and feedback") get layered. This essay is the cleanest statement of his market-libertarian reading of the architecture, later expanded in "Nostr is pro-censorship."

"Nostr instead is much simpler, it simply says that servers are private property and establishes a generalized framework for people to connect to all these servers, creating a true free market in the process." — https://fiatjaf.com/ded75cbc.html

Nostr: a quick introduction, attempt #3

Aimed squarely at a misconception he keeps meeting: people who hear "relays" and imagine a set of free public servers, then ask "who will run these relays?" or "how is this censorship-resistant if you can take down the relays?" His answer: "Don't be one of these people." Nostr is only the interface description — a relay understands ["REQ", "z", {"limit":10}] and nothing else. Whether a relay is free, whether it stores your event, whether it deletes it after a while or keeps 32 redundant copies, whether it serves everyone or only some people — every one of those is a private decision of "the program running on the relay server." The essay is a drumbeat repetition of that clause, hammering home that no property of any particular relay is a property of Nostr.

"Nostr is not any specific set of relays, and relays are not meant to be public or free." — https://fiatjaf.com/0601c1ca.html

Visual depiction of the architecture of 3 different decentralized social networking protocols

A short comparative piece (with diagrams on the page) contrasting the Fediverse, Nostr, and ATProto. The Fediverse ("Mastodon is the de facto controller of the protocol"; ActivityPub proper he calls a broader spec "conceived by the minds of unreasonable academics, unimplementable in nature" and only partly adopted) is clients talking to a single server that talks to other servers. ATProto/Bluesky's core idea is decomposing the social server into three kinds of servers in a pipeline. Nostr's single core novelty is stated in one clause — clients talk to multiple servers — and he owns the consequence proudly: the result is chaos, and the chaos is the point. Useful as the most compact statement of what he thinks is architecturally distinctive about Nostr versus its two main competitors.

"its core new idea is that clients can talk to multiple servers, which gives us a very chaotic ecosystem of signed messages." — https://fiatjaf.com/52a0d652.html

Theme 2 — Relays, discovery, and what censorship-resistance actually requires

A vision for content discovery and relay usage for basic social-networking in Nostr

His canonical design document for how a Twitter-like client should actually use relays — the essay the later "not decentralized" polemic points back to. He models three app views (home feed, profile, replies; optionally global) and classifies relays subjectively as spammy, safe (fee/registration barriers but fundamentally open), or closed (friend groups, communities). The heart is the follow flow: to follow someone you must learn some relay where they publish, bootstrapped from wherever you met them — relay URLs embedded in e/p tags, nprofile URIs, NIP-05 relay lists, or (worst case) a bare npub requiring prompts or searching your known relays. Clients must then continuously mine relay hints from every event seen anywhere to keep a local profile→relay database fresh as people migrate. Rendering follows from this: home and profile feeds can safely query even spammy relays (the author filter protects you), but reply views and global feeds must query only safe/closed relays or spam gets injected. He closes by admitting the many corner cases (resolving a referenced note via its hint, the mentioner's relays, the relay you saw the mention on...) and that all of it "may fail and then it is probably not a big deal."

"Nostr is just a very loose set of servers with basically no connection between them, there are no guarantees of anything, and the process of keeping connected to others and finding content must be addressed through many different hackish attempts." — https://fiatjaf.com/3f106d31.html

"To write Nostr applications and to use Nostr one must embrace the inherent chaos." — https://fiatjaf.com/3f106d31.html

Nostr is not decentralized nor censorship-resistant

A remarkable self-critique conceding (charitably) Peter Todd's long-standing accusation. His experiment: two identical notes published simultaneously, one to three popular relays (nostr.wine, nos.lol, pyramid.fiatjaf.com), one only to his own relay — which he announces in his NIP-05 and NIP-65 relay list, i.e. exactly where clients are supposed to look. The first got vastly more engagement, which "shouldn't have happened at all" if clients actually followed people rather than followed relays. He draws the political consequence: a figure banned by the three biggest public relays would instantly drop to ~10% reach — the same fate as personalities deplatformed from corporate social media — "in that sense Nostr today is similar to what we had before." The crucial distinction he insists on: Todd is right about the present, wrong about the design — the failure lives in clients that subscribe to a static relay set, not in the protocol, and it is fixable by driving clients toward real relay discovery.

"Nostr today is indeed centralized." — https://fiatjaf.com/87a208d9.html

"Peter Todd is wrong that Nostr is inherently centralized or that it needs a protocol change to become what it has always purported to be." — https://fiatjaf.com/87a208d9.html

Censorship-resistant relay discovery in Nostr

The constructive companion piece, published the same day. It gives the history of the discovery problem: the idea was always that clients would follow people "in the relays they decided to publish to, even if it was a single-user relay hosted in an island in the middle of the Pacific ocean," but nothing ever enforced this (nothing could), and his own first client Branle shipped with "a stupid static list of relays" anyway. Mike Dilger's Gossip was the first client to do censorship-resistant discovery for real — NIP-05 hints, relay hints, kind:3 relay lists — and NIP-65 then crystallized it into what got popularized as the "gossip model"/"outbox model," adopted by Coracle and Snort. His warning: reducing the outbox model to just NIP-65 is "too restrictive" — NIP-05 hints, nprofile/nevent hints, and event-tag hints all still matter and should be used together. He ends by arguing the space is not finished: manual user action is "underrated" (if not designed "by people that think users are dumb animals"), and resilience will come from deliberately mixing many mechanisms rather than standardizing one.

"Reliance on third-parties, hardcoded values, social graph, and specially a mix of multiple approaches, is what Nostr needs to be censorship-resistant and what I hope to see in the future." — https://fiatjaf.com/bc63c348b.html

Why relay hints are important

A rebuttal to Coracle's removal of support for relay hints in event references in favor of pubkey hints plus kind:10002 (NIP-65) alone. He piles up concrete cases the pure outbox model cannot handle: posts inside NIP-29/NIP-87 communities whose relays are in nobody's outbox list; a conference-only relay whose events could never be referenced from outside; a user whose big outbox relay periodically nukes old events while their archive lives on cellar.nostr.wine; topical relays (cooking recipes) that users publish to exclusively; one keypair running two personas with two different kind:10002 lists on different indexers; relays that reject certain kinds; and finally the fully-banned user — an "Alex Jones" who cannot even get his kind:10002 onto index relays could still live "a normal Nostr life" via nprofile business cards and per-event relay hints, but without hints he is simply unreadable. The essay is the strongest statement of his view that hints woven through events, not any single published relay list, are what make Nostr's reachability degrade gracefully under adversarial conditions.

"That is a catastrophic idea that destroys much of Nostr's flexibility for no gain at all." — https://fiatjaf.com/8ce7df34.html

The only solution to Nostr spam

His mature position: spam is solved at the relay layer, not the client layer. Main feeds have no spam problem by construction (you read people you follow, from relays you chose). Inbox spam (mentions/replies in notifications) is fixed by clients querying #p mentions only from the user's NIP-65 "read" relays — and by users choosing read-relays that actually filter: relay.mostr.pub's NIP-05 requirement, his pyramid inbox's 2-level web-of-trust filter, PoW or paid relays as fallbacks; he calls for public filtered inbox relays to become client defaults so newcomers never see spam. The hardest case is other people's threads: you fetch replies from their read relays, and if those are garbage, "that is their fault" — an incentive structure where clean threads are each user's responsibility, socially correctable, like not visiting a house that is always dirty. The final section rebuts the do-it-all-client-side camp: mutes don't stop bots with infinite keys; client-side WoT fails because "content must first be downloaded before it can be filtered" (at scale, gigabytes of spam daily, and a 500-reply flood already starves naive queries); client-side filtering is monolithic where relay choice is composable; and purely local filtering is a tragedy of the commons, since it leaves every visitor to your threads fending for themselves.

"If the practices outlined above become widespread, it will also become evident that, if you're seeing spam at someone else's thread that is their fault. It's their fault for not picking 'read' relays correctly." — https://fiatjaf.com/6fcc40bf.html

Nostr is pro-censorship

Deliberately titled to scandalize, this is his deepest statement of why the relay architecture works where "anti-censorship" platforms failed. The core of Nostr is not keys but the fact that a client can reach a huge number of independent servers, "from a modest server at his basement to a big cloud relay," without trusting any. Platforms and protocols built on "a big common 'global' pool of messages" all eventually broke on the same rock: someone must host the content, hosting has costs and moral and legal implications, "and there will never be a global agreement between all the peoples of the Earth about whom or what should be allowed" — even rate-limits and IP blocking are a form of censorship. Nostr dissolves the problem by definition: no global pool exists, every relay is independent, and it is the reader's job to figure out where to read — so every relay is free to censor as much as it likes, and the network as a whole becomes censorship-proof precisely because censorship is everywhere permitted and nowhere decisive. The closing caveat carries the whole weight: all of this "breaks down if apps relinquish their obligation to figure out what relays to read from and decide to read from a static list of relays."

"no relay has any obligations to please all the peoples of the Earth and is free to impose any limits or policies it wants." — https://fiatjaf.com/3a914800.html

Keys are meaningless

The short, sharp companion to "Nostr is pro-censorship," attacking key-worship among technologists. Secret keys are "just numbers"; a script can mint a bazillion of them with zero effect on the world. He rejects the slogans "not your keys, not your notes" and "self-sovereign identity" as meaningless — "people are not keys," and by key-worshipper logic a person locked in a cage is "free" because only they can move their own body. Sovereignty ("what an unfortunate word") means nothing without means of action in the world; for Nostr the means of action is publishing to places where your audience actually reads. Keys are, in his phrase from the sister essay, an unnecessary burden that exists to enable the thing that matters: relays.

"having a key is meaningless if you cannot publish messages to where the people you're trying to reach can read them." — https://fiatjaf.com/cb4ca47a.html

Theme 3 — Protocol design discipline: what NOT to do

How being "flexible" can bloat a protocol

A parable ("a somewhat absurd example, but you'll get the idea") about how optional niceties become mandatory burdens. One client charitably supports NIP-05 files in YAML at /.well-known/nostr.yaml alongside JSON — harmless, surely. A user's YAML file works there, so when other clients "break," the user complains to their developers, who, fearing an incomplete client, add YAML support too; the cycle repeats until YAML is extra-officially part of the spec and every future client forever does double the work. The mechanism — user-facing pressure ratcheting one client's kindness into everyone's obligation — is the same one he later invokes against NIP-26, against edits, and against superapp kind-rendering. It is his most compact statement of why "why not?" is never a sufficient argument for a protocol extension.

"The end result of this is that now nip05 extra-officially requires support for both JSON and YAML files. ... A lot of work was wasted for nothing." — https://fiatjaf.com/27598e6f.html

Why I don't like NIP-26 as a solution for key management

The essay that effectively killed NIP-26 (delegated event signing) as a general mechanism. He recounts its origin in the needs of Minds.com — letting a custodial platform key be statelessly associated with a user's self-owned key via a delegation tag — and stresses that its whole appeal to him was that it was "fully optional": clients ignoring it would just see two identities, both with faces and histories, no harm done. Then the community started treating NIP-26 as the key-management story: a cold master key on a hardware device signing monthly delegation tags for per-app throwaway keys. That flips the property that made it acceptable: now the active keys are "faceless entities," and a client that doesn't implement NIP-26 sees only "a constant stream of random keys" — unable to follow or interact with anyone. So NIP-26 becomes de facto mandatory for every client, breaking the simplicity of the protocol for a solution he considers partial and inelegant anyway. If a mandatory delegation scheme is ever truly needed, he argues, it should be designed fresh rather than rushed — but key management can instead be solved by many optional approaches coexisting.

"So now every client must implement NIP-26 to become usable at all, it is not optional anymore." — https://fiatjaf.com/4c79fd7b.html

Thoughts on Nostr key management

The constructive sequel to the NIP-26 essay, listing techniques that "work in tandem": NIP-41 stateless key invalidation, NIP-46 Nostr Connect, NIP-07 browser signers, hardware signing devices, musig/FROST threshold keys with semi-trusted servers, dedicated mobile signers. More interesting than the list are his stated premises for why he doesn't worry much: Nostr keys are not as valuable a target as Bitcoin keys; identity, unlike money, can be recovered "slowly and painfully" after total loss; and for most people losing keys and starting fresh "isn't a big deal" — people delete social accounts and lose phone numbers all the time and just tell their friends. He sketches social recovery as an example: friends publish events attesting to Alice's new key, and Carol's client trust-weights Bob's attestation. His favorite property of NIP-41-style and social-recovery schemes: they need no support in ordinary clients at all — they can live in "standalone single-purpose microapps" users visit occasionally, which then update follow lists automatically.

"Even when you lose everything, identity can be recovered -- slowly and painfully, but still --, unlike money" — https://fiatjaf.com/72f5d1e4.html

The case against edits

A structured polemic (in objection-and-reply format) against editable kind:1 notes. Edits are fine in specialized kinds, but kind:1 "is the public square of Nostr," where decentralization is paramount. His core argument is about the barrier to entry: if edits spread, every client — including the tiny embedded ones he hopes for, "Nostr notes being referenced from and injected in unrelated webpages, unrelated apps, hardware devices, comment sections" — must implement complicated edit-fetching on top of already-complex outbox querying. To "but likes and zaps are optional extras too" he answers: those don't change the content of the post; edits do, so a non-implementing client shows false information — meaning edits, once widespread, are mandatory, and clients without them die, which is exactly what a centralizing force looks like. He punctures the "every platform has edits" myth (Bluesky, Instagram comments, TikTok, YouTube videos, email, and 15 years of Twitter say otherwise) and turns "the market will decide" around: "The market has decided for Facebook, Instagram, Twitter and TikTok. If we were to follow what the market had decided we wouldn't be here." Alternatives he offers: the annotations spec (graceful fallback to replies), human-readable diffs as annotations, and the old email trick of a delayed-send window for fixing typos.

"Direct edits are a centralizing force on Nostr, a slippery slope that should not be accepted." — https://fiatjaf.com/ad84e3b3.html

"No, they are not optional. If edits become widespread they necessarily become mandatory. Any client that doesn't implement edits will be displaying false information to its users and their experience will be completely broken." — https://fiatjaf.com/ad84e3b3.html

kind:1 maximalism and the future of other stuff and Nostr decentralization

His architecture for how "other stuff" (long-form, podcasts, calendar events, livestreams) should relate to microblogging. Three options for discoverability: (a) publish everything as kind:1 ("obviously very bad"); (b) different kinds, but microblogging clients fetch and render them all (via NIP-31/NIP-89); (c) different kinds, announced by plain kind:1 notes that link out to dedicated clients. He confesses he long favored (b) — as do, tacitly, the clients rendering ever more kinds in feeds — but has switched to (c): superapp-ification "pushes clients to become bigger and bigger, raising the barrier to entry into the kind:1 realm," and he personally hated seeing his long-form articles dumped into feeds as if they were tweets. Solution (c) maximizes publisher flexibility, keeps a crisp boundary for simple clients, and preserves the reason for microapps to exist (if every client renders recipes perfectly, dedicated recipe apps die). The conclusion inverts the essay's title: kind:1 is not just another kind — it is "the central plaza of Nostr," and its neutrality demands dozens of small, diverse clients even if every niche vertical has only two.

"It's ok if Nostr ends up having just 2 recipe-sharing clients, but it must have dozens of microblogging clients" — https://fiatjaf.com/cd8ce2b7.html

The end of NIPs

A late, radical proposal from the person who created the NIP process: "We stop using the NIPs repository completely." Replace it with a minimal, uncontentious registry that only reserves kind numbers with one-line descriptions, and let anyone interested in a kind (or kind-group) write their own guide to how it works — multiple competing explanations rather than one official text. His bill of grievances: most NIPs are just event-schema tables not worth the increasingly bureaucratic numbering process; NIP texts are too short to teach real usage — "specially the part about choosing what relays to use at each step," whose neglect produced developers "writing 'clients' that only connected to a hardcoded set of relays"; GitHub is getting worse and Nostr should dogfood its own discussion tools; the NIP number confers an unearned "officialness aura" while good uncodified practices have none; and dead NIPs should be able to actually die instead of polluting every newcomer's reading list. The closing reflection: he copied the numbered-documents style from his own LNURL spec work, but that described one main flow with optional features — Nostr is not one flow and "clearly isn't like a single-implementation programming-language-spec with a dictator and his committee," so the format was a category error.

"We stop using the NIPs repository completely." — https://fiatjaf.com/311b999e.html

"...many developers ... just focus[ed] on translating between event schemas as described in the NIP text and UI elements and disregarded the hard subtleties of relay choice, writing 'clients' that only connected to a hardcoded set of relays" — https://fiatjaf.com/311b999e.html

P2Panda and the super-peer curse

Prompted by someone suggesting p2panda could replace Nostr, this becomes his general taxonomy of the "super-peer" failure mode. p2panda's Aquadoggo node is not a relay but an "app server": a trusted machine that abstracts away all protocol work and hands "massaged, sorted, filtered, ordered data" to a dumb client — meaning underlings behind it "will be controlled, censored, mislead and tricked." He identifies the same design as fundamental to Bluesky, Farcaster, and Pubky, creeping into RSS (aggregators) and IRC (bouncers), and experimented with inside Nostr itself — ZBD Social (his own project), Primal, Ditto, Satlantis, Bostr — while noting SSB and Mastodon were never corrupted by it. If this architecture were destined to dominate Nostr, he "would immediately declare Nostr a failed experiment." What super-peers buy is the reliability pure p2p can't deliver, plus filtering and discovery; Nostr's answer must be to lean harder on its own weirdness: whitelisted community relays, rule-enforcing relays, search relays, AI-feed relays, spam-filtering relays, curation relays — power in the relay layer, never interposed between a follower and the followed.

"The basic Nostr feature of being able to follow anyone you want and not giving a super-peer the power to break that link between follower and followed, i.e. the outbox model, is still the most basic function of relays." — https://fiatjaf.com/c45ce07b.html

Why IPFS cannot work, again

(Not Nostr-tagged, but the sharpest single statement of the anti-DHT conviction baked into Nostr's "no P2P techniques, therefore it works" — his site has a whole "How IPFS is broken" series at https://fiatjaf.com/d5031e5b.html.) The argument is a reduction: storing all data on all computers can't work (too much data — "if you think this can work then you're a BSV enthusiast"); sharding by pubkey still can't work (still too much data, incentives misaligned); and IPFS's actual move — storing only pointers to where data lives — just relocates the problem. Now every available file must be continuously advertised, flooding the network, and every retrieval floods it again with peer-to-peer request forwarding; push more storage onto peers and nodes become unbearable, push less and flooding grows and retrieval slows. There are no incentives anywhere in the loop. The punchline is the one he redeploys against every "decentralized" storage scheme.

"But if everybody just saves everything to Infura or Cloudflare then it works, magic decentralized technology." — https://fiatjaf.com/b8e2f959.html

About Nostr, email and subscriptions

A short piece against transplanting legacy communication assumptions onto Nostr. Some services were sending Nostr DMs containing articles as a "subscription" mechanism — which he calls senseless: pulling DMs from relays is the same process (slightly more convoluted, even) as pulling public events, so the assumption that a DM "reaches" a subscriber better than the event they explicitly subscribed to is a fossil "from some fantastic past era in which emails were 100% always seen." (He opens by admitting he checks email once or twice a week himself.) The right move is Nostr-native subscription flows — following creators, curation providers, communities, and relays directly, as clients mostly already do (he cites Coracle's custom feeds). The kicker is an anecdote about an interviewer asking Farcaster's creator whether it gives creators email addresses: answering "no, but you can send them uncensorable DMs!" would be "getting everything backwards."

"Building around such broken assumptions is the wrong approach." — https://fiatjaf.com/8af0e043.html

Theme 4 — How developers should build on Nostr

How to do curation and businesses on Nostr

His playbook for entrepreneurs, opening with the temptation to avoid: a closed platform that reuses Nostr identities, siphons content from the open network, imprisons it, and runs "an amazing AI-powered algorithm" on top — especially tempting in discovery-heavy niches (recipes, long-form, used-goods markets, freelancing, game lobbies, professional directories, music, restaurants). Even if it succeeds it "enshrines you as the head of a platform": ads, a legal team, the FBI, advertisers shaping discourse. The prescription is two-step. First, write an interoperable, ideally open-source niche client with a NIP or NUD for its event kinds ("without interoperability this can't be Nostr"), letting users point it at any relay for global content. Second, put your secret sauce in a relay you run — charge, do "KYM (know your music)" validation, apply the AI sorcery there — and make it the client's default. Your relay is your website; people are free to connect or not; you compete on a level playing field and users get portable identities and social graphs that don't depend on you — which is exactly why they can trust you. Crucially, the social layer (follows, comments) must still ride the outbox model, so a musician banned from your relay keeps their followers from nos.lol. Hardcoded defaults and manually typed relay URLs are fine for now; relay-list-sharing events can smooth it later.

"You don't own the network, you're just competing against other websites on a leveled playing field, so you're not responsible for it." — https://fiatjaf.com/1f4d0118.html

How can web apps be independent protocol clients?

An honest examination of a hole in the model: Nostr assumes clients are true "user agents" — servers may be "as evil as they want as long as clients are working to serve the interests of users" — and that holds tolerably for installed native apps (updates are optional, rare, discernible, the same for everybody). But a web client is chained to a DNS name and someone else's server: jumble.social works until its owner shuts it down, is coerced into shipping malicious code, or makes an unwanted change nobody can opt out of. His preferred fix is "subjective apps": Jumble should mean "this version of Jumble I use (represented by this hash)," with the static HTML/JS/CSS hosted on Blossom and addressed by content hash; users voluntarily accept the author's new releases, or adopt a contentious fork under the same name, with these subjective naming decisions propagating through the social graph. He rates this "very good" but weird enough that it may not happen soon, so he offers the lazier cultural fix: users learning that clients are many and interchangeable, keeping secondary clients (yakihonne, coracle) in parallel so any single web client's death or betrayal is survivable.

"a web client can't ever be trusted as an installed client can. They can't be fully user agents as they'll always remain (at least a little bit) agents of their true owner, the person who has the domain name." — https://fiatjaf.com/6829ad8b.html

Redistributing Git with Nostr

The design rationale behind NIP-34/GRASP-style git-on-Nostr. He starts by conceding the lurking comment — "but Git is already distributed!" — is technically true and practically false: GitHub hosts essentially all of open source, and projects elsewhere lose discoverability and contributions because contributing anywhere else means account creation, passwords, email confirmation, and SSH setup. Moving everyone to GitLab or Codeberg misses the point ("the open-source world controlled by two shady companies instead of one"); the goal is that a self-hosted server in a wood cabin and a new hosting company both compete with GitHub on equal terms. Nostr's contributions: patches as event content (Nostr as "a quite powerful email replacement," reviving the git send-email flow with better UX than GitHub's "intense clickops mixed with terminal copypasting"); issues as threaded Nostr comments (better threading than GitHub, he notes); search via repository announcement events on public-good or curated relays, indexable by anyone without proprietary APIs; and CI as a paid-in-sats service triggered by Nostr events instead of GitHub webhooks. The essay doubles as a worked example of his generic recipe: find the network-effect chokepoint, replace its coordination layer with signed events on competing relays.

"What we want is to give every person the opportunity to host their own Git server without being ostracized." — https://fiatjaf.com/18ff5416.html

"we must remove the network-effect centralization pressure." — https://fiatjaf.com/18ff5416.html

Coverage notes