These days I largely stay out of conversations about ActivityPub and atproto. Folks i respect like and have asserted that over time the paths that ActivityPub and atproto take will converge.

I think that arguing with one's metaphorical siblings is not fruitful and think it's more important to get folks using open social protocols in general.

Anyway, in a thread authored by my inability to follow my own advice, an conversationalist who asked to remain unnamed asserted an interesting claim:

But the really odd thing is, I had a similar experience with a (now former) long time mutual, where all I said was that I didn't think it would be possible to migrate 5-40 million active users within the Atmosphere if Bluesky's infrastructure disappeared.

This is a useful thought experiment even if it looks a bit silly on first read, since this is true for essentially all other systems. If your account host goes down, your account is boned. For instance, this is enough of an issue in the Mastodon ecosystem that the Mastodon server covenant includes a 3 month notification period before shutting off a server:

Commitment to give users at least 3 months of advance warning in case of shutting down
Sometimes services shut down, it is the cycle of life. But users must have the confidence that their account will not disappear overnight, so that they have time to export their data and find another server.

This doesn't actually solve any problems in an exigent circumstance, but i think it's good to ask people to be nice.

What's more interesting to me is question in initial assertion. What would it take to rebuild the Atmosphere if Bluesky's servers got raptured tomorrow?

I think the floor for preservation would require 3 things, two of which we can do today.

  1. 1.

    Maintaining an ongoing copy of the PLC.

  2. 2.

    Maintaining an up to date cache of the app.bsky.graph.* lexicons

  3. 3.

    A way to provide all Bluesky pds accounts w/ a way to reassert control of their DID with the PLC.

(and an optional 4th item, which is full backups of users accounts)

These top two items are things we can do today. Keeping a full backup of the PLC is feasible, and actively underway right now (see 's https://plc.wtf/ ). Keeping a cached copy of the full follow graph is certainly feasible, and tools like Tap, Ramjet, or Hydrant allow for both backfilling and maintaining up-to-date syncs of this subset of network traffic.

Maintaining spare keys

The third item is a gnarly problem. Bluesky provides the ability for users to create and store their own account keys, which would allow them to take control of their account details listed in the PLC.

However, vanishingly few users do, and awareness of this capability is low even among the tech literate userbase of bluesky. For users migrating away from Bluesky's PDS servers, PDS migration tools like PDSMoover and Northsky's provide the ability to create these keys, but it's up to the users to keep and maintain them in.

So this is the unsolved problem that makes the initial assertion true for the vast majority of Bluesky's users.

There is absolutely a space for some project that would help users automatically create and store keys in whatever computing ecosystem they participate in (google, apple, firefox, 1password, etc), and restore or otherwise reassert control over their PLC identity.

For now, users who have created their own keys have recourse if Bluesky PBC's servers disappeared entirely, however unlikely that scenario is. But full restoration does take active work. Adding rotation keys, and maintaining active backups of the data stored in your PDS account.

But one of the things that's neat with atproto in this context is that there is a path, even if that path needs to be further surveying, engineering, and paving.