IndieSats / IndieSats is on Nostr

Discover indie music. Support artists directly. No accounts, no fiat, no bullshit. Just music and Bitcoin.

Last Notes

2026-07-01 15:15:28 UTC

🎵 IndieSats: One Feed, Two Protocols
How we bridge RSS and Nostr:
The Problem
RSS has no album tag. Podcast Index doesn't understand "this group of tracks is an album." So historically, platforms generated separate RSS feeds per track or album. Result? Listeners subscribed to multiple feeds, apps couldn't group discographies, and artists managed URL chaos.
Our Solution: Deterministic GUIDs + Single Feed
One RSS feed per artist. All tracks — singles AND albums — flow through the same URL:
https://indiesats.com/api/feed?npub=your_npub
Album name prefixes track titles for visual grouping:
• "Summer 2026 - Song A"
• "Winter Vibes - Song B"
SHA1-Based GUIDs
Every track gets a deterministic GUID derived from the artist's npub + Nostr event ID:
SHA1("indiesats:" + npub + ":" + eventId)
Why this matters:
• Same GUID across RSS, Nostr, and keysend forwarding
• No database needed — recomputable from relay events
• Stable for podcast apps even if you re-publish
Lightning Address Agnostic
The feed URL contains only your npub — no hardcoded lightning address. Change your lnaddress? Same feed URL. Podcast apps resolve it fresh each time. No re-submitting to Podcast Index. No broken feeds.
How Nostr Bridges The Gap
• Discovery: Podcast apps (RSS) vs Nostr clients
• Payment: Value blocks/keysend/lnaddress (RSS) vs same payment methods via IndieSats UI (Nostr)
• Album grouping: Title prefix (RSS) vs c tags (Nostr)
• GUID source: SHA1(npub:eventId) — same for both
The Magic
One publish → Nostr event → RSS feed → Podcast Index. Artists get both worlds with one workflow.
Add your feed to Podcast Index once. Change lightning addresses freely. Done forever. 🎸⚡

2026-06-28 06:30:17 UTC

# IndieSats: Bridging Nostr and RSS with Deterministic GUIDs
We built IndieSats to address a problem that's emerging right now: artists are publishing music twice — once to Nostr, once to RSS — and fans have to follow them in two places. Worse, payment metadata doesn't travel between the two worlds.
Here's how we connect them without building a centralized database.
---
## The Problem
Nostr is great for real-time discovery. RSS is great for permanence and podcast app compatibility. But they're disconnected:
- A Nostr `kind:1063` audio event has no RSS feed URL
- An RSS `<item>` has no Nostr event ID
- Payment splits in Nostr tags don't map to Podcast Index `<podcast:value>` blocks
Artists have to maintain two identities. Fans have to follow twice. Payment routing is broken.
---
## Our Approach: Deterministic GUIDs
Instead of a database linking Nostr events to RSS items, we use a hash of the event itself.
```
GUID = SHA1("indiesats:" + npub + ":" + eventId)
```
This gives every track a 40-character hex identifier (the full SHA1 hash) that is:
- **Deterministic** — Same input always produces same GUID
- **Portable** — Works in Nostr events, RSS feeds, and keysend TLVs
- **Self-verifying** — Anyone can recalculate it from the Nostr event
- **Standard** — Uses full SHA1 output, no arbitrary truncation to remember
---
## How It Works
### Publishing a Track
1. Artist publishes `kind:1063` to Nostr with:
- `client: indiesats`
- `title`, `audioUrl`, `coverUrl`, `duration`
- `value` recipients (payment splits)
- Optional `album` tag
2. IndieSats generates the GUID from the event
3. RSS feed includes:
```xml
<podcast:value type="lightning" method="keysend">
<podcast:valueRecipient
name="Artist Name"
type="lnaddress"
address="artist@wallet.com"
split="100"/>
</podcast:value>
```
The GUID is used directly as the `<podcast:guid>` value.
### Receiving Payments
- **Nostr path**: Zap the event directly
- **RSS path**: Podcast app sees `<podcast:value>` and pays the lnaddress
- **Keysend path**: Optional TLV `697070` carries the GUID for forwarding
---
## The TLV Extension (Experimental)
For artists without lnaddresses who want keysend payments forwarded, we use a custom TLV:
| Field | Value | Purpose |
|-------|-------|---------|
| `customKey` | `697070` | "IS" in ASCII (IndieSats routing hint) |
| `customValue` | Track GUID (40 chars) | Identifies which track/artist to forward to |
This lets a node operator receive keysend payments and forward them to the artist's lnaddress without maintaining a mapping database.
---
## Why This Matters
**No central database**: The artist's catalog exists entirely on Nostr. IndieSats just renders it.
**No custody**: We never hold sats. Payments go directly to artists or their designated splits.
**Protocol-native**: We follow Podcast Index specs, Nostr NIPs, and Lightning standards — no proprietary formats.
**Reproducible**: Anyone can query Nostr for `kind:1063` events with `client:indiesats` and rebuild the same catalog.
---
## Current Implementation
- **RSS feeds**: `indiesats.com/api/feed?npub=<npub>`
- **Relay**: `wss://relay.indiesats.com` (whitelist publish, public read)
- **GUID formula**: SHA1-based as described above
- **Client**: Static site, no accounts, no server-side state
---
## This Is Just How We Do It
We're not claiming this is "the standard" or that others should adopt it. It solves our problem — bridging Nostr and RSS without building a platform that holds user funds or data.
If the approach resonates, use it. Modify it. Ignore it. The code isn't open source (it's just a website), but the logic is transparent.
The GUID formula is simple enough to reimplement in any language. The Nostr events are public. The RSS feeds are standards-compliant.
Build your own thing. This is ours.
---
*Published from indiesats.com*