I'm going to offer some pushback, and not because I necessarily disagree with you, more as a thought exercise.

RSS is simply a data structure. It's saved in a file that's easily fetched, but that data structure could just as easily be saved in the contents of a note. So I don't know that we need to get rid of RSS so much as think about other ways for it to be stored and delivered. I think there are ways an RSS feed can be stored on multiple servers, signed so it's confirmed to be the same data stored in each relay, and the feed can have new tags in it to inform the app of the preferred relay, as well as back up relays to pull the feed from if the preferred relay is ever offline. Using key signing, un updated feed can be sent to multiple servers that are able to verify the feed is indeed being updated by the owner, then replacing the existing feed with the new feed. The underlying data structure that has worked for 20 years and on which the entire podcasting industry is built upon has proven itself. If we can figure out ways of storing that data on multiple relays, most of the podcasting apps will be able to continue to function as they always have, and the only change they need to their code is how the feed is fetched.

And as it stands, every relay you're using right now needs a domain and DNS. Your notes are either on your own relay or one your renting from someone else. I'm not sure how npub fixes that we need servers (relays), those servers need to be findable, and the notes attached to your npub have to be stored on those servers so others can see your notes, even when you're offline. The core ideas of nostr offers redundancy and identity, both of which can be adopted into the RSS feed.

Reply to this note

Please Login to reply.

Discussion

I am glad to have a reasonable conversation.

I agree that the file format is not a problem. It successfully conveys the information we need. And indeed, it could be copied to multiple places, signed, etc.

My point is that the same job can be done in a much better way if it were #NOSTRNative. One aspect is that RSS is a polling process where the file is downloaded at a regular interval and scanned for new contents. This paradigm is inverted by nostr, where an event can be published when there is new content, eliminating the wasteful traffic spent polling.

You are right that relays still depend on domain names and servers. I just think that NOSTR will offer a better pathway to substrate independence and uncensorability.

The pathway to a better version of what RSS is trying to accomplish will be found in using NOSTR directly, rather than reimplmenting some kind of identity and auth scheme for RSS.

My guess is that most of the blogs and podcasts I follow will one day originate as NOSTR notes and get syndicated into RSS feeds by services offering such. I am working on just such a service myself. I don't want someone like you to have to choose. I want the content to be addressable in whatever format you prefer.

"The core ideas of nostr offers redundancy and identity, both of which can be adopted into the RSS feed. "

In this we are in close agreement. And thank you for your reasoned response.

Polling in RSS is no longer necessary due to podping which works fantastically.

https://podcasting20.substack.com/p/podping

I appreciate you pointing this out. It does seem to solve the polling problem.

But it seems to me that NOSTR also solves this problem, but does so in a much more elegant way, with a turnaround time of updates to distribution potentially being measured in milliseconds. Not only that, but the content IS the message.

Plus, I like the idea that the NOSTR protocol carries all the things that I want timely updates on. I would like to have a feed that can handle articles, podcast episodes, comments on all of the above, and all the menagerie of note kinds that I have yet to explore, using a single protocol, so I don't need to mix and match betweeen them. Obviously, if there is a superior protocol for a particular kind of content, I wouldn't hobble utility to have uniformity, but it would be nice to minimize the number of integrations, accounts, and book keeping required to both publish and consume such content.

Have you personally used the Podping stack to publish stuff? I'm curious to hear your experience with it.

I use podping everytime I publish a new episode of Lightning Thrashes and when I do live shows every Sat to signal it's statuses (pending, live, ended) to podcast apps like Fountain, Curiocaster, PodcastGuru, etc.

I also use it whenever I publish or update an RSS feed. (I've got about 30ish so far)

I don't have much of a dog in the hunt re: nostr vs RSS. I tend to prefer the way the current RSS ecosystem works, but I have no problem with other solutions being developed and tried.

My biggest concern is openness, scalability and interoperability. So far RSS has been rock solid for over 20 years.

I invite you to learn more about podcasting 2.0 and the amazing innovations that have been made over the past several years.

podcastindex.org

https://github.com/Podcastindex-org/podcast-namespace