haven't looked into any of them but I wonder how many are mostly redundant and how many are more like sidecar records with strictly complementary information. In the latter case I'd name them differently, but maybe that's just me.

Sounds like you might have experience with companies that offer an abstraction layer on top of this. I'm not familiar with those but wouldn't be surprised if they charge a hefty premium for it. Depending on your goals it might be worth diving into the underlying tech so you can skip those layers.

my reply was to a different post discussing general advice, not the OP.

A common and cheap setup is to host a static website on object storage and serve it through a CDN. This static site would then call the serverless functions through an API gateway.

Hosting server-side code comes down to 3 options: virtual machines, containers, or serverless functions. Serverless tends to be really cheap with vendors where you pay only for runtime and memory; particularly those with a generous free tier.

That seems unavoidable. Without access to the apps, all the activity you can see is whatever generates events that flow through the relays so it sounds like you're already doing what can reasonably be expected.

The repo record itself doesn’t have versioning so you would only see the latest version or in the case of a deleted record nothing at all, iirc.
The relay that puts out the firehose has a retention period of a couple of days, so you could replay recent events but not from the beginning of time.

there's no need to subpoena anything. The government (or anyone else) can subscribe to the event log service aka firehose and get all the events in the network for archival. You should assume they already do.

Familiarity for Substack users seems to me like higher priority than anything else. I wouldn't waste time on a whole new design at the beginning: the time where you have the least amount of information you'll ever have. There's a reason bsky looks just like Twitter.

The short answer is that Bluesky is not in charge of your following list. You are.
You're the only one who can edit the list of accounts you follow and nobody else has permissions to edit it for you; not Bluesky, not the people you follow, only you.

We already have a few bookmark services on atproto but if you're going to build one please use the community lexicon for it so it will be compatible with other good citizens of the ecosystem: community.lexicon.bookmarks.bookmark

What's cardy? Can't find anything about it online.

exactly. The longer we go without private records, the more tempted apps will be to stop seeing the PDS as canonical storage.

At first I thought you were being sarcastic, describing how Bluesky's underlying protocol works, more or less. But it's pretty insightful that you saw it this way without knowing that. Nice!

Personal Data Server, the component that stores your account and content like your posts and images. A separate component is the apps that interact with it like Bluesky and many others.