Essentially, yes. But these servers are simple to spin up and inexpensive to run if you’re not storing a metric ton of data.
But if 1000’s of relays are all indexed by more than one indexer you get mighty powerful.
All I can think of is Napster without that pesky centralization.
Okay, so with RSS distribution, I store my RSS file on an http server, any client can fetch that file over http, then the client can parse the data to create a guid. That's podcasting at it's core.
Point of failure, if my server goes down, my feed is unfetchable. Not necessarily a single point of failure, because an Index, like the Podcast Index could also have my feed info in their database, and an app could fall back to fetching the data from the Index.
So, nostr is websockets instead of http. I could have a relay that sends my RSS file to the client, the client just needs to connect over websocket. I could update my feed by sending the new file to my relay, but also to several other relays. My server could serve websocket and http, so my relay could also be my traditional http server and I have two ways of getting the RSS file to an app. If my relay goes down, the podcast client is also listening to other relays, so could look for my RSS file on a different relay that may have stored it when I updated my feed. Now my feed is stored on several relays, and so I can have more points of failure and still have my feed available.
Am I understanding things correctly?
