I just learned that eating a really mean horseradish works great against nostalgia and self-pity.

Against any thought deeper than a pure primal survival state of mind, really.

That moment when you trying to solve something and suddenly there is hackathon for this with 25 mil sats prize ,)

That moment when you trying to solve something and suddenly there is hackathon for this with 25 mil sats prize ,)

should be good I hope. Question is... why no show of TOOL on the east coast?! Gonna need an updated TOOL Drive.

#toolband #music #musicstr

I'm a #GrapheneOS type of person, so Apple is not in the cards. I'm sure Apple Health and Google Health is great and works for many people, but it won't work for me I'm afraid. Appreciate the response though 🙏

I want to get more serious about my fitness and health and am considering getting a tracker. Never had one. Any recommendations? #asknostr

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.

Community drives this platform, for better or for worse.

nostr wins if it stops trying to be a twitter clone and starts being the invisible layer underneath apps you actually want to use. like bitchat for location-based messaging, diVine for entertainment, whitenoise for private messaging, zap.stream for streaming, shakespeare for vibe coding, etc.

it wins by unbundling into 50 different apps that all talk to each other, rather than one giant app/corp that traps you. it's all about the ecosystem.

Nostr is whatever users, not devs, want it to be.

Key rotation doesn't need to be complex. Sometimes the best solution is to admit that humans are social creatures and build systems that embrace that reality.