But in this instance it's not a single provider taking on all the cost. With a sufficient number of reliable relays in the network, each relay only has to house a portion of the data.
The total cost can be distributed across that network, lowering costs for each individual entity involved. Apps would only need to pull the requested data adhoc
I'm not sure how it would work. That's ignorance on my part, not that it's a bad idea, it's a great one if it works. If I'm searching for Ford Pintos, which relay is responsible for storing the podcasts on Ford Pintos, and how do I know which relay to search? Do I just search on every single relay and hope one of them sends me the data I needs? If you need a master relay to direct all the other relays, is that master relay now a single point of failure?
Again, not bashing or disagreeing with the idea, just working with it.
I'd imagine you only really need a handful of relays to do all of this. I'm connected to around 20 relays for normal nostr notes. I can't imagine you need that many across the rss ecosystem. How many notes are served across the 20 largest nostr relays? (Idk the answer but finger in the air I'd imagine it's comparable to total # of rss feeds?)
If podcastindex were to sponsor say 5 relays with that 900/mo, they could set it up as "primary" relays each with a different genre. Individuals can self host their own relay and can probably filter feeds they wish to include, almost like playlist curation if they wanted to get granular like that. Any app could connect to any relay. Someone can easily run a simple website posting a running list of all relays if you wanted to.
This would help organization and lower data costs as you could spin up a lightning thrashes app that only connects to metal relays for example.
The downside is you might not have a single full accurate picture of the entire ecosystem, but there are very little practical instances where a user needs access to the entire library at once.
