My point is #nostr is better RSS .. RSS should upgrade .. backward comparability is meaningful if there is a purpose ...there is none in my mind .. convince me ..why should any nostr developer support RSS ? It is a technology way beyond common man .. it is totally centralized by big players ( no matter what Adam says ) ..and it is broken ..
Discussion
We're just trying to help people add podcasting 2.0 features to apps that's it.
That means using RSS and we're not interest in reinventing it.
My point is ..it's a distraction .. nostr is a future state of podcasting 2.0.. it is like podcasting 5.0 :-) ..
Podcasting 5.0 rss feed redirects to anchor
RSS is just an XML file with metadata and links to files. There is no reason it can't be integrated with Nostr, and each improve the other.
But nostr is already a better version of that ? Why support same old XML ?
How is Nostr a better version of that? Where is the better replacement for podcasting built on Nostr without RSS?
I say let them cook, and see what they can build, rather than complaining.
Not a fan of XML either, but it works. And it's pretty darn sweet to tell my normies to "search for my release's title in their favorite app". Nearly all of them have one. The ability to use stuff like pod.link entirely on my own whim for my normies is pretty sweet. And the response among the music normies around me (some of which make decent living from music) has mostly been "I am interested, when can we have a coffe". They understand it. And they'll understand nostr, in due time. Pc2 is a great gateway to the heavier drugs!
Despite its longevity and widespread adoption, the RSS-based system suffers from several inherent architectural weaknesses that create centralization pressures and points of vulnerability. It was great before a thing like nostr existed .. but now it is a drag ..
Centralized Points of Failure: The entire system hinges on the availability of the hosting provider. Both the media files and the RSS feed itself are typically served from a single, centralized source. If that host experiences an outage or goes out of business, the podcast becomes completely inaccessible. There is no native redundancy in the protocol.
Gatekeeper Power: The dominance of Apple Podcasts and Spotify as the primary discovery platforms gives them immense power. They can de-list a podcast for any reason, effectively cutting it off from the largest potential audience. Their terms of service dictate what content is permissible, creating a powerful vector for censorship that bypasses the open nature of the underlying protocol.
Lack of Data Integrity: The
Inefficient Update Mechanism: The polling-based model is inefficient at scale. It generates significant server traffic from clients repeatedly checking for updates that are rarely present, and it introduces a delay between when an episode is published and when it appears for listeners.
Omg dude GFY and your AI slop. Muted 😂
I think podcast 2 is great, but the third point is actually valid: wait until a big fish joins the scene and watch all the fake feeds fall in with swapped podcast:value to some scammer wallet. In that sense, nostr is better equipped for the modern web.
That's said i'm a fervent promoter of having phun we the toys we have while we can.
There's some valid points there but scammers are going to scam and high jacking your rss feed seems like a lot of work.
This is where this all being open helps out since you can literally check the feed for the details.
Also if PC 2.0 is shit build your own. That's literally how podcastindex started. Apple kicked people off so we built our own.
That dude is just spamming replies but there are some valid issues there but we got bigger issues than those and some of that stuff is already fixed. Like the polling issue with podping. Send a podping and everything gets updated in like a minute but it's running of Hive so people yell "that's a shitcoin blockchain" which it might be but it uses the chain and not the token plus it's been in use for years and y'all didn't know.
Most people here are still skates to YouTube even if they claim not to be. Gotta reach the normies they say while bitching about being shadow banned or getting kicked off.
I'm loving all the RSS talk around here lately and hope it helps some people out. It's really cool and really powerful stuff.
Anyone could copy your Nostr events under a different npub with different payment info easily as well.
Different npub, yes.
nostr:nprofile1qqsda2memtapc2lykjnd8t9px4ake2stw39lg6k49xj6u3jz3pteu6qpz9mhxue69uhkummnw3ezuamfdejj7qgmwaehxw309amk7apwv3hhwmnfwdhkuargv46hqtnrvyhszythwden5te0dehhxarj9ekxzmny9u6elzz9 thanks! You made me think, podcast:npub and podcast:signature and boom: I can love xml again 😅
Something like this. Yes.
Nostr authentication is one massive upgrade im pushing for RSS players to integrate. Im certain we can utilize nostr to authenticate feeds as well
Your this very message is a "podcast" of text .. your text is stored on multiple relays and my client can discover it .. it is already 1000 x better model than sending XML to likes of Spotify and Apple ..for feeding to their own client apps ..
Add to it #blossom ..you can host signed audio content ..
All you need is ability to play mp3s in nostr client ..
Artist profile becomes a web page for the podcast ..you can see all the episodes ..
This is the ONLY way to make a dent on Apple and Spotify... If creators move to nostr for podcasting .. and biggies are choked off new content ... Then only they will even look at v4v ..
Ok.
Here are the simple specs how it will work ..but longish ..but give it a quick run through ..
# Content Hosting with Blossom
The first challenge is replacing the centralized hosting of audio files. The Nostr ecosystem's solution for this is Blossom, a protocol specifically designed for storing and retrieving large binary files (blobs).
Blossom introduces a profound architectural shift from location-addressing (the URL in an RSS
Blossom integrates tightly with Nostr for two key functions:
Authentication: To upload, manage, or delete files on a Blossom server, a user must prove their identity. They do this by signing a kind:24242 Nostr event and presenting it to the server. This leverages Nostr's native identity layer to authorize actions on a separate but integrated file storage system.
Discovery and Redundancy: To ensure resilience, a creator can upload their audio file to multiple independent Blossom servers. They then publish a kind:10063 Nostr event, which contains a list of the Blossom servers where their content can be found. A Nostr client attempting to fetch the audio file can first look up this list. If the first server on the list is offline, the client can simply try the next one, requesting the exact same file using its universal hash identifier. This provides native redundancy and censorship resistance at the media hosting layer, a direct and powerful solution to the fragility of the single-host RSS model.
## Metadata Publication and Discovery
In the Nostr model, there is no single "feed file." A podcast is simply an ongoing stream of events published by the creator's public key. The metadata traditionally found in an RSS feed is replicated and enhanced using various standardized event kinds, defined in Nostr Implementation Possibilities (NIPs):
## Podcast-Level Metadata:
A creator's kind:0 event serves as their global profile. This can contain the podcast's title, a detailed description, and a URL pointing to the cover art, directly replacing the function of the RSS
## Episode-Level Metadata:
Each new podcast episode would be announced with a new Nostr event. This event would contain tags pointing to all the necessary information. A kind:30023 ("Long-form Content") event is ideal for publishing detailed, Markdown-formatted show notes. The event's tags would include a `` tag and, crucially, a tag pointing to the audio file on Blossom, using its SHA-256 hash.
Interoperability with the Broader Ecosystem: To ensure that Nostr-based podcasts can be indexed and understood by other systems, NIP-73 provides a standard for referencing external content IDs. A podcast episode event could include a tag like ["i", "podcast:item:guid:d98d189b-dc7b-45b1-8720-d4b98690f31f"], using the globally unique identifier from a traditional RSS feed. This allows a Nostr event to be definitively linked to a specific episode, enabling cross-platform commenting and interaction.
# Direct Monetization with Zaps
The Nostr protocol includes a native V4V model called "Zaps," standardized in NIP-57. Zaps are Bitcoin micropayments sent over the Lightning Network. Unlike Podcasting 2.0's V4V, which is an add-on to a protocol with no identity, Zaps are a fundamental, protocol-native interaction.
The process is defined by two event kinds:
kind:9734: A Zap Request, which is a private event created by the sender's client to request a Lightning invoice from the recipient's wallet service.
kind:9735: The Zap itself, which is a public event created by the recipient's wallet service after the invoice is paid. This event is signed by the recipient's wallet and broadcast to the network, serving as a public receipt that includes information about the sender (their public key) and often a reference to the event they were zapping.
This makes sending a Zap a core social gesture within the Nostr ecosystem, akin to a "like" or "retweet" but with real economic value attached. The entire transaction, from the user clicking a ⚡ icon in their client to the creator receiving satoshis in their wallet, happens in seconds with negligible fees.
The Nostr User Experience
The experience of using a Nostr-based podcasting client would be fundamentally different from a traditional podcatcher:
Discovery: A listener would discover a new podcast not by browsing a centralized directory, but by seeing it mentioned or reposted by other users they follow on Nostr. Discovery is social and organic, driven by the user's "web of trust".
Subscription: To "subscribe," the listener's client simply adds the creator's public key to its list of subscription filters. The client will then receive all future events from that creator in real-time from its connected relays.
Consumption and Interaction: When the creator publishes a new episode event, it appears in the listener's feed. The client would parse the event, use the hash to fetch the audio from one of the creator's listed Blossom servers, and display the show notes. The listener could then reply directly to the episode event (creating a new kind:1 event that references it) or send a Zap, all from within the same interface.
This architecture doesn't just decentralize podcasting; it reframes it. In the RSS model, each podcast is a discrete data silo contained in its own XML file. On Nostr, all data—profiles, social notes, podcast episodes, comments, and V4V payments—exists within a single, global, and interoperable data space. A "podcast app" on Nostr is simply a client that is programmed to filter for and render podcast-related event kinds. This means a podcast episode and its associated social interactions are first-class citizens in the same data stream, enabling a level of composability and integration that is architecturally impossible with the siloed RSS model.
One of the things we are looking at is the decentralization of the index using nostr. There are other complications and problems that arise with this setup that weren't there with RSS so its not as simple as "nostr fixes this" but we're working on it. Your input helps.
Also, backwards compatibility is essential. The current vast majority of paying audience is from RSS and its not even close. If we cut off RSS then we are dead in the water. From a community standpoint both need the other right now to move forward.
Don’t say that, I only just got mine working. 😂
I am not against podcasting ..
I am against the idea of making a much better technology retrofitted to old just for the sake of it .. and just to serve big tech .. podcasting 2.0 is great feature set but the reality is none of big players (read Apple and Spotify and Google ) reading those extra tags .. and between those three - they control what around 70 percent of all podcasting traffic .. another estimate shows podcasting 2.0 is supported in less than 1 percent of all plays .. so ..
My point is - you can't win against big tech by supporting them .. you got to put forth a totally new way for AV consumption ..
Technically XML is just too bad vs JSON .. Large APIs see almost 30 percent speed bump when they switch from XML ( podcasting ) to JSON (Nostr ) based communication
Besides ..the idea that a podcaster can live on V4V is absurd .. only No Agenda show can run on donations .. sponsorship is a must .. it is not going away ...
And music is a totally different beast .. no serious artist ever ships music through podcast .. it's a pipe dream ..
No artist really makes money on the current set up…
Apple supports the transcript tag.
Stop supporting big tech but every Bitcoin and Nostr podcast prioritizes YouTube.
V4V is a lifestyle and not a monetization strategy.
Point is zaps are better than v4v :-)
I'll say medium. Some artists have. nostr:nprofile1qqsgsp3h9t6329dlfthcqu53h9jg06scymykdf2ed09gv6tmtk9j80qprfmhxue69uhhyetvv9ujuem9w3skccne9e3k7mf0wccszrnhwden5te0dehhxtnvdakz7qgcwaehxw309ahx7um5wghxvmt59emkj73wvf5h5tchp4uk7 has somewhat first mover advantage here, but she's also talented and constantly puts in the work.