Wow this looks great!

I think Nostr is great for discovery. The only method we have for RSS right now is a centralized database called the Podcast Index. We could use Nostr relays to decentralize that index and provide a way to share music and podcasts with friends and others.

I don't think Nostr is suited for hosting content. RSS is a simple text file that you can host on any webserver along with your MP3s. Webservers are very good at serving small static files like RSS at scale and can do 10k requests/sec out of the box. Compare that to Nostr, which can take multiple seconds to find a single piece of content spread across multiple relays.

The problem with RSS is the user interface. Many people want a simple user interface for it and don't want to learn how it actually works. We do have https://musicsideproject.com and https://sovereignfeeds.com that let you fill out a form to generate an RSS file. You still need a place to put that file and some people don't want to learn how to upload files to webservers either.

I think there's a good opportunity to combine the strengths of each technology and build something great. You could build a Nostr app that uses Nostr relays for podcast/music discovery, uses RSS to build podcast/music feeds, and uses Blossom to host the RSS feed and MP3s on a webserver for you.

We had that one magical night and then went our separate ways. It sucks.

We did build some cool apps to hopefully bridge the gap:

@Derek Ross built Podstr and Zaptrax to host and play RSS feeds with Nostr.

@Sir Libre built a killer V4V music app https://v4vmusic.app that has all the features you'd want in a music app including Nostr logins, community ratings, spam filtering, playlists, live streams, publisher tags, podroll, and more.

@ChadF and 33 others built http://ITDV.podtards.com to highlight the excellent musical talents of The Doerfels and also built his own music app https://stablekraft.app/

@Gigi built https://castr.me that automatically publishes media in your npub as an RSS feed.

I would invite anyone who wants to help to check out some of the vibe coding tools that are now available, like Shakespeare, Cursor, Claude, Codex, and Gemini. Many of the apps I referenced were coded by people who have never coded before. It's never been easier to build something and be the change you want to see in the (Nostr/RSS) world.

<promo>
The RSS crowd is having another live concert on January 9th at 7pm to celebrate the release of So Big's new album: As If.

The concert is going to have a lot of surprises based on your zaps and boosts so tune in! It will be streaming on all of your favorite podcast/music 2.0 apps as well as on Nostr/Tunestr.
</promo>

They're just standard Lightning nodes that use Keysend rather than Lightning Address/LNURL/Invoices to receive payments. Most of them (other than Fountain) are self-hosted and self-custodied rather than being hosted by a custodial wallet.

Both Keysend and LNURL are ways to get around Lighting's requirement that a sender needs to ask the recipient to generate an invoice before they can pay them. There's no way to send a "spontaneous payment" in standard Lightning.

Keysend works by sending the payment with an empty invoice. The recipient's node just receives the sats and ignores the fact that there's no invoice attached. The sender uses the node's public key to send the recipient sats via the Lightning network.

LNURL works by putting a publicly-accessible webserver in front of the recipient's node who's only job is to generate invoices for people who ask for them. The sender uses the recipient's Lightning Address to look up the webserver, sends a request to the LNURL callback, and gets an invoice back. They then can pay that invoice on the Lightning network.

V4V nodes chose keysend because it's simpler and requires no additional lookups or servers in the middle of the payment process. You just send a payment from your node to the recipient's node through the Lightning network and that's it.

Wallet providers, including most of the ones the Nostr folks use, chose LNURL and ignored keysend entirely, which is why many here are unfamiliar with it.

The Lightning network already uses other nodes to route payments. Doesn't BOLT12 just extend this concept to also route messages?

Well at least until the Alby Nostr relay goes down. You did switch that in the AH config, didn't you?

That's the logical alternative to the LNURL payment flow:

Instead of: Payer -> HTTP/LNURLp -> Recipient
Do: Payer -> Nostr Relay (Hopefully not Cloudflared) -> Recipient

Of course if we adopted keysend or BOLT12, the payment flow would be Payer -> Recipient without any middlemen.

It looks like you can fetch the offer code from NIP-01 or NIP-05 https://github.com/shocknet/CLINK/blob/main/specs/clink-offers.md#integration-with-nostr .

Unfortunately, the most popular Lightning implementation (LND) still doesn't support BOLT12. Every major implementation except them supports it.

I would love to kick LNURL to the curb and go full BOLT12, but it can't happen until they get with the program.