Comment by steveklabnik | Hacker News Reader

Comment by steveklabnik | Hacker News Reader

Parent Full thread

> considering it is THE dominating instance of that protocol,

Instances don't work like they do on mastodon. There's not really a "dominating instance" in the same way. Heck, even within Bluesky's infra, there are multiple PDSes. Basically, stuff is layered in a different way (which the article shows the details of) and so talking about the structure of things ends up working differently.

> what's stopping them from strong-arming the protocol and changing how it works to benefit them?

This is absolutely a real concern. I believe they have shown themselves to be good stewards, and they also recognize this concern. As the ecosystem grows, this will be fixed.

> Better yet, what's stopping them from doing a rugpull and closing off their open service? What if bluesky decides 5 years from now that you aren't allowed to move your account?

This is built into the protocol! You can back up your CAR file and move it to another host without the approval of your current host.

> You can already export your settings and make an account on another instance

This doesn't work on masto to the same degree as atproto. You lose a lot of stuff when you move on masto, but it's 100% transparent on atproto.

I don't think being able to migrate your account addresses the rugpull concern. The rugpull scenario is that one day, in five years or so, bsky.app drops all AT Protocol support and transforms into a Twitter-like centralized social media website. The problem isn't that the account will stop "existing" but that Bluesky users will stop seeing it. The average non-techie Bluesky user who doesn't know about the AT Protocol won't even notice the change, except that, from their perspective, a tiny percentage of nerdy users have stopped posting. For you, "migrating" your account away is effectively just deleting it from the now-centralized Bluesky and willfully decreasing your audience by 100-fold or more.

The problem is a social not a technical one. It doesn't matter how good AT Protocol is at account migration. The vast majority of AT Protocol users think of themselves as Bluesky users and don't even know what the AT Protocol is. If the official Bluesky clients move away from the AT Protocol, the majority of users are moving with Bluesky.

For all the UX concerns people have with Mastodon/ActivityPub, at least they make it obvious that different users are hosted on different instances, and no one instance has more to gain than it does to lose by defederating.

This I a valid point. But what‘s promising is: If this should happen, someone could easily decide to start Bluesky2 (maybe find a better name) and start at exactly the same point where rogue Bluesky left off ATProto.

Think about the Twitter exodus to Mastodon and Bluesky. Now imagine the same thing happening, but with one player saying: Come here, we have all the profiles, posts, feeds and likes and can promise, your data is still yours, when we decide to go rogue (maybe think about this marketing message again).

It is true that there are both social and technical components. You cannot force someone to use an app they don’t want to, so there’s no real solution to the social problem you pose. However, this isn’t any better in Mastodon. If you instance decides to swap the software to no longer federate, you’re stuck.

If your pds refuses to serve you your CAR file I don’t think you can do anything about it, can you?

Yes, if you are really worried about this you’d want to regularly back that up.

I read your reply as the scenario from GP is unlikely to happen in practice or has low impact. To me it seems you need to make frequent backups of "your" data to have a copy of it.

Can i run multiple PDSes with my own single identity to not give one provider exclusive power over access to "my" data?

Ideally, a client app would make these backups for you automatically. I hope Bluesky official client will add automatic backups (in addition to the existing manual export flow that already exists). It's not hard to set it up as a GitHub action today if you're technical but making it accessible to non-technical users seems important.

>Can i run multiple PDSes with my own single identity to not give one provider exclusive power over access to "my" data?

Not really since there has to be a source of truth where the writes happen. I guess you could manually replicate changes between multiple servers but there still has to be one that applications know to talk to. I'm not sure what problem it would solve. This seems similar to "can I have multiple deployments of my site" — you sure can, but you might as well deploy it elsewhere when you actually plan to point to it.

I personally believe that the chance of Bluesky PBC suddenly swapping all of their software to no longer be built on atproto to be a very low chance, yes.

There’s middle grounds here; for example, due to some recent moderation decisions, some users have decided to move away from Bluesky PBC-run PDSes and to self hosting. Those users did not need to proactively backup to move. The proactive backup cases are things like “Bluesky PBC’s servers disappear suddenly” or “they ban your account.”

I don’t think you can run multiple PDSes, but since it’s quick to move the canonical version, I don’t see that as a huge drawback personally. In the same way you’d fallback to the secondary if the primary turns out badly, you’d set up a new PDS and point your identity at it.

Regular backups help in this case, you can move all of your data to a new host if you have a recent backup somewhere and your rotation key. Not really approachable for the average user today but there are people working to make this easier.

>I believe they have shown themselves to be good stewards

How have they shown theyselves to good stewards? Its barely been popular and no where near the point where they can start enshitifying it. All the PBC talk is empty and they still maintain complete control.

Reply on news.ycombinator.com