StevenB on Nostr: I'm going to offer some pushback, and not because I necessarily disagree with you, ...
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.
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.