DVMs were designed as a general-purpose compute marketplace, and while they work for feeds, the request/response model is overkill when all you need is a list of event IDs.

The problem with DVM feeds

When a client wants a feed from a DVM, it publishes a kind 5300 job request, waits for the request to propagate through relays, then waits again for the DVM to detect it, compute results, and publish a kind 6300 response. Every request exposes your pubkey and follows to the provider, and if you want fresh results, you repeat the entire flow.

Curated feeds: invert the model

The core idea: publishers maintain a replaceable event containing an ordered list of recommended content, and clients subscribe to it directly using standard Nostr filters.

{
  "kind": 30405,
  "tags": [
    ["d", "bitcoin-daily"],
    ["title", "Bitcoin Daily"],
    ["k", "1"],
    ["e", "<event-id>", "<relay-hint>"],
    ["e", "<event-id>", "<relay-hint>"]
  ]
}

The k tag indicates what kind of events the feed contains, so a microblogging client can filter out long-form article feeds without fetching everything first. The publisher updates this event whenever they want, updated as needed, and clients receive updates automatically through their existing websocket subscription, publishing nothing themselves.

Personalization

For users who want a feed tailored to their interests, the negotiation happens out of band. The user contacts the provider, agrees on terms, pays if required, and the provider creates a new feed with a unique d tag for that user. The user then subscribes to their personalized feed like any other curated feed, keeping the protocol simple while allowing arbitrary business models on top.

Comparison

	DVM Feeds	Custom Feeds NIP	NIP-32 Labels	NIP-51 Curation Sets	Curated Feeds
Purpose	On-demand compute	Feed recipes	Content tagging	User bookmarks	Live feed publishing
Latency	Request/response round trip	Depends on source	Requires relay support	Instant	Instant
Privacy	Request reveals user interests	Varies	Label queries may leak interests	Private to user	Zero metadata exposed
Complexity	Multiple event kinds, status flows, payment negotiation	Complex recipe format with set operators	Separate labeling events	Not designed for third-party feeds	One replaceable event
Live updates	Must re-request	Must re-evaluate	Must re-query labels	Manual refresh	Automatic via subscription
Use case	Personalized computation	Composable feed definitions	Distributed moderation, categorization	Personal collections	Editorial curation

Full spec below.

---

NIP-XX: Curated feeds

draft optional

This NIP defines a simple mechanism for publishing curated feeds of Nostr events. Unlike DVM-based feeds (NIP-90), curated feeds require no request/response flow. Publishers maintain replaceable events containing ordered lists of recommended content that clients subscribe to directly.

Event format

A curated feed is a parameterized replaceable event of kind 30405:

{
  "kind": 30405,
  "tags": [
    ["d", "<feed-identifier>"],
    ["title", "<human-readable name>"],
    ["description", "<what this feed contains>"],
    ["k", "<kind of events in feed>"],
    ["e", "<event-id>", "<relay-hint>"],
    ["e", "<event-id>", "<relay-hint>"],
    ["a", "<kind>:<pubkey>:<d-tag>", "<relay-hint>"]
  ],
  "content": ""
}

Tags

• d - Required. Unique identifier for this feed.
• title - Optional. Human-readable feed name.
• description - Optional. Description of the feed's purpose or algorithm.
• k - Optional. The kind of events this feed contains (e.g., "1" for notes, "30023" for articles). Clients MAY use this to filter feeds by content type.
• e - Event references. Order is significant: first tag is the top recommendation.
• a - Addressable event references (articles, etc). Order is significant.

Publishers SHOULD limit feeds to a reasonable size (e.g., 50-200 items). Clients SHOULD treat tag order as the intended display order.

Client behavior

Clients subscribe to feeds using standard filters:

{"kinds": [30405], "authors": ["<publisher-pubkey>"], "#d": ["<feed-id>"]}

When the publisher updates the feed, clients receive the new version automatically via their existing subscription. Clients MAY cache previous versions to highlight new additions.

Discovery

Content curators MAY publish a curator profile event of kind 10405 to advertise themselves and list their available feeds:

{
  "kind": 10405,
  "tags": [
    ["name", "<curator name>"],
    ["about", "<description of curation focus>"],
    ["a", "30405:<pubkey>:<feed-d-tag>", "<relay-hint>"],
    ["a", "30405:<pubkey>:<feed-d-tag>", "<relay-hint>"]
  ],
  "content": ""
}

Clients can discover curators by querying for kind 10405 events and display their available feeds to users.

Custom feeds

Publishers MAY offer personalized feeds on request. The negotiation, payment, and delivery mechanism is out of scope for this NIP. A typical flow:

1. User requests a custom feed from a publisher (out of band)
2. Publisher creates a new feed with a unique d tag for that user
3. Publisher communicates the d tag to the user
4. User subscribes to their personalized feed

Why not DVMs?

NIP-90 DVMs require clients to publish job requests and wait for responses. The round-trip creates latency and exposes user interests to providers. Curated feeds invert the model: publishers proactively maintain feed state, clients subscribe.