But then it’s not federated. It’s all on one giant monolith of a server. Perhaps the traffic is shared between machines, but that’s not the same thing as federated.
Below is how account portability work between servers, it is easy to migrate between servers.
Account portability
We assume that a Personal Data Server may fail at any time, either by going offline in its entirety, or by ceasing service for specific users. The goal of the AT Protocol is to ensure that a user can migrate their account to a new PDS without the server’s involvement.
User data is stored in signed data repositories and verified by DIDs. Signed data repositories are like Git repos but for database records, and DIDs are essentially registries of user certificates, similar in some ways to the TLS certificate system. They are expected to be secure, reliable, and independent of the user’s PDS.
Each DID document publishes two public keys: a signing key and a recovery key.
Signing key: Asserts changes to the DID Document and to the user’s data repository.
Recovery key: Asserts changes to the DID Document; may override the signing key within a 72-hour window.
The signing key is entrusted to the PDS so that it can manage the user’s data, but the recovery key is saved by the user, e.g. as a paper key. This makes it possible for the user to update their account to a new PDS without the original host’s help.
A backup of the user’s data will be persistently synced to their client as a backup (contingent on the disk space available). Should a PDS disappear without notice, the user should be able to migrate to a new provider by updating their DID Document and uploading the backup
The way sign up currently is, probably not. It would still default to bsky.social and your average person isn’t going to think about it.
But then it’s not federated. It’s all on one giant monolith of a server. Perhaps the traffic is shared between machines, but that’s not the same thing as federated.
Below is how account portability work between servers, it is easy to migrate between servers.
Account portability
We assume that a Personal Data Server may fail at any time, either by going offline in its entirety, or by ceasing service for specific users. The goal of the AT Protocol is to ensure that a user can migrate their account to a new PDS without the server’s involvement.
User data is stored in signed data repositories and verified by DIDs. Signed data repositories are like Git repos but for database records, and DIDs are essentially registries of user certificates, similar in some ways to the TLS certificate system. They are expected to be secure, reliable, and independent of the user’s PDS.
Each DID document publishes two public keys: a signing key and a recovery key.
Signing key: Asserts changes to the DID Document and to the user’s data repository.
Recovery key: Asserts changes to the DID Document; may override the signing key within a 72-hour window.
The signing key is entrusted to the PDS so that it can manage the user’s data, but the recovery key is saved by the user, e.g. as a paper key. This makes it possible for the user to update their account to a new PDS without the original host’s help.
A backup of the user’s data will be persistently synced to their client as a backup (contingent on the disk space available). Should a PDS disappear without notice, the user should be able to migrate to a new provider by updating their DID Document and uploading the backup
What other server is there?