4 ms·
If a server admin ragequits and pulls the plug on the server without notice you are going to have trouble getting your data out or migrating.
by Sunspark 3y ago
If a server admin ragequits and pulls the plug on the server without notice you are going to have trouble getting your data out or migrating.
- shagie 3y agoThis is an ongoing issue with one of the Lemmy instances. https://lemmy.world/post/1232070 https://lemmy.world/post/1232070 And a Mastodon instance (mastodon.lol) from a few months ago: https://news.ycombinator.com/item?id=34748195 https://news.ycombinator.com/item?id=34748195 (though there was some warning)
- crtasm 3y ago> https://lemmy.world/post/1232070 https://lemmy.world/post/1232070 The image they're looking for is on Wayback machine, if that's helpful: https://web.archive.org/web/20230614091556/https://vlemmy.net/pictrs/image/928b2f95-a37c-4e94-bd70-bc014c8655d4.jpeg https://web.archive.org/web/20230614091556/https://vlemmy.ne...
- vidarh 3y agoAbility to recover from that is one of the few things of value in the AT protocol (Bluesky) and something I expect will get pilfered in one way or another eventually.
- Kye 3y agoA lot of people only seem to see "portability" as some magic feature without understanding it. So they're going to be surprised when they get suspended from bsky.social or they decide to sunset it and everything is lost because they didn't associate their identity with a domain they control. Everything people found complicated about Mastodon is there in Bluesky in some form.
- vidarh 3y agoAT separates the handle (the domain) from the DID, which is the identifier for the repository. You can change your handle, including from bsky.social subdomains to one you own. The bigger issue currently is that there is a problem where the did:plc method used for all the currently issued did's is stupidly centralised. Though if Bluesky were to mess that up badly enough there in theory nothing really stopping other parties from deciding to crawl the audit log and take over processing of DID's if clients agree. They do certainly need to fix that DID bullshit, though, or they have a chokehold that is worse than the bsky.social domain. It's the rough outlines of a good idea but a really dumb mechanism full of the idiotic NIH issues that you can find throughout. I'm certainly no fan of the protocol, and their "why not ActivityPub" part just demonstrates that they don't really understand either ActivityPub nor the space. E.g you don't need a stable ID and they made a stupid choice in assuming so. The recovery keys allowing the user to update the DID could equally be used to sign claims about a change of id and push them to the followers/following. As such the recovery key part is good - it's all the Fediverse would need to adopt to be able to let users do unilateral migrations (coupled with regular backups/exports; frankly having a standard API for the clients to pull that would be good).
- Kye 3y agoHow are the keys currently managed? That's something I'm not clear on. Any user-managed key is a lost cause outside use cases where it's obvious to all parties why it's important and everyone has the patience to manage it. Secret management always seems to end up centralized, adding potentially adversarial parties to the chain of trust. I at least know I never had to set up any kind of recovery key for my Bluesky account, so I assume this is handled on bsky.social even though my handle is @ my domain.
- vidarh 3y agoAs far as I can tell their intent (and I don't know if this is followed through) is for the clients to hold both keys and copies of your other data, without really making much of a point of it to users. I think that's a good idea as a worst case fallback, but a bad idea to rely on, but in either case it ought to be made clearer to users.