Bluesky Blog

I have my foot in both the ActivityPub and atproto camps as nothing more than an interested observer/developer, but I want to defend Bluesky a bit here.

What Bluesky are really building is atproto. If bsky.app and atproto were in a house fire and the team could only rescue one, they'd rescue atproto. Throughout this year there was such demand for a Twitter alternative that wasn't Mastodon, people jumped aboard bsky.app despite it only being a testbed/PoC for the development of atproto.

The Bluesky team reviewed the existing protocols for distributed public conversation and none of them checked all the boxes. So they built their own. Their goals were [1]:

- Account portability. Being able move your entire social graph (identity, posts, follows, likes, etc) without the previous server needing to cooperate or even be online [2].

- Scale. A "big-world" view of the entire network to enable global conversation.

- Trust. Letting users build custom feeds so you can control what your timeline looks like and being open by default.

One complaint against atproto is: why not work instead to improve ActivityPub? As someone who has worked with both protocols, I agree with the Bluesky team that it would have been too difficult to retrofit these features into ActivityPub (portability and scale, especially). Plus, a lot of Mastodon power users have philosophical disagreements with the things required for "big-world" global conversation so it's unlikely Bluesky would have received a warm…

Here's how I think about it:

* ActivityPub -> AT Protocol (https://atproto.com/)

* Mastadon -> Bluesky (https://blueskyweb.xyz/)

Right now, federation is not turned on for the Bluesky instance.

There are differences in both, however. I'm not going to speak about my impressions of the Mastadon vs Bluesky teams because frankly, Mastadon never really caught on with me, so they're probably biased.

At the protocol level, I haven't implemented ActivityPub in a decade, so I'm a bit behind developments there personally, but the mental model for AT Protocol is best analogized as git, honestly. Users have a PDS, a personal data server, that is identified by a domain, and signed. The location of the PDS does not have to match the domain, enabling you to do what you see here: a user with a domain as their handle, yet all the PDS data is stored on bluesky's servers. You can make a backup of your data at any time, and move your PDS somewhere else with ease (again, once federation is actually implemented, the path there is straightforward though). This is analogous to how you have a git repository locally, and on GitHub, and you point people at the GitHub, but say you decide you hate GitHub, and move to GitLab: you just upload your git repo there, and you're good. Same thing, except since identity is on your own domain, you don't even need to do a redirect, everything Just Works.

This analogy is also fruitful for understanding current limitations: "delete a post" is kind of like "git…

Sure, I'll try to explain the Gmail point:

- Setting up a separate domain for mail is a good idea, but access to previous emails and/or photos, docs, Drive files will be not recovered. Also non-technical person would probably skip this step.

The issue of not really being in control of your data can be solved by:

- regulating Google to let you access your data irrespectively if you are banned from their frontend or not. You can choose to export it in a standardized way to your own server, IPFS or another cloud provider. All data and metadata is exported and then parsed depending on capabilities of the receiving server.

- putting all of your data, encrypted, on IPFS or similar and creating multiple frontends for it (not unlike email clients, right? Similar idea). Then assigning your unique DID to this data, so it's part of your online belongings

- Next step would be regulating Google to allow you to use the complete user data stored on their servers with any client. Like an S3 bucket? Yes, something like that. Google can choose to charge some price for the access, that's OK.

GDPR tried to solve some of the high level issues related to user data, but it's not enough

Edit:

Google already has semi-closed APIs for some of their products, but only for partner businesses.

You're required to jump through multiple hoops to gain access (not guaranteed): https://developers.google.com/photos/partner-program/overview

On Twitter:
Jack does seem to have plans to make Twitter more…

You're gonna have to start citing something from folks joining bluesky saying that that's what they want, because inside the platform, no one is echoing that sentiment, nor does either bluesky or AT protocol websites suggest an approach where people are being blocked in that manner.

bluesky/AT protocol is pretty clear how they see moderation to work.

> Our approach to moderation is three-fold: automated filtering, manual admin actions, and community labeling

> Labels can be automatically or manually generated, and can be applied by any service or person in the network

> For example, an organization like the ACLU could create a “hate-speech” label, and services or users in the network could subscribe to their labels to flag, filter, mute, or ban content. The Bluesky reference app we’re building has custom controls that lets users hide, warn, or show content, and will add more controls over time. Through this approach, we aim to prioritize user safety while giving people more control and transparency over how moderation is done

https://blueskyweb.xyz/faq

Plus https://blueskyweb.xyz/blog/4-13-2023-moderation

If people, after reading that (or ignoring that) still end up bluesky, we can kind of assume that they agree (explicitly or implicitly) with the approach.

I'm curious to see what the adoption of BlueSky will be if ever available

https://blueskyweb.xyz/blog

I don't understand why it's so hard for everyone to just have their own blog that is twitter-sized posts and you follow the people you want or don't.

No need for censorship or filtering because you simply don't follow people you find offensive?

No need for ads because it's your own app/data.

The problem is there needs to be an edge cache of each post and storage/bandwidth isn't "free" (just cheap these days).

The app/data is either entirely on your phone or browser.

I guess the thing about twitter/facebook is people want "discovery" and to profit off it by self-promotion. So it's like those drones in the sky no-one asked for, it's someone being obnoxious for attention and profit.

Just like usenet had its first spam sooner or later.

https://matrix.org/blog/category/this-week-in-matrix#matrix-in-the-news-

> our friends at Bluesky announced their application protocol for building decentralised social media called AT. While not based on Matrix, there are some parallels, and some stuff we may be able to get inspiration from around portable identity :) https://blueskyweb.xyz/blog/10-18-2022-the-at-protocol

Sounds like some there are some parallels, and the protocol might inspire portable account identities in Matrix!

The only account migration tool I know of at the moment is proprietary [1], I'd love to see portable identity in Matrix come to life.

[1]: https://ems.element.io/tools/matrix-migration