Been pondering for my team to use it for our product’s timeline. I don’t particularly want our user base to be Bluesky, but it’d be good to have support for the protocol, and control over the system.
Have there been any products go embraced this? Or is it like ActivityPub where basically the whole thing is Mastodon.
ATProto is a lot of fun to work with, but of course by no means perfect. The biggest challenge right now is dealing with private data, I hope they can figure out a way to support it soon.
If you want to find other apps that are using Bluesky and ATProto we run https://blueskydirectory.com for that. Feel free to add any apps you find to it!
Here is an excerpt from the offical docs for the curious:
"Why not use ActivityPub?
ActivityPub is a federated social networking technology popularized by Mastodon.
Account portability is a major reason why we chose to build a separate protocol. We consider portability to be crucial because it protects users from sudden bans, server shutdowns, and policy disagreements. Our solution for portability requires both signed data repositories and DIDs, neither of which are easy to retrofit into ActivityPub. The migration tools for ActivityPub are comparatively limited; they require the original server to provide a redirect and cannot migrate the user's previous data.
Another major reason is scalability. ActivityPub depends heavily on delivering messages between a wide network of small-to-medium sized nodes, which can cause individual nodes to be flooded with traffic and generally struggles to provide global views of activity. The AT Protocol uses aggregating applications to merge activity from the users' hosts, reducing the overall traffic and dramatically reducing the load on individual hosts.
Other smaller differences include: a different viewpoint about how schemas should be handled, a preference for domain usernames over AP's double-@ email usernames, and the goal of having large scale search and algorithmic feeds."
> unicode scalars, which most languages index strings in
Very few do. Of moderately popular languages, Python is the only one I can think of. Well, Python strings are actually sequences of code points rather than scalars, which is a huge mistake, but provided your strings came from valid Unicode that doesn’t matter.
Languages like Rust and Swift make it fairly easy to access your string by UTF-8 or by scalar.
Languages like Java and JavaScript index by UTF-16 code unit and make anything else at least moderately painful.
> This is somewhat of an unfortunate tech debt thing as I understand, and it was made this way mostly because of JavaScript, which doesn’t work with UTF-8 natively. But this means you need to be extra careful with the indexes in most languages.
I’m confused here. You established indexing is by UTF-8 code unit, then said it’s because of JavaScript which… doesn’t do UTF-8 so well? If it were indexed by UTF-16 code unit, I’d agree, that’s bad tech debt; but that’s not the case here.
Bluesky made the decision to go all in on UTF-8 here <https://docs.bsky.app/docs/advanced-guides/post-richtext#tex...>—after all, the strings are being stored and transferred in UTF-8, and UTF-8 is increasingly the tool of choice, and UTF-16 is increasingly reviled, almost nothing new has chosen it for twenty years, and nothing major has chosen it for ten years, it’s all strictly legacy. Hugely popular legacy, sure, but legacy.
Hmm… Yeah, I guess each language does it kinda differently. At least Ruby also does it similarly like Python.
> I’m confused here. You established indexing is by UTF-8 code unit, then said it’s because of JavaScript which… doesn’t do UTF-8 so well?
It's not that UTF-8 is because of JavaScript, it's that indexing by bytes instead of UTF-8 code units is because of JavaScript. To use UTF-8 in JavaScript, you can use TextEncoder/TextDecoder, which return the string as a Uint8Array, which is indexed by bytes.
So if you have a string "Cześć, #Bluesky!" and you want to mark the "#Bluesky" part with a hashtag link facet, the index range is 9...17 (bytes), and not 7...15 (scalars).
I think that your description of ATproto relays is a conflation of the role of an AppView (or backend) in ATproto and a Nostr relay. Relays (by default) are not designed to be a permanent archive of content, and are really meant as content streams for backends to ingest and index appropriately. The storage cost is also overestimated, as people have begun to host third-party variants of the Bluesky AppView (which is partially open-source due to its dependence on internal code for some non-essential to microblogging functionality): https://whtwnd.com/futur.blue/3ls7sbvpsqc2w
The note at the end about Bluesky being able to censor, verify and ban users from the protocol is also largely incorrect, with some asterisks as is for a complex system. The Turkish accounts that were censored were hidden from the platform in Turkey via the app's labeler system, which allows for "composable moderation". You can use this system to implement geoblocking in Bluesky clients based on your IP address when you open the app, which is what they did to ban those accounts from being seen in Turkey. The application of labelers (outside of Bluesky's main moderation service which the Bluesky-hosted AppView follows) is client-side, and any client that doesn't want to respect the default geoblocking behaviour (or implement mod labels at all) can just ignore it.
The Politico columnist that was banned from Bluesky has their account taken down from the whole network because their account was hosted on a Bluesky PDS, which could be (somewhat because, again, the default AppView follows a default labeler for displaying content through the AppView's API) bypassed by moving their account to another PDS that isn't operated by Bluesky. If your account was banned from Bluesky while also being on a non-Bluesky PDS, you would still have access to the ecosystem (and a half-working version of Bluesky that is basically a shadowban due to the default client and AppView conflicting with the labeler's takedown action).
Speaking of PDSes, they also do quite a bit more than just store user data. As an user's identity is dependent on a PDS to exist as a proper account, most user actions have to be routed through it to allow applications to store their data on-protocol and to authenticate the user.
The verification system is implemented through a record type (or "Lexicon") that is stored on an account that basically confirms that the record owner has verified the target. The system is also odd in that there are two types of verified accounts, "trusted verifiers" (think Twitter's business verification system) and regular verified accounts. Trusted verifiers are chosen by the client and can verify their own set of accounts, giving them the regular checkmark. Clients that haven't implemented support for the checkmarks or allow users to choose their own trusted verifiers can basically see whatever checkmarks they want, or just disable the system altogether (which is possible in the default client).
How Bluesky uses DIDs are... complicated. ATproto supports two DID methods for accounts, did:web and did:plc. Web DIDs are used mainly for services on the network, but can also be used for regular accounts. PLC is a more complicated system, which becomes quite obvious when you find out the original acronym meaning was "placeholder". PLC is (in regards to the general protocol) not a decentralized system, as its current iteration is a DID document pastebin with authentication and version history. I do think that the method's current centralized status can be mitigated somewhat (synchronization between various directories, then having a consensus system for establishing the validity of the documents' current states), but the system could always be replaced at any point to either incorporate new features or to choose a new model for how documents are publicized.
Thank you for the detailed reply, your points make sense but many of these are, I think, too technical for the intended audience of my blog post, and do not change my overall impression of BlueSky. I will see if I manage to incorporate some of your points in a more digestible way, but reading the blog post you linked (which I didn't know, thanks) confirms my fears: 18 TB and 200$/month to run an instance which is basically serving one user is... insane? And with a lot of features not supported because closed source. I knew about did:web and did:plc and I agree that a future, better, fully decentralized implementation might possible, but at the current state I don't think BlueSky stands up to its promises compared to, e.g., Mastodon.
One nitpick about ActivityPub actor identity — the username doesn't have to be part of your ID (the URL that points to the JSON object representing your actor). It is in Mastodon, but some other software (Smithereen that I work on, and also Misskey) uses opaque identifiers derived from database row IDs. This allows for cleanly changeable usernames since you can just update your `preferredUsername` and `url` fields.
28 comments
[ 4.4 ms ] story [ 51.0 ms ] threadHave there been any products go embraced this? Or is it like ActivityPub where basically the whole thing is Mastodon.
[1] https://en.wikipedia.org/wiki/Hayes_AT_command_set
https://discord.atprotocol.dev/
Of course the spec is good too, very easy read
https://atproto.com
https://docs.bsky.app
ATDT2024561414
https://atproto.com/articles/atproto-for-distsys-engineers
Those old enough will know :)
"Why not use ActivityPub?
ActivityPub is a federated social networking technology popularized by Mastodon.
Account portability is a major reason why we chose to build a separate protocol. We consider portability to be crucial because it protects users from sudden bans, server shutdowns, and policy disagreements. Our solution for portability requires both signed data repositories and DIDs, neither of which are easy to retrofit into ActivityPub. The migration tools for ActivityPub are comparatively limited; they require the original server to provide a redirect and cannot migrate the user's previous data.
Another major reason is scalability. ActivityPub depends heavily on delivering messages between a wide network of small-to-medium sized nodes, which can cause individual nodes to be flooded with traffic and generally struggles to provide global views of activity. The AT Protocol uses aggregating applications to merge activity from the users' hosts, reducing the overall traffic and dramatically reducing the load on individual hosts.
Other smaller differences include: a different viewpoint about how schemas should be handled, a preference for domain usernames over AP's double-@ email usernames, and the goal of having large scale search and algorithmic feeds."
Very few do. Of moderately popular languages, Python is the only one I can think of. Well, Python strings are actually sequences of code points rather than scalars, which is a huge mistake, but provided your strings came from valid Unicode that doesn’t matter.
Languages like Rust and Swift make it fairly easy to access your string by UTF-8 or by scalar.
Languages like Java and JavaScript index by UTF-16 code unit and make anything else at least moderately painful.
> This is somewhat of an unfortunate tech debt thing as I understand, and it was made this way mostly because of JavaScript, which doesn’t work with UTF-8 natively. But this means you need to be extra careful with the indexes in most languages.
I’m confused here. You established indexing is by UTF-8 code unit, then said it’s because of JavaScript which… doesn’t do UTF-8 so well? If it were indexed by UTF-16 code unit, I’d agree, that’s bad tech debt; but that’s not the case here.
Bluesky made the decision to go all in on UTF-8 here <https://docs.bsky.app/docs/advanced-guides/post-richtext#tex...>—after all, the strings are being stored and transferred in UTF-8, and UTF-8 is increasingly the tool of choice, and UTF-16 is increasingly reviled, almost nothing new has chosen it for twenty years, and nothing major has chosen it for ten years, it’s all strictly legacy. Hugely popular legacy, sure, but legacy.
> I’m confused here. You established indexing is by UTF-8 code unit, then said it’s because of JavaScript which… doesn’t do UTF-8 so well?
It's not that UTF-8 is because of JavaScript, it's that indexing by bytes instead of UTF-8 code units is because of JavaScript. To use UTF-8 in JavaScript, you can use TextEncoder/TextDecoder, which return the string as a Uint8Array, which is indexed by bytes.
So if you have a string "Cześć, #Bluesky!" and you want to mark the "#Bluesky" part with a hashtag link facet, the index range is 9...17 (bytes), and not 7...15 (scalars).
Happy to correct any factual inaccuracies.
The note at the end about Bluesky being able to censor, verify and ban users from the protocol is also largely incorrect, with some asterisks as is for a complex system. The Turkish accounts that were censored were hidden from the platform in Turkey via the app's labeler system, which allows for "composable moderation". You can use this system to implement geoblocking in Bluesky clients based on your IP address when you open the app, which is what they did to ban those accounts from being seen in Turkey. The application of labelers (outside of Bluesky's main moderation service which the Bluesky-hosted AppView follows) is client-side, and any client that doesn't want to respect the default geoblocking behaviour (or implement mod labels at all) can just ignore it.
The Politico columnist that was banned from Bluesky has their account taken down from the whole network because their account was hosted on a Bluesky PDS, which could be (somewhat because, again, the default AppView follows a default labeler for displaying content through the AppView's API) bypassed by moving their account to another PDS that isn't operated by Bluesky. If your account was banned from Bluesky while also being on a non-Bluesky PDS, you would still have access to the ecosystem (and a half-working version of Bluesky that is basically a shadowban due to the default client and AppView conflicting with the labeler's takedown action).
Speaking of PDSes, they also do quite a bit more than just store user data. As an user's identity is dependent on a PDS to exist as a proper account, most user actions have to be routed through it to allow applications to store their data on-protocol and to authenticate the user.
The verification system is implemented through a record type (or "Lexicon") that is stored on an account that basically confirms that the record owner has verified the target. The system is also odd in that there are two types of verified accounts, "trusted verifiers" (think Twitter's business verification system) and regular verified accounts. Trusted verifiers are chosen by the client and can verify their own set of accounts, giving them the regular checkmark. Clients that haven't implemented support for the checkmarks or allow users to choose their own trusted verifiers can basically see whatever checkmarks they want, or just disable the system altogether (which is possible in the default client).
How Bluesky uses DIDs are... complicated. ATproto supports two DID methods for accounts, did:web and did:plc. Web DIDs are used mainly for services on the network, but can also be used for regular accounts. PLC is a more complicated system, which becomes quite obvious when you find out the original acronym meaning was "placeholder". PLC is (in regards to the general protocol) not a decentralized system, as its current iteration is a DID document pastebin with authentication and version history. I do think that the method's current centralized status can be mitigated somewhat (synchronization between various directories, then having a consensus system for establishing the validity of the documents' current states), but the system could always be replaced at any point to either incorporate new features or to choose a new model for how documents are publicized.
Sorry...
How do people find you on mastodon if your instance isn't in your username anyway?