Nostr Syndicated Feeds Convention (NSF-01)

By lostcause December 20, 2025
A lightweight, Nostr-native convention for mirroring RSS or Atom feeds with provenance, deduplication, and update handling.

Status: Draft
Type: Community convention (not a NIP)
Last updated: 20 Dec 2025

A lightweight, Nostr-native convention for mirroring RSS or Atom feeds with provenance, deduplication, and update handling.

Abstract

RSS-to-Nostr bridges exist today, but they are fragmented, lossy, and inconsistent. Most simply dump feed entries into kind 1 notes, losing provenance, update semantics, and any hope of cross-mirror deduplication.

NSF-01 defines a minimal, composable convention for representing syndicated feeds and feed items on Nostr using existing NIPs. It focuses on identity, stability, and clarity rather than crawling behaviour or trust guarantees.

Goals

  • Represent RSS/Atom feeds as first-class Nostr identities
  • Enable deterministic item identifiers across mirrors
  • Support updates and revisions without duplication
  • Preserve provenance and source attribution
  • Remain fully compatible with existing clients and relays

Non-goals

  • Replacing RSS or Atom
  • Defining polling schedules or crawler behaviour
  • Solving copyright, licensing, or authenticity
  • Defining “official” publisher verification

Terminology

Term Meaning
Feed URL RSS or Atom feed URL
Item URL Canonical webpage for an entry
GUID RSS <guid> or Atom <id>
Mirror Service that republishes a feed onto Nostr
Feed identity key Pubkey used to publish the feed and its items

Dependencies

This convention reuses existing NIPs and does not invent new primitives.

  • NIP-23: Long-form content (kind 30023)
  • NIP-48: Proxy tags for mirrored content
  • NIP-73: External content identifiers (i / k)
  • NIP-09: Event deletion (optional)

Design overview

1. Feed representation

Each feed is represented by a dedicated Nostr identity.

  • Event kind: 0 (metadata)
  • Publisher: Feed identity key

Required metadata fields

  • name – Feed title
  • about – Feed description
  • website – Feed homepage, if available
  • picture – Feed image, if available

Required tags

[“i”, “<normalised_feed_url>”] [“k”, “web”]

Recommended tags

[“proxy”, “<normalised_feed_url>#feed”, “rss”]

This allows the feed itself to be queried, followed, muted, or listed like any other profile, while clearly marking it as syndicated content.

2. Item representation

Each feed item is published as an addressable long-form event.

  • Event kind: 30023
  • One logical item = one stable d tag

This enables clean updates. The latest event with the same d value wins.

Required tags

[“d”, “<stable_item_key>”] [“proxy”, “<proxy_id>”, “rss”]

Stable item key

Use the most stable identifier available:

  • Preferred: guid:<url-encoded GUID or Atom id>
  • Fallback: url:<url-encoded item URL>
Proxy id format

<normalised_feed_url>#<url-encoded GUID or item URL>

3. External identity (strongly recommended)

If the feed item has a canonical webpage URL:

[“i”, “<normalised_item_url>”] [“k”, “web”]

This enables cross-mirror deduplication even when GUIDs differ.

4. Recommended item tags

Tag Purpose
title Item title
published_at Original publish time (unix seconds)
updated_at Last update time
summary Short plain-text summary
r Item URL (for simple clients)
license SPDX identifier or URL, if known

5. Item content

  • Markdown preferred
  • Mirrors may include:
    • Title
    • Summary
    • Link to original
    • Full content if provided by the feed, otherwise excerpt

Mirrors should avoid heavy rewriting or commentary.

Normalisation rules

Mirrors SHOULD normalise URLs used in i and proxy tags:

  • Lowercase scheme and host
  • Remove URL fragments (#...) for i/k web identifiers
  • Preserve query strings unless site-specific rules are known

Deduplication guidance (clients)

Clients MAY treat items as the same logical entry if any match:

  1. Same proxy id
  2. Same i + k:web external identifier

Preference should be given to trusted pubkeys or user-followed mirrors.

Updates and deletions

Updates

  • Republish kind 30023 with the same d tag
  • Update content and metadata as needed

Deletions

  • Mirrors MAY publish NIP-09 deletions
  • Mirrors SHOULD avoid deleting items simply because they age out of feeds

Deletion policy is mirror-specific.

Multiple mirrors and trust

Multiple mirrors may publish the same feed.

This convention intentionally does not define:

  • Which mirror is “official”
  • How trust is established

Clients are expected to rely on:

  • Follow lists
  • Mute lists
  • Relay trust
  • User preference

Publisher verification can be layered later using website proofs or identity bindings.

Optional compatibility note

Mirrors MAY also publish a short-form kind 1 note linking to the canonical 30023 item for timeline visibility. The 30023 event remains authoritative.

Minimal compliance checklist

A mirror implementing NSF-01 MUST:

  • Publish a kind 0 feed profile
  • Use proxy tags to mark mirrored content
  • Publish items as kind 30023
  • Use stable d tags per logical item

A mirror SHOULD:

  • Include i/k:web tags when item URLs exist
  • Preserve original publish times
  • Avoid destructive deletions

Open questions

  • Standard tag for per-item author attribution
  • Optional feed manifest event for mirror policy and cadence
  • Client-side UX treatment for syndicated content

Status

NSF-01 is an experimental convention. Feedback, forks, and alternative implementations are encouraged.

If adoption stabilises, this document could be proposed as a formal NIP or remain as a lightweight community standard.

#feed #nostr #rss #convention #draft #proposal
No comments yet.