Sad part is the alternative to this at least with distributed networks is to make co-hosting content optional, but then that makes the network less resilient.

You touched on the key weak spot of the #ssb2 design so far. Basically, availability (of "seeders") is inversely proportional to storage sustainability. Which makes SSB(1) highly available. I have aggressive goals for SSB2, like being limited to 64MB of data in disk, but gotta be conscious of the cost this can have on availability, and I'd like to measure or study this tradeoff somehow quantitatively, to reach a compromise.

I've been thinking whether one thing SSB needs is more ability to ask for what's available of someone's feed and put it into a sandbox or cache, to preview what kind of (or how much) content is there before one commits it all their log.