I just received my invite code today and took a quick look around the app. Like Mastodon I do not prefer microblogging platforms. And that’s all I know about Bluesky.
In bluesky I think those effects mostly lie on the side of which client people use.
The protocol is extensible and you can add new post types and formatting options by creating a new schema/lexicon, but these would only be readable by other clients which supports it. I hope they’ll be able to add some general “category template” lexicons so a graceful degradation scheme can be implemented to support compatibility without hindering 3rd party development.
To protect against a PDS server going bad the client could assist with automated account migration (the new PDS doesn’t need to understand the lexicon of your posts to be able to migrate them intact), even if the old PDS won’t cooperate (the client could maintain backups for you to make migration quick). But if you don’t control your keys separately then a bad client update could make your account unrecoverable, similarly to a mastodon server going bad.
@Natanael you seem to continue to focus on PDSes even though I explicitly said it doesn’t matter which PDS you’re on, the secondary centralization (and thus control) happens in the “reach” layer, outside of what PDSes do in ATproto.
In other words, changing a PDS gives you way, way less agency in BS, compared to agency you get with changing an instance on Fedi.
BS is designed to make that secondary centralization happen, and to be where the real power in the system is.
I don’t see how that’s a negative, all the choices attached to Mastodon hosts are distributed to multiple services in bluesky which optionally could be served by the same entity, but doesn’t need to be. A PDS can run its own moderation services, or subscribe to another, or leave it to clients. A PDS can run their own feeds, or leave it to others. Clients can choose to use the services provided by the PDS, or to use others.
I don’t see where the centralizing forces are (other than economy of scale stuff). Having the most users doesn’t mean much when it’s trivial to substitute your service, regardless if that’s a moderation labeler service, a collection of feeds, or whatever else. It’s really just the most popular client apps which have disproportionate power, but that’s true for every protocol.
Edit: I also want to point out that the PDS by default controls a bunch of stuff for the client via the appview service, that’s the service which the client talks to and it assembles your home feed and assemble post views (where it control sorting, etc) and it apply blocks and mutes and applies the PDS’s own moderation, and it forwards moderation labels on posts (like NSFW tags) to the client.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !technology@beehaw.org
A nice place to discuss rumors, happenings, innovations, and challenges in the technology sphere. We also welcome discussions on the intersections of technology and society. If it’s technological news or discussion of technology, it probably belongs here.
Remember the overriding ethos on Beehaw: Be(e) Nice. Each user you encounter here is a person, and should be treated with kindness (even if they’re wrong, or use a Linux distro you don’t like). Personal attacks will not be tolerated.
In bluesky I think those effects mostly lie on the side of which client people use.
The protocol is extensible and you can add new post types and formatting options by creating a new schema/lexicon, but these would only be readable by other clients which supports it. I hope they’ll be able to add some general “category template” lexicons so a graceful degradation scheme can be implemented to support compatibility without hindering 3rd party development.
To protect against a PDS server going bad the client could assist with automated account migration (the new PDS doesn’t need to understand the lexicon of your posts to be able to migrate them intact), even if the old PDS won’t cooperate (the client could maintain backups for you to make migration quick). But if you don’t control your keys separately then a bad client update could make your account unrecoverable, similarly to a mastodon server going bad.
@Natanael you seem to continue to focus on PDSes even though I explicitly said it doesn’t matter which PDS you’re on, the secondary centralization (and thus control) happens in the “reach” layer, outside of what PDSes do in ATproto.
In other words, changing a PDS gives you way, way less agency in BS, compared to agency you get with changing an instance on Fedi.
BS is designed to make that secondary centralization happen, and to be where the real power in the system is.
I don’t see how that’s a negative, all the choices attached to Mastodon hosts are distributed to multiple services in bluesky which optionally could be served by the same entity, but doesn’t need to be. A PDS can run its own moderation services, or subscribe to another, or leave it to clients. A PDS can run their own feeds, or leave it to others. Clients can choose to use the services provided by the PDS, or to use others.
I don’t see where the centralizing forces are (other than economy of scale stuff). Having the most users doesn’t mean much when it’s trivial to substitute your service, regardless if that’s a moderation labeler service, a collection of feeds, or whatever else. It’s really just the most popular client apps which have disproportionate power, but that’s true for every protocol.
Edit: I also want to point out that the PDS by default controls a bunch of stuff for the client via the appview service, that’s the service which the client talks to and it assembles your home feed and assemble post views (where it control sorting, etc) and it apply blocks and mutes and applies the PDS’s own moderation, and it forwards moderation labels on posts (like NSFW tags) to the client.