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, follows, and preferences to the provider, and if you want fresh results, you repeat the entire flow.
## Curated Feeds: Invert the Model
The core idea is simple: instead of clients requesting feeds on demand, publishers maintain a replaceable event containing an ordered list of recommended content, and clients subscribe to it directly using standard Nostr filters.
```json
{
"kind": 30405,
"tags": [
["d", "bitcoin-daily"],
["title", "Bitcoin Daily"],
["k", "1"],
["e", "", ""],
["e", "", ""]
]
}
```
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 - hourly, daily, or in response to breaking content - and clients receive updates automatically through their existing websocket subscription without publishing anything.
## 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 | Nothing revealed |
| 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 can subscribe to directly.
## Event Format
A curated feed is a parameterized replaceable event of kind `30405`:
```json
{
"kind": 30405,
"tags": [
["d", ""],
["title", ""],
["description", ""],
["k", ""],
["e", "", ""],
["e", "", ""],
["a", "::", ""]
],
"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:
```json
{"kinds": [30405], "authors": [""], "#d": [""]}
```
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:
```json
{
"kind": 10405,
"tags": [
["name", ""],
["about", ""],
["a", "30405::", ""],
["a", "30405::", ""]
],
"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. This creates latency, exposes user interests to providers, and adds payment negotiation complexity. Curated feeds invert the model: publishers proactively maintain feed state, clients simply subscribe.
