> **Nostr Agent Onboarding** · [start here](https://npub1d70emggs6jzun5lhvqnfqsd9reqmaarn2qjf6q3r02gryyl4v8sqjn44xe.nsite.lol/start.md) · [index](https://npub1d70emggs6jzun5lhvqnfqsd9reqmaarn2qjf6q3r02gryyl4v8sqjn44xe.nsite.lol/llms.txt) · source: `Nostr-exp/voices/fiatjaf/on-nostr.md` · snapshot 2026-10-10 # fiatjaf on Nostr: what the creator of the protocol publishes on his own protocol Research date: 2026-08-31. Method: read-only `nak req` against fiatjaf's own advertised write relays plus fallbacks. No events were published or signed. - **Pubkey (hex):** `3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d` - **npub:** `npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z` - Sources queried: `wss://pyramid.fiatjaf.com` (his own relay), `wss://purplepag.es`, `wss://relay.damus.io`, `wss://nos.lol`. (`wss://relay.nostr.band` timed out from this machine, so no NIP-50 keyword search was possible; notes were sampled instead.) - Data volume: **~250 unique kind:30023 articles** (deduped from 268 raw events by d-tag) and **425 kind:1 notes** (span 2026-04-16 → 2026-08-30). --- ## 1. Profile (kind 0) Latest kind:0 (event `31ae13f6…`, updated 2026-08-07). Content is minimal, in character: ```json { "name": "fiatjaf", "about": "~", "picture": "https://fiatjaf.com/static/favicon.jpg", "nip05": "_@fiatjaf.com", "lud16": "@npub.cash", "website": "https://stuff.fiatjaf.com/", "banner": "https://cdn.satellite.earth/8f10244a….jpg" } ``` The `about` field is literally a single tilde. Identity is anchored by NIP-05 at the root of `fiatjaf.com`. ## 2. Relay list (kind 10002 / NIP-65) Latest relay-list event `2cd4d1d5…` (2026-06-28). Note the deliberate read/write split — he practices the inbox/outbox model he preaches, including a dedicated spam-filtered `/inbox` endpoint on his own relay: | Relay | Mode | |---|---| | `wss://pyramid.fiatjaf.com/` | write | | `wss://basspistol.org/` | write | | `wss://spatia-arcana.com/` | write | | `wss://theforest.nostr1.com/` | write | | `wss://relay.44billion.net/` | write | | `wss://pyramid.fiatjaf.com/inbox` | read | | `wss://inbox.relays.land/` | read | | `wss://spatia-arcana.com/inbox` | read | | `wss://basspistol.org/inbox` | read | His canonical home relay is `pyramid.fiatjaf.com` (his own "Pyramid" relay software, WoT-whitelisted). His NIP-05 file also announces it. ## 3. Long-form articles (kind 30023) ~250 unique articles exist under this pubkey. The bulk (~225) was **imported in one batch on 2024-01-14** and is his pre-Nostr blog archive (fiatjaf.com): Bitcoin/Lightning engineering (Drivechain, Eltoo, HTLCs, bolt12), an entire "IPFS problems" series ("How IPFS is broken", Pinning, Dynamic links, Shitcoinery…), critiques of DIDs/ION, Austrian economics, and personal essays in Portuguese. Below are the **Nostr-specific articles**, newest first, each with d-tag, date, summary, and quotes. ### nostr - Notes and Other Stuff Transmitted by Relays (`d:nostr`, 2025-12-19) The founding document, maintained as a living replaceable event. Defines the protocol in one line and explains why the alternatives fail: Twitter (ads, bans, addiction techniques), Mastodon (identity welded to domain names, migration "doesn't work in an adversarial environment"), SSB (great but over-complicated, chain-of-updates bloat), and run-your-own-server schemes ("they require everybody to run their own server"). The core architecture: clients talk to many dumb relays, relays never talk to each other, signatures are verified client-side. Censorship-resistance comes from free entry on the relay side ("there will always be some Russian server willing to take your money in exchange for serving your posts"). Spam is a relay-policy problem, not a protocol problem. Data storage scales because content only needs to sit where its audience reads. > "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." > "A relay is very simple and dumb. It does nothing besides accepting posts from some people and forwarding to others. Relays don't have to be trusted." ### Nostr: a quick introduction, attempt #3 (`d:0601c1ca`, 2025-12-02) Third attempt at a minimal explanation: Nostr is only two descriptions — a signed message format ("event") and a server interface ("relay"). His target is the misconception that Nostr is "a set of free servers that are readable and writable by everyone", which leads to bad questions ("who will run these relays?"). Whether a relay is free, stores your event, deletes it, or restricts reads is entirely the relay operator's business. > "Nostr is not any specific set of relays, and relays are not meant to be public or free." > "Don't be one of these people." ### The only solution to Nostr spam (`d:6fcc40bf`, 2025-11-17) His definitive spam essay. Main feeds have no spam problem (you follow whom you follow). Inbox/notification spam is "trivial to fix": clients must read mentions only from the user's NIP-65 "read" relays, and users must pick read-relays that actually filter (WoT-whitelisting like his Pyramid `/inbox`, nip05-requiring, PoW or paid relays as fallback). The hard case is *other people's threads*: you fetch replies from *their* read relays, so if their thread is full of spam "that is their fault… for not picking 'read' relays correctly" — a deliberate incentive structure. Client-side-only filtering (mutes, local WoT) can only be last-mile: content must be downloaded before it can be filtered, so purely local filtering means "downloading gigabytes of spam all day everyday", and it creates a tragedy of the commons. > "Enforcing restrictions once per write is much more effective and efficient than trying to enforce them on every read." *(companion note, see themes)* > "Eventually people should stop going to someone else's house if the house is always dirty." ### How can web apps be independent protocol clients? (`d:6829ad8b`, 2025-11-15) Native clients can be true "user agents"; web clients cannot, because they hang off a DNS name owned by someone else — "they'll always remain (at least a little bit) agents of their true owner". Proposes "subjective apps": a client is a content hash, hosted on Blossom, updated voluntarily, with contentious forks propagating socially through follow graphs. Fallback ("lazier") solution: users simply learn that clients are many and interchangeable and keep secondary clients in parallel. > "A fundamental assumption of Nostr is that servers are free to be as evil as they want as long as clients are working to serve the interests of users." ### Visual depiction of the architecture of 3 protocols (`d:52a0d652`, 2025-10-04) Short illustrated comparison: Fediverse = clients talk to one server, servers federate; Nostr = "clients can talk to multiple servers, which gives us a very chaotic ecosystem of signed messages"; ATProto = social-server functions split into a pipeline of specialized big servers. ### The end of NIPs (`d:311b999e`, 2025-08-15) Proposes abandoning the NIPs repository: keep only a minimal registry that reserves kind numbers with one-line descriptions, and let anyone write competing guides for how kinds work. Diagnosis: most NIPs are just event-schema tables; NIP texts are too short on the part that matters ("specially the part about choosing what relays to use at each step (which caused many developers to just… write 'clients' that only connected to a hardcoded set of relays)"); NIP numbers give bad ideas an "officialness aura" while good single-implementer practices lack one; GitHub should be replaced by dogfooded Nostr discussion. (Follow-through visible in his 2026 notes: he now maintains `nostr-protocol.github.io/registry-of-kinds/`.) > "This flexibler approach allows bad or abandoned NIPs to effectively die such that they don't continue to pollute the minds of every new programmer." ### Nostr is not decentralized nor censorship-resistant (`d:87a208d9`, 2025-08-10) A self-critical experiment: he published identical notes simultaneously, one to three big relays, one only to `pyramid.fiatjaf.com` (which is plainly announced in his NIP-05 and NIP-65). The big-relay copy got vastly more engagement — proof that clients are not actually following users at their announced relays, so a person banned from the 3 biggest relays would instantly lose ~90% of reach. Concedes Peter Todd is right about Nostr *today*, but wrong that it is *inherently* centralized: it's a client-implementation failure, fixable without protocol changes. > "If Nostr was really censorship-resistant that shouldn't have happened at all." ### Nostr is pro-censorship (`d:3a914800`, 2025-05-28) Provocative framing of the same doctrine: the "global pool of content" model is what kills open platforms, because someone must host everything and no global agreement on acceptable content can ever exist. On Nostr there is no global pool by definition; every relay is free to impose any policy, and readers are responsible for choosing where to read. Relay-level "censorship" (moderation) is thus a feature that makes the network work. > "No relay has any obligations to please all the peoples of the Earth and is free to impose any limits or policies it wants." > "Of course all of that 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, but that should have gone without saying." ### Keys are meaningless (`d:cb4ca47a`, 2025-05-28) Against key-worship ("not your keys, not your notes", "self-sovereign identity"). Keys are just numbers; what matters is the ability to act — i.e. relays. > "Having a key is meaningless if you cannot publish messages to where the people you're trying to reach can read them." > "Is a person locked in a cage 'free'? If you use the key-worshipper logic then yes." ### Redistributing Git with Nostr (`d:18ff5416`, 2025-04-25) The NIP-34/GRASP manifesto. Git is distributed but GitHub centralizes it via the network-effect of accounts and pull-request UX. Goal: anyone can host a Git server without ostracism, hosting companies compete on a level field. Nostr is "a quite powerful email replacement", so patches fit event contents (the `git send-email` flow revived); Issues are just threaded comments (Nostr does it better than GitHub); search works via kind:30617 repo-announcement events indexable by anyone; CI can be triggered by Nostr events instead of proprietary webhooks. > "We must remove the network-effect centralization pressure." ### The fiatjaf Nostr fund (`d:fd6dc37c`, 2025-04-25) Ledger of how Jack Dorsey's Dec-2022 donation "has been misused so far": every bounty from Dec 2022 to Mar 2025, in sats, with recipients and projects. Reveals his priorities: repeated bounties specifically for **outbox/gossip-model implementation** in Snort, Coracle, Nozzle, Camelus, Gossip ("display relays, follow event hints"), relay tooling (strfry, nostr.watch), search (nos.today), and RSS-reader Nostr integrations. Notable line: "William Casarin: 7 BTC - splitting the fund". ### P2Panda and the super-peer curse (`d:c45ce07b`, 2025-02-22) Reviewing p2panda's Aquadoggo node, he identifies the recurring failure mode of "decentralized" protocols: a trusted super-peer that hands massaged, sorted, filtered data to dumb clients — the design of Bluesky, Farcaster, Pubky, RSS aggregators, IRC bouncers, and even Nostr experiments (ZBD Social — his own, Primal, Ditto, Bostr). Super-peers buy reliability/filtering/discovery that pure p2p can't deliver; Nostr's multi-relay architecture is the alternative answer, and should lean into specialized relays (communities, search, curation, spam filtering) while the outbox model preserves the follower–followed link no super-peer can break. > "If I believed the answer was 'yes' I would immediately declare Nostr a failed experiment, but I don't." ### The case against edits (`d:ad84e3b3`, 2024-11-07) Edits to kind:1 are "a centralizing force… a slippery slope". If widespread they become de-facto mandatory (non-implementing clients display false information), raising the barrier to entry for the micro-clients he wants everywhere. Counter-evidence to "everyone has edits": Bluesky, Instagram comments, TikTok, YouTube, email, 15 years of Twitter. Alternatives: annotations that degrade to replies, or send-delay ("undo"). > "If edits become widespread they necessarily become mandatory." > "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." ### kind:1 maximalism and the future of other stuff (`d:cd8ce2b7`, 2024-10-26) How should "other stuff" (articles, podcasts, livestreams) reach microblogging feeds? Rejects (a) publishing everything as kind:1 and (b) superapp clients rendering every kind (centralizing: pushes clients to be huge). Endorses (c): different kinds referenced from kind:1 announcement notes with NIP-31/NIP-89 handoff to dedicated microapps. kind:1 is special — "the public square of Nostr" — so it must stay simple enough that dozens of small clients can handle it. > "It's ok if Nostr ends up having just 2 recipe-sharing clients, but it must have dozens of microblogging clients." ### How to do curation and businesses on Nostr (`d:1f4d0118`, 2024-09-18) The business blueprint: don't build a closed platform that imprisons Nostr content behind an algorithm. Instead (1) write an open niche client, (2) run a value-adding relay — "your relay is like your 'website'" — where your magic sauce (curation, KYM, AI filtering, payments) lives. Users keep unified identity and outbox-model portability: if a musician you follow gets banned from the music relay, you still see them. > "They do not depend on you, therefore they're more likely to trust you." ### Nostr: a quick introduction, attempt #2 (`d:ded75cbc`, 2024-09-06) The political-economy framing: Nostr doesn't subscribe to "free speech" ideals; 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". Nostr as the public road between private stores. ### Why relay hints are important (`d:8ce7df34`, 2024-06-13) Against reducing relay discovery to kind:10002 alone (prompted by Coracle removing event-reference relay-hint following — "a catastrophic idea"). Seven concrete scenarios where hints are the only path: community/NIP-29 posts, conference-scoped relays, archival relays (cellar.nostr.wine) outside the outbox list, topical relays, dual personas on one key, kind-restricted relays, and the fully-banned user whose nprofile relay hints are his lifeline ("Alex Jones could still live a normal Nostr life"). ### About Nostr, email and subscriptions (`d:8af0e043`, 2024-05-24) Against "DM subscription" services: pulling DMs from relays is the same (slightly more convoluted) mechanism as pulling public events, so DMs confer no deliverability magic — that's an email-era assumption smuggled into Nostr. Build Nostr-native subscription flows (custom feeds, curation, communities, relays) instead. > "Building around such broken assumptions is the wrong approach." ### Censorship-resistant relay discovery in Nostr (`d:bc63c348b`, 2024-03-19) History and doctrine of the gossip/outbox model: original vision (relay hints + kind:2 recommendations + manual action), Gossip client as first true implementation (NIP-05 hints, kind:3 lists), then NIP-65 crystallizing it. Warns against equating "outbox model" with NIP-65 alone — nprofile/nevent hints, tag hints, NIP-05, manual action, hardcoded values and social-graph heuristics should all be mixed. > "Reliance on third-parties, hardcoded values, social graph, and specially a mix of multiple approaches, is what Nostr needs to be censorship-resistant." ### Nostr: a quick introduction, attempt #1 (`d:d0b15ac7`, 2024-01-29) The friendliest of the three intros: Nostr as "very much like the internet itself", honest about the tradeoffs — no guarantees any relay has what you want, replies may differ between users, and the nsec is "painful, but cool". > "To conclude: Nostr is like the internet (or the internet of some decades ago): a little chaotic, but very open." ### From the 2024-01-14 archive import (still Nostr-canon): - **Why I don't like NIP-26 as a solution for key management** (`d:4c79fd7b`) — delegation was fine as an optional bridge for custodial platforms (Minds); as *the* key-management scheme it becomes de-facto mandatory for every client and "breaks a lot of the simplicity of the protocol". - **Thoughts on Nostr key management** (`d:72f5d1e4`) — a menu (NIP-41, NIP-46, NIP-07, hardware, musig/frost, social recovery) plus deflationary premises: "For the vast majority of people, Nostr keys aren't a target as valuable as Bitcoin keys"; "losing keys and starting fresh isn't a big deal"; identity, unlike money, is recoverable. - **A vision for content discovery and relay usage** (`d:3f106d31`) — the ur-text of the outbox model: classify relays (spammy/safe/closed), bootstrap profile→relay mappings from hints in everything, fetch home/profile views by author from their relays (spam-immune because the filter is strict), fetch reply/global views only from safe relays. "To write Nostr applications and to use Nostr one must embrace the inherent chaos." - **Bluesky is a scam** (`d:ab1127fb`) — atproto's three claims (protocol, identity, openness) dissected: the protocol is "a description of whatever the Bluesky app and servers do"; DID Placeholder is "a normal old boring trusted server controlled by Bluesky"; the BGS chokepoint means readers control nothing. - **The problem with DIDs** (`d:98aab9a5`) — "supporting DIDs" would mean implementing a gazillion methods and blockchains; the standard must fail, degenerate to `did:key`, or centralize into shared libraries calling servers. --- ## 4. Themes from kind:1 notes Sample: 425 notes, 2026-04-16 → 2026-08-30, fetched from pyramid.fiatjaf.com, relay.damus.io, nos.lol. His notes are mostly replies: terse, combative, concrete. The recurring themes, with verbatim quotes (hex event ids): ### Theme 1 — Spam is solved at relays, on write; never client-side, on read The single most repeated position. Filtering belongs in chosen inbox/read relays; local WoT and mutes are last-mile at best, and spam in your thread is *your* relay configuration's fault. > "Let me say it clearly: The only way to fix reply spam is for people to use inbox relays that filter spam. Clients then should read replies by default only from people's advertised relays. Finally, if you see reply spam in someone else's thread it should be clear whose fault that is, so that person will be ashamed and fix it." > — `8d3c1fb6c75f4529539a33a8a4522f8c9147bbf5ac79824d401ed5b22e252fca` (2026-08-24) > "Wrong, the only scalable and decent way to prevent against spam is by picking relays that enforce limits and reading from such relays on a case-by-case basis. […] In other words: enforcing restrictions once per write is much more effective and efficient than trying to enforce them on every read." > — `87a713726637ae1f491825b3d829cf62371865bdefe4c885421c5e4ed5eba11c` (2026-07-27) > "Lots of people think that, but they are wrong. Clients are fragile and powerless against the lawlessness of the internet. Imagine your client having to download and process thousands of evil comments and mentions coming from random public keys?" > — `f29aa37daff86fff2ad0f2aeda42b41b54fd7065fd8f6f6022cc23545e0f0cab` (2026-08-15) > "The fact that people like the fake Gaza guy bot […] are still showing up basically everywhere is proof that no lesson was learned from all these years of spam, claims that 'WoT fixes this', excessive muting and that any basement kid that wanted to actually break the Nostr experience for everybody would be able to do it easily. But I still have hope the tide will turn." > — `4d528db962e8bc46a1488b8c8122297f24b594df11ed31a39e59f4f526f91691` (2026-08-25) ### Theme 2 — Relays are private property; moderation/deletion there is legitimate and good The "Nostr is pro-censorship" doctrine, applied daily: relay owners may delete, ban and whitelist freely; users moderate their own comment sections through their inbox relays; nobody is entitled to a single canonical reply section. > "Do you allow anyone to enter your house and shit on the floor? I don't get why you're so against people deleting notes from relays they control. That doesn't hurt any of the Nostr ideals." > — `c458230601b772643284c16f33929cba90b158c2fd6b461c3077141075d56593` (2026-08-24) > "Clients should double down on allowing people to moderate their own comment sections: eliminate annoying, unwanted, harassing replies by just deleting them from your own inbox relays. Maybe even ban someone from ever replying or mentioning you again." > — `e4dd276af0ff994dd784608e00d1ce68b041ab2a942d26c3f00b27e04d5713f1` (2026-08-15) > "You are free to not look at them, you are free to block them in your relay, but you can [sic — can't] stop people from writing whatever junk they want in their own relays (or whatever other relays that decide to accept them)." > — `ba3d78c19d457487c0d84128c3e44c62ecb3029c9149ad0615062a86d3da355b` (2026-07-30) Related: "What is the difference between spam and a comment you don't like?" (`9027b2f7a29d6e55…`, 2026-08-15) — the two are continuous, which is exactly why policy belongs to each relay, not the protocol. ### Theme 3 — The outbox duality; hardcoded relay lists are the cardinal client sin His model of reading, stated as a two-scenario duality; and his standing code review for new clients is checking whether they fetch users' NIP-65 lists. > "You connect to random relays and fetch only from specific authors from such relays, that's in one scenario. Then there is a different scenario in which you want to open yourself to reading stuff from strangers, in that scenario you choose relays wisely and take what they give you. That's the fundamental duality of Nostr, or something." > — `992c11260849d7756a68d18af57ffe1b2068ed9b50fe49926860af6a841df2d0` (2026-07-29) > "From a quick glance at the code you have a set of hardcoded relays that the app uses at all times and at no point you try to fetch outbox relays of users or their list of DM relays. There is another 'pool' that the app maintains with other relays. I don't know where those come from, but apparently you blast every DM to all these relays too?" > — `00a1a0a1aed223d776d9a791b9ce5fa6e2a9ab3b713fc79d5af30e1e077ca5f4` (2026-06-03, reviewing a DM client) > "People have to wake up for the fact that relays are just simple servers and clients can choose from which relays they read." > — `4a04e393485e597400ba212f7c300f7bc5318bfb8b23cf1d13703851e294e0a5` (2026-06-24) He also polices this in the tooling he uses: "why does 'req -p $ME -k 1 -k 1111' […] connect to wss://relay.primal.net if that is not in my inbox list?" (`7de7839a6eede315…`, 2026-08-28). ### Theme 4 — Relays as communities / relay feeds are the underused frontier Relays are more than pipes: they are communities, curation surfaces, and feeds. He promotes "relay feeds" as a first-class client feature (his own client work — Hallway, a Jumble fork — is built around them) and wants relays with personality. > "But don't tell people to add this relay to their list of 'read' relays. Instead they should favorite it as a relay feed, as it's the perfect use case for this and works great. This works on dozens of clients now: Grimoire, Jumble, Nostur, Yakihonne, Hallway, Cor[acle]…" > — `542a16016b932ed5…` (2026-08-20) > "Relays could have been 'just a keypair' on Nostr too, but that would be stupid, because one of the functions of relays is to solve connectivity. Because p2p doesn't really work on a global scale relays are both classic web servers […] and 'communities'." > — `5e2e8c2094cc58a8d090603204a1455376d8baebe32bab597aafc19d68f65650` (2026-05-11) > "It is not expensive to run a relay though. […] the cost is probably less than $1/mo […] I am not trying to win the argument of how easy it is to run a community or a relay, though. The entire point of Nostr is that most people don't have to run servers." > — `5a77ac1d1f07ddef856aa06b86b8be1e7e168c1a97b3ba01a93243c89528359a` (2026-05-14) > "Stacker News is like a single relay. Nostr is supposed to operate with an ecosystem of free-entry relays […] Stacker News should really transition to being an actual relay, I'm still hoping for the day that will happen." > — `48b46fc140d99166afcc319ed2a22a30cc9dd5c9cc2868e3acf59b4d465995a4` (2026-08-24) ### Theme 5 — Client minimalism; against feature bloat, event pollution and X-cloning Consistent with "The case against edits" and "kind:1 maximalism": clients should be simple, opinionated, and stop copying X while over-optioning everything. > "Why are all Nostr clients trying to copy X, and yet they have a thousand emojis to select reactions from when X only has 1? Who decided that more is always better than 1 and making the user choose is always better than simplifying things?" > — `1a9363a12a09ffd7048894f73a0b6d9f8422769ebf1b3e03f082a6c95fd1c4f5` (2026-05-13) > "Instead of polluting all the events with a 'client' tag can you guys please agree on publishing a kind:1729 event (I just made that number up) with the client name in it every day […] Also please remove the useless 'alt' tags (specially from kind:1), that experiment has failed." > — `02b07dbf442a59f07c29d0b06d510a7fcd2476e45ff2d7e5d9286abf6ba0801d` (2026-06-20) > "What are 'settings'? Relays are not 'settings'. Do Nostr apps need a 'settings' menu? Maybe a 'preferences' menu where the user can change the color […] but not 'settings'." > — `457d74404cbaca9160604aeb293ecdba8fa2654bd77fe33487eabdb639130b2e` (2026-08-21) His own client wish-list (note `30acd3f89129d1de…`, 2026-08-04, describing Hallway) starts: "No zaps or Bitcoin anywhere. A single 'like' button with no millions of emoji options" — then goes deep on relay feeds, follow sets, outbox syncing, kind:1111 comments, and NIP-43 relay membership. ### Theme 6 — Nostr is the possibility, not a community; keys are pragmatics, not religion He fights both the "Nostr = Bitcoiner community" perception and nsec-dogma; pragmatic on key storage, bullish on NIP-46 bunkers and FROST ("pomegranate"). > "The problem is that all clients present Nostr as a thing with people inside, a 'community' of sorts (a community of right-wing raw-meat-eater Bitcoiner assholes, or something like that), but Nostr isn't that, Nostr is the possibility, not the concretude." > — `c7f6b4e11ede0dd4123140d23b37cf14cc6e5aba84517432ca0a7144152a8994` (2026-08-20) > "I think it is a very reasonable flow for an introductory client to generate an nsec locally for the user and store it locally. Then, later, […] that client acts as a NIP-55 or NIP-46 local provider for that user or to setup a #pomegranate bunker." > — `e858aabdb33984f527b6b554018a36caf59c8bdf98249d98b25162eda9bd8fd8` (2026-08-20) > "Maybe the entire 'don't put nsecs in apps' is kind of a moot point. If the app developer takes basic precautions and is not insane the odds of the key being stolen are pretty small." > — `9ebbbc3c10ff003c28daa97665bd5946ef726289d5ea1cac561a5f121b517551` (2026-08-20; goes on to list the real risks: web apps, evil apps, physical access, OS takeover — "Amber/NIP-55 defends against the first two") ### Recurring sub-threads (smaller but persistent) - **NIP-17/NIP-4E DMs**: continuous field-testing of DM clients (Nospeak, Wisp, Jumble, Coop) — "I just wanted proof that NIP-17 could work reliably, and now I got it" (`81dabb9e6d7ce4d1…`); wants NIP-17 marketed as a generic open DM protocol (`c28794f6ddce5e49…`); frustrated by clients that don't use receivers' DM relays. - **NIP-29 groups**: "Much like Nostr, NIP-29 is just signed notes on servers" (`7d302dd555eda7a0…`); vs. keypair-owned groups: "In NIP-29 you only give partial authority to a server at all times, you always keep your right to migrate" (`77d6c3d3900ddafa…`). - **NIP-34/GRASP git**: still dogfooding and still frustrated — "I'm sorry to all people who send me NIP-34 patches […] I basically never look at them" and asking peers "will we ever get a 'merge' button that applies the patch and pushes the updated repository directly to our grasp servers?" (`b507bdf0b5698d00…`, 2026-08-30); laments zero Nostr mentions in HN threads asking for decentralized git (`b2529a02cb447fa3…`). - **Anti-p2p/anti-IPFS**: "On Nostr these costs are clear and obvious with the concept of relays. On IPFS that cost is distributed to people who never signed up for that job" (`5a77ac1d…`); echoes the archive's whole IPFS-problems series. - **Tooling**: promotes `nak` features (`nak profile`, `--outbox` flag: "Use --outbox so it publishes to your relays automatically", `bd564cdeaeb15cdf…`), his Pyramid relay (subscription introspection), viewsource.win (NIP-34 viewer), registry-of-kinds. ## 5. One-paragraph synthesis Across articles and notes, fiatjaf's message is remarkably coherent: **relays, not keys, are the point of Nostr**. Keys merely make relays trustless; relays are private property with free entry, and every hard problem — spam, moderation, discovery, curation, business models, even censorship-resistance itself — is meant to be solved by *choosing relays*, with write-side enforcement rather than read-side filtering. The great failure mode he attacks over and over is clients that hardcode a static relay list and treat Nostr as "a set of free public servers", which quietly re-centralizes the network (his own two-notes experiment proved it). The second failure mode is complexity creep — edits, superapps, emoji walls, tag pollution, bureaucratic NIPs — anything that raises the barrier to writing a small independent client. What he wants built: opinionated micro-clients, value-adding filtered relays (inbox relays, relay feeds, communities), outbox-model everything, and boring-but-working sub-protocols (NIP-17 DMs, NIP-29 groups, NIP-34 git) that dogfood Nostr instead of GitHub and Twitter.