Introduction to AT Protocol
mackuba.eu
mackuba.eu
"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."
The main part of ATProto that is centralized is the PLC and that will eventually be made (most likely) into a consortium. PDS hosting is debatable
That being said, it should be possible to run completely independent atproto networks today. We have several dev infra setups for doing it in the ecosystem
But does anyone do it? It doesn't really matter if it's /theoretically possible/ if no one actually does it.
Running an ActivityPub server is piss easy, anyone can do it on a $5 VPS or in their basement, and that's one of its big strengths.
same statement can be applied to running a bluesky PDS. Here are the server recs: https://github.com/bluesky-social/pds?tab=readme-ov-file#sel...
Based on his progress posts it seems that ATproto is intentionally moving in the right direction and BlackSky has progressed to the point he’s asking for volunteers to move off Bluesky and try out his implementations
https://discord.atprotocol.dev/
Of course the spec is good too, very easy read
One of the most interesting projects is tangled.sh - a github-like using atproto for the social layer, which fits perfectly.
They are working on this, but it's still gonna take a while as I understand.
It's also generally not advisable to make your cypher text publicly visible
That being said, I'm working with others in the ecosystem on "permissioned space", which are much closer to how people think about Google Docs and similar systems working.
There is also another effort around E2EE content (MLS) for messaging. They are also thinking beyond just messages too
There's a working group for doing this but it'll be a while before anything is adopted at scale.
If fully public is okay for you, there is actually already a chatroom/IRC-esque platform called Roomy. It works well but it is all public and there's a touch more latency than a normal client-server platform due to the nature of atproto's gossip protocol.
. . .
ATH
Bluesky's name collision was pretty avoidable here but I guess they thought the obvious name was BS.
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).
When the encoding is UTF-8 (which it is here), the code unit is the byte.
They called the fields byteStart and byteEnd, but a more technically precise (no more or less accurate, but more precise) labels would be utf8CodeUnitStart and utf8CodeUnitEnd.
You may not have seen this interesting article before: https://hsivonen.fi/string-length/. I agree with its assessment that scalars are really pretty useless as a measure, and Python and Ruby are foolish to have chased it at such expense.
But seriously, I can’t think of any other popular languages that count by scalars or code points—it’s definitely not most languages, it’s a minority, all a very specific sort of language. “Most” encompasses well-formed UTF-8 (e.g. Rust), recommended UTF-8 but it doesn’t actually care (e.g. Go), potentially ill-formed UTF-16 (e.g. JavaScript, Java, .NET), and total-mess (e.g. C, C++).
Those old enough will know :)
NO CARRIERHave there been any products go embraced this? Or is it like ActivityPub where basically the whole thing is Mastodon.
- Threads
- Flipboard
- WordPress
- micro.blog
- NodeBB
- PeerTube
- Pixelfed
- GoToSocial
- Akkoma
- ...and countless smaller projects
This isn’t quite true. WordPress.com announced they were planning on ActivityPub support, but that is a separate entity run by a commercial company (Automattic).
Their plan was to support it specifically on Tumblr, as well as helping fund an open source plugin for it; there have been no plans to integrate it into the WordPress software directly.
I believe they’ve also deprioritised it as they did significant layoffs recently.
https://wordpress.org/plugins/activitypub/
I follow a few blogs on Mastodon just fine (for example John Carlos Baez's Azimuth, https://johncarlosbaez.wordpress.com/), it's just like an RSS reader in your timeline.
I would also discard services that auto post to the fediverse but are not actively used by the majority of users as such.
How do people find you on mastodon if your instance isn't in your username anyway?
And yes, that's one weakness of this system — there is no "real" account migration. Most you can do is set up two-way references between your old and new accounts and ask your followers to unfollow the old one and follow the new one. But your past content doesn't carry over.
But then idk, Bluesky's identity service is completely centralized, so the fediverse is better with regard to independence?
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 for the long read but as you see I've wasted way too much time into reading through developer posts and documentation, had to unload it somehow.
At the risk of sounding like a shill, I would also say that the protocol is much less mature than ActivityPub or Nostr, but the rate of progress that I've seen is pretty rapid (compared to APub at least, Nostr is also a rapidly-developing protocol but its harder for me to track its progress as there's no reliable source for protocol updates that is not on Nostr afaik) and with the active developer community surrounding it I firmly believe that most of these issues will be solved within the next few years at worst. Zeppelin has also progressed on bringing back some of these missing features, as video processing and chat have been introduced to the AppView (albeit proxied through Bluesky's services so it's a moot point).
There's an important distinction to make between AppViews and an APub instance, which is that AppViews handle solely the application portion of the user experience while APub instances typically manage the entirety of the user's experience. As a result, ATproto users can hop between any AppView without any lock-in to a specific AppView provider as their accounts aren't bound to their existence (which means that anyone can switch from using the Bluesky AppView to the Zeppelin AppView with little difficulty (or any other AppView)), while users on the Fediverse cannot easily do the same (applications can authenticate with a Fediverse account to confirm their identity but there are limits to what you can do, such as federating with the identity of that user). They're also not designed to be closed/single-user instances, mainly because the PDS handles the role of user management and platforming users and is where most of that responsibility is placed at. In regards to active usage, enough moderation controversies have happened with Bluesky Social's policies to the point that a small (at this moment) market has opened for a Bluesky with truly user-controllable moderation, and that Zeppelin will be one of the main products to serve that market. The costs also aren't that large compared to some of the larger Mastodon instances, so for the amount of content that it's storing it could be way worse (mstdn.social saved 180 euros when moving to another server apparently but there's definitely other examples of Mastodon unnecessarily ballooning instance costs as it grows in scale, because it's bloatware compared to what's out there. mstdn.social is also a fraction of the activity size of the ATproto network's output on off-peak hours, so eh).
I will say that this isn't a core attribute of the Fediverse, the base protocol is only slightly less extensive and modifiable than Nostr as projects like ActivityPods and "nomadic identities" (over a decade old!) exist which can perform a similar role to an ATproto PDS but with the Solid protocol but it's seen little adoption due to the lack of focus towards implementing "next-gen" features like these in the current set of APub server software.
Working Group is forming this fall, we'll be at IETF, Montreal in Nov
Also building one such platform that needs permissioned spaces, if you want to follow along
https://github.com/blebbit/atproto
https://bsky.app/profile/blebbit.app
Off the top of my head, there are also WGs for E2EE messaging, web monetization, and geo.
Lot's of infra getting built this year
ATDT2024561414
AT+QSINR?
AT+QRSRQ
AT+QRSRP
AT+QNWINFO
-- getting current status/band of a link
Do we have any new tools to prevent spam in a post-email world? Or can we just use the current email structure with some better GUI around PGP and Hashcash and force anyone who wants to send a message to burn 10 cents worth of electricity ?
I'm curious what you're looking for in an email standard ?
Personally, I'd prefer something like an expansion of how XMPP works. By default you only see what people in your contact list have sent you, and anything else is marked "dubious", and it's up to you to read it or not. I think it's a mistake that email servers have been given the responsibility to filter unwanted traffic. Email servers should have only ever simply passed along whatever they received (excluding excessively large messages, of course).
Any email client could implement this policy. You could even prioritize mail over who sent it or whether it's a reply to a mail you sent or have already read.
The first email a sender sends to a recipient has an attachment that serves as a request to email them for a specific purpose (e.g. human:human, mailing list, transactional). This email is not delivered to their inbox immediately, but to a separate “friend request” style queue. When the recipient approves, the sender receives a Biscuit token [0] and the email is delivered to the inbox.
Subsequent emails are sent by attenuating a one-time-use token from the master token, which is included in a header. Because they have verifiable authorisation, this can skip all existing spam heuristics because the receiving mail system knows for certain the recipient authorised this sender.
Biscuits can also be attenuated to reduce scope. Want the hotel you are staying at to only be able to send you email for the next 30 days? No problem. Mailing list providers can reject tokens that are scoped to transactional email. A sender can reduce blast radius of compromises by attenuating new tokens to give to third-party providers.
Authorised senders who spam can have all their historical emails quarantined at once and their ability to send in the future removed. Recipients can see who gave spammers their email address.
People who send mail are incentivised to implement this because it improves delivery rates by bypassing all existing spam filters, including IP reputation. “Ask for a token and you’ll never hit a spam filter again” is something a lot of people would jump at the chance for. No need for providers like Mailchimp, you could go back to sending mail directly from your own servers.
Recipients are incentivised to implement this because it will cut down on spam and phishing significantly.
This can be implemented independently of the other side because the fallback situation is the status quo – the initial email just has an attachment that goes ignored, and subsequent emails are sent without tokens and are subject to existing spam filters.
It’s possible for spammers to send lots of unsolicited contact requests, however separating things out into a spam-free inbox and a “this new person wants permission to email you” queue makes it far more manageable than the current ocean of potential spam in an overflowing inbox. Determining “is this new contact legitimate?” a handful of times is much easier than determining “is this email legitimate?” thousands of times more often.
What you’re essentially doing with this is bootstrapping a social graph on top of email. You can then add a bunch of other nice things on top of that, like public key cryptography, but the actual diff between current email and this system is surprisingly thin.
- email / inbox [or @mail since it is @atproto :]
- unsubscribe from email
- notifications / rsvp
The cool thing is that we could use the stackable moderation infra for dealing with bad actors
https://bsky.social/about/blog/03-12-2024-stackable-moderati...
And just unsolicited feedback but "Blebbit" is a deeply terrible name. It turns my stomach for some reason. I don't even know what a bleb could be or what it could represent besides, like, an ulcer.
There are two efforts around "permissioned" and "encrypted" spaces/content, where encrypted is the E2EE / signal like stuff and permissioned is more like Google Docs or the Discord like permissioning systems. There are use-cases for both
re: name, the second person to dislike, outnumbered by those who do like, will add you to the tally
the name is a play on plebeians / plebs / blebs, not to belittle, but to emphasize this is for the people, not the oligarchs.
Credible Exit Philosophy is important to me and the ATProtocol ecosystem. It means that users can leave an app without losing their data, that they can move their database without losing access, that the majority of Bluesky users could switch to an alternative if they become adversarial.
What it means is that ATProtocol bakes competition into our shared social fabric that all apps build on
Then the world invented pull-style electronic communications systems via another route. You're looking at one.
DMAC, DKIM, SPF, S/MIME, PGP are all ugly workarounds. The issues are fundamental.
Even ignoring pressing issues like lack of mandatory E2EE, SMTP requires encoding binary data into text. This includes the main body for most emails these days. Awfully wasteful.
So it will go the way of FTP.