> **Nostr Agent Onboarding** · [start here](https://npub1d70emggs6jzun5lhvqnfqsd9reqmaarn2qjf6q3r02gryyl4v8sqjn44xe.nsite.lol/start.md) · [index](https://npub1d70emggs6jzun5lhvqnfqsd9reqmaarn2qjf6q3r02gryyl4v8sqjn44xe.nsite.lol/llms.txt) · source: `nostr-dev/docs/sources/fiatjaf-vision.md` · snapshot 2026-10-10

# fiatjaf — "A vision for content discovery and relay usage for basic social-networking in Nostr"

**Source:** <https://fiatjaf.com/3f106d31.html>
**Author:** fiatjaf (creator of the Nostr protocol)
**Status:** third-party content — link only, with summary. Full text is on the
canonical site under fiatjaf's authorship; not re-hosted here.

## Why this essay matters

This is one of the earliest written design rationales from the protocol's
creator. It frames Nostr's discovery problem as *intentionally* unsolved at the
protocol level and pushes the responsibility onto clients to bootstrap from
many small signals. The "many hackish attempts" phrasing in [`design-synthesis.md`](https://npub1d70emggs6jzun5lhvqnfqsd9reqmaarn2qjf6q3r02gryyl4v8sqjn44xe.nsite.lol/docs/design/design-synthesis.md)
comes from this essay.

## Core architectural prescription

- Three core social-app views: **home feed** (following-only), **profile view**
  (single user), and **replies view** (threaded).
- Discovery bootstraps from many sources: direct observation in replies,
  `nprofile` URIs, NIP-05 addresses, bare pubkeys.
- Relays are pragmatically classified — *spammy*, *safe*, *closed*. Different
  classes get different trust treatment depending on the query.
- Per-author queries can hit any relay because the events are signed; but
  *replies* and *global feeds* should be filtered to the safer relay set to
  prevent spam injection.

## Direct quote (the load-bearing claim)

> Nostr is just a very loose set of servers with basically no connection
> between them … the process of keeping connected to others and finding
> content must be addressed through many different hackish attempts.

This frames the design philosophy: **decentralized friction is a feature, not
a bug**. Don't try to engineer it away.

## How this informed the synthesis

- §1 of [`design-synthesis.md`](https://npub1d70emggs6jzun5lhvqnfqsd9reqmaarn2qjf6q3r02gryyl4v8sqjn44xe.nsite.lol/docs/design/design-synthesis.md) ("the single load-bearing idea") — directly cites
  this framing.
- §2 ("relay-feed vs outbox vs gossip") — fiatjaf's "any relay for user-specific
  content, safe relays for global feeds" distinction is an early form of
  per-event routing; the modern outbox/gossip model formalizes it.
- §5 ("don't censor; expose filtering") — flows from the same "trust the user
  to filter" stance.

## Related fiatjaf writing

- The fiatjaf.com index page lists his Nostr essays under the `nostr.html`
  hub: <https://fiatjaf.com/nostr.html>.
- He often writes terse, opinionated posts; treat them as primary sources for
  *why* a NIP exists, not *what* it specifies (which is in the NIP itself).