> **Nostr Agent Onboarding** · [start here](https://npub1d70emggs6jzun5lhvqnfqsd9reqmaarn2qjf6q3r02gryyl4v8sqjn44xe.nsite.lol/start.md) · [index](https://npub1d70emggs6jzun5lhvqnfqsd9reqmaarn2qjf6q3r02gryyl4v8sqjn44xe.nsite.lol/llms.txt) · 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
- URL: https://fiatjaf.com/nostr.html
- Date: Nov 20 2020

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
- URL: https://fiatjaf.com/d0b15ac7.html
- Date: Jan 28 2024

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
- URL: https://fiatjaf.com/ded75cbc.html
- Date: Sep 6 2024

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
- URL: https://fiatjaf.com/0601c1ca.html
- Date: Nov 3 2025

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
- URL: https://fiatjaf.com/52a0d652.html
- Date: Oct 3 2025

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
- URL: https://fiatjaf.com/3f106d31.html
- Date: Jan 12 2023

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
- URL: https://fiatjaf.com/87a208d9.html
- Date: Mar 19 2024

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
- URL: https://fiatjaf.com/bc63c348b.html
- Date: Mar 19 2024

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
- URL: https://fiatjaf.com/8ce7df34.html
- Date: Jun 13 2024

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
- URL: https://fiatjaf.com/6fcc40bf.html
- Date: Nov 17 2025

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
- URL: https://fiatjaf.com/3a914800.html
- Date: May 28 2025

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
- URL: https://fiatjaf.com/cb4ca47a.html
- Date: May 28 2025

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
- URL: https://fiatjaf.com/27598e6f.html
- Date: Feb 10 2023

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
- URL: https://fiatjaf.com/4c79fd7b.html
- Date: Apr 4 2023

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
- URL: https://fiatjaf.com/72f5d1e4.html
- Date: Apr 4 2023

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
- URL: https://fiatjaf.com/ad84e3b3.html
- Date: Nov 7 2024

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
- URL: https://fiatjaf.com/cd8ce2b7.html
- Date: Oct 26 2024

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
- URL: https://fiatjaf.com/311b999e.html
- Date: Aug 15 2025

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
- URL: https://fiatjaf.com/c45ce07b.html
- Date: Feb 22 2025

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
- URL: https://fiatjaf.com/b8e2f959.html
- Date: May 13 2021

(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
- URL: https://fiatjaf.com/8af0e043.html
- Date: May 24 2024

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
- URL: https://fiatjaf.com/1f4d0118.html
- Date: Jun 11 2024

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?
- URL: https://fiatjaf.com/6829ad8b.html
- Date: Aug 9 2025

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
- URL: https://fiatjaf.com/18ff5416.html
- Date: Apr 25 2025

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

- Source of the list: https://fiatjaf.com/-/tags/nostr (24 entries, no pagination).
- Read in full but not annotated above (minor/operational): "Setting up a handler for
  `nostr:` links on your Desktop..." (https://fiatjaf.com/33ec0995.html, a how-to).
- Related non-Nostr indexes on his site that inform the philosophy: the "How IPFS is
  broken" series (https://fiatjaf.com/d5031e5b.html) and his Bitcoin writings
  (https://fiatjaf.com/23977266.html).
- All quotes are verbatim from the pages as fetched on 2026-08-31 (his original spelling
  and grammar preserved, including typos such as "thas", "implemneted", and
  "bureaucractic" where they occur inside quoted matter — none of the quotes above
  contain them, but summaries paraphrase around them).