having given this 45 seconds of thought: various app.bsky appviews selling themselves like usenet providers and differentiating themselves by retention lengths, moderation policies, etc clients would set their primary appview but could also add secondary appviews to fetch missing content as needed

could have a lightweight appview as your primary (self-hosted? community hosted?) and buy blocks of 1/3/5k requests from providers that maintain a complete archive of the network feels like atproto with its content-address/self-authenticating properties is a good fit for this model

I'm sure if I gave this 60 seconds of thought I would think of some reason it wouldn't work, so that's why I stopped when I did more fun that way

I would venture this setup is... too complicated for the average user too many pieces for my own taste

Reminds me of the onboarding process for ActivityPub, where your first task is to decide what server to use. That was too much for the average user and even myself. Not having that friction is why Bluesky blew past Mastodon user counts

true, but this would be more for the power user set than for casuals Bluesky PBC deploying social-app to bsky.app pointing to api.bsky.app out of the box would still exist, for sure

this would be for people who want independence from Bluesky PBC (or are just hackers in spirit) and want to run a modest appview in the $20–$50/mo range that can cover 90% daily usage let a big player maintain a full network archive, and let me pay to grab old stuff not in my lightweight appview

The way I've thought about this is an API service people can pay-go for network backfills, annotations, and enrichments