Introduction to AT Protocol(mackuba.eu)
mackuba.eu
Introduction to AT Protocol
https://mackuba.eu/2025/08/20/introduction-to-atproto/
116 comments
Relevant post by Christine Lemmer-Webber (Co-creator of ActivityPub) https://dustycloud.org/blog/how-decentralized-is-bluesky/
a very opinionated piece that leads by conclusion rather than building up to it.
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
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
> it should be possible to run completely independent atproto networks today
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.
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.
BlackSky seems to be run by a competent dev with a high enough profile that I see his posts regularly without following him directly
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
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
What is this BlackSky you're talking about?
https://www.blackskyweb.xyz - it's the black people community on Bluesky, they started first with some custom feeds and blocklists/labeller, now they have a PDS and relay, and they're planning to launch a forked version of the app and eventually have a full independent infra basically. With some extra features like option to make "internal" posts that aren't shared with the wider Bluesky but only with people on the PDS.
People are doing it yeah. The post linked in the comment above is already outdated, see https://whtwnd.com/bnewbold.net/3lo7a2a4qxg2l for relatively recent developments.
> 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...
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...
I could be mistaken, but I believe BlackSky is pretty close today.
I am finding it very informative.
Was fully expecting to see descriptions of “ATD” and “ATH”…
Yes, exactly! I was expecting https://en.wikipedia.org/wiki/Hayes_AT_command_set
RING, RING, RING, ATA, CONNECT!
+++ATH0
If you are interested in building on ATProtocol, one of the best places to start is the Discord (until we have an atproto native alt @blebbit.app)
https://discord.atprotocol.dev/
Of course the spec is good too, very easy read
https://atproto.com
https://docs.bsky.app
https://discord.atprotocol.dev/
Of course the spec is good too, very easy read
https://atproto.com
https://docs.bsky.app
When discord alternative?
I've been building Mikoto Platforms on https://github.com/mikotoIO/mikoto
Ai generated images on the homepage are a huge bummer :(
What sorts of things can be built on the protocol?
It’s good at social-oriented apps - there’s obviously Bluesky, and many other smaller apps in the style of other platforms.
One of the most interesting projects is tangled.sh - a github-like using atproto for the social layer, which fits perfectly.
One of the most interesting projects is tangled.sh - a github-like using atproto for the social layer, which fits perfectly.
Anything "social" basically - the first ideas that come to people's minds are of course things like: GitHub but on ATProto, Instagram on ATProto, Tiktok on ATProto, Reddit on ATProto…
Why isn't there a Discord built on ATProto ? [Serious Question, wondering if there are trade-offs that make this especially annoying]
Currently atproto is still figuring out how to approach private data. Right now there exists extremely limited abilities to store private data via the bluesky preferences but until that mechanism is standardised in a way other projects can use, there's not really a good way to store data privately let alone transmit data privately.
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.
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.
So, one big problem is that there's basically no way to have shared-private data in the protocol - it's either private to you, or fully public. Hence no "locked accounts", "followers-only posts" and so on on Bluesky, and this also prevents more sensitive ideas like e.g. "Strava on ATProto" (where you probably don't want to share your run map with the whole world!).
They are working on this, but it's still gonna take a while as I understand.
They are working on this, but it's still gonna take a while as I understand.
Ah thanks for the answer. What's the PKI story on bluesky, doesn't every identity have a corresponding public key? So if I had a list of people I wanted to a post to be visible to, couldn't I "just" encrypt it with a key that is decryptable by each of those individuals via their pubkey?
PKI distribution for encrypted data is an unsolved problem at the scale of many millions or billions of people. Signal caps at 10k iirc
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
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
Peergos has a private data solution that is compatible with (and predates) atproto (dag-cbor, portable data and accounts and social graph).
Fantastic. Looking forward to seeing where you land.
It’s not that shared private data is impossible, just that the mechanisms haven’t been fleshed out yet. I expect this type of setup might be difficult to scale?
I'm not really familiar with that layer of things, but I think it's possible, though that "just" is doing a lot of work here of course, and I think it might not necessarily be a good idea to have encrypted messages available publicly for everyone all the time, so they can collect them and wait until someone slips up / a vulnerability is found / they have enough hardware to crunch it...
My immediate thought to
Working on it, https://blebbit.app (mainly landing pages, but login and basic chat work)
Thats such a bummer, I was on the matrix dev chat for a while and it was good and helpful. I wonder why they changed it from that?
I don't think that Matrix chat was used much after the initial months, I've only really heard about it in legends... That Discord (the ATProto Touchers) is community-run.
Here I was thinking I'd see old AT commands for controlling radios. Learned something new
I believe that's still used in phones for communication between the computer and the cell phone hardware.
> 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.
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’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).
> indexing by bytes instead of UTF-8 code units
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.
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.
Sorry, I keep mixing these - bytes instead of scalars, which I think would be more natural to iterate over in most languages (at least the ones I use).
OK, checked and Ruby does seem to use scalars. Well, unless you mess with encodings. Then it’s messy. So it’s probably better and worse than Python 3.
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++).
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++).
Thanks, will have a read :)
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.
Have there been any products go embraced this? Or is it like ActivityPub where basically the whole thing is Mastodon.
ActivityPub is embraced by:
- Threads
- Flipboard
- WordPress
- micro.blog
- NodeBB
- PeerTube
- Pixelfed
- GoToSocial
- Akkoma
- ...and countless smaller projects
> WordPress
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.
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.
What do you mean? WordPress already supports ActivityPub through their plugin:
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.
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.
My point is in terms of activity. I’m familiar with all those services. I recommend doing a percentage of each vs total activitypub content.
I would also discard services that auto post to the fediverse but are not actively used by the majority of users as such.
I would also discard services that auto post to the fediverse but are not actively used by the majority of users as such.
[deleted]
Beyond Bluesky, there's a growing ecosystem including Pebble (a self-hosted PDS), Skychat (messaging), Skeet (app framework), Graysky (mobile client), and several specialized feeds/algorithms - unlike ActivityPub, ATProto's architecture allows for more diverse application types while maintaining interoperability.
Do you have experience with Pebble? Could be nice to have a ready made pds!
For now mostly just small things that the Bluesky dev/user community is playing with, but check out e.g. Tangled which is meant to be a GitHub alternative on ATProto: https://tangled.sh
TikTok: https://bsky.app/profile/skylight.social
Insta: https://bsky.app/profile/pinksky.app
Twitch: https://bsky.app/profile/stream.place
Events: https://bsky.app/profile/smokesignal.events
Insta: https://bsky.app/profile/pinksky.app
Twitch: https://bsky.app/profile/stream.place
Events: https://bsky.app/profile/smokesignal.events
Build your own feeds / algorithms in the browser: https://graze.social
Pinterest: https://bsky.app/profile/scrapboard.org
And here is an app to generate unified feed for such apps: https://bsky.app/profile/atpage.one
Similarly our news site is considering a live-blog feature and I'm wondering if AT Proto would be a fun way to do it.
activitypub is mostly used in the fediverse. mastodon is one of many clients and servers, and one of the worst.
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.
It still doesn't solve the account migration issue though right? If you move to a different instance your old instance still has to redirect.
How do people find you on mastodon if your instance isn't in your username anyway?
How do people find you on mastodon if your instance isn't in your username anyway?
Your instance is in your username. The full username is "@[email protected]". You use WebFinger (https://mastodon.social/.well-known/webfinger?resource=acct:...) to convert that to the ActivityPub actor ID, which in my case would be "https://mastodon.social/users/grishka".
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?
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?
I didn't write this for the HN crowd, but here we go anyway: https://gagliardoni.net/#20250818_battle_of_socials
Happy to correct any factual inaccuracies.
Happy to correct any factual inaccuracies.
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.
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.
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.
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.
You're welcome. I understand that a lot of what I've said is technical jargon and nonsense to the average *.bsky.social user but a lot of it can be simply dumbed down to "the client can choose to ignore it" or "get off Bluesky servers, lol?".
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.
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.
would love fb marketplace disruptor on atproto
there is a marketplace in nostr if u interested
Isn't the problem the network effect, and not the protocol whatsoever?
yea i dont think there's any blocker from a protocol perspective, im just saying i'd love to see it happen. adoption for sure among the largest hurdles id guess
Retvrn to Craigslist.
Here's another great resource about the ATProto distributed design
https://atproto.com/articles/atproto-for-distsys-engineers
https://atproto.com/articles/atproto-for-distsys-engineers
That was a nice read, thanks.
I'll save you a click: it's unrelated to the Hayes AT commands [1].
[1] https://en.wikipedia.org/wiki/Hayes_AT_command_set
[1] https://en.wikipedia.org/wiki/Hayes_AT_command_set
Would love for more platforms to embrace the AT protocol.
I'm working with some people on permissioned spaces for atproto (spec and pds changes). This will unlock a ton of use-cases not possible today
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
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
In this house, we believe “AT protocol” refers to Hayes modem commands.
ATDT2024561414
ATDT2024561414
A slightly more modern usage for cell modems that still implement AT commands in 2025:
AT+QSINR?
AT+QRSRQ
AT+QRSRP
AT+QNWINFO
-- getting current status/band of a link
AT+QSINR?
AT+QRSRQ
AT+QRSRP
AT+QNWINFO
-- getting current status/band of a link
I see the error of forgetting the long distance prefix and dialling some poor innocent to squeal tones in xyr ear during Zone Mail Hour is alive and well. (-:
+++ ATH0
This brings back memories of hanging my 56k modem up with a specially crafted ping command :)
I was expecting the old AT protocol i use to communicate with Radio module
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!
this directory does not load
Was hoping that BlueSky somehow used the AT command set.
Would be great to have a new modern alternative to the E-mail standard that is usable for both public and private messaging.
ActivityPub can be used for both public and private messaging, though I don't think the e-mail standard needs to be retired anytime soon.
There was once an idea named IM2000.
Then the world invented pull-style electronic communications systems via another route. You're looking at one.
* https://news.ycombinator.com/item?id=10410164
* https://jdebp.uk/Proposals/IM2000/
Then the world invented pull-style electronic communications systems via another route. You're looking at one.
* https://news.ycombinator.com/item?id=10410164
* https://jdebp.uk/Proposals/IM2000/
There's DIME[0]. I wish I heard about the effort more often, as it's sorely needed.
0. https://en.wikipedia.org/wiki/Dark_Mail_Alliance
0. https://en.wikipedia.org/wiki/Dark_Mail_Alliance
We might be able to do this with permissioned spaces. There are instances or use-cases where you want an outside entity to make changes to a user's repo
- 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...
- 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...
stackable moderation for ignoring senders is a cool idea. I'll keep an eye out for permissioned spaces, is there encryption and signatures involved at all? (everything on bluesky is signed with PKI, iirc?)
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.
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.
Your content is signed with a key, but there isn't PKI in the same sense as certificates
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
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
there shouldn't be a rush to replace the things that have stood the test of time. Lindy's law would suggest a protocol that's been around 40+ years is fundamental and won't be going anywhere anytime soon.
When it comes to SMTP for email, time has only served to highlight its inadequacy.
DMAC, DKIM, SPF, S/MIME, PGP are all ugly workarounds. The issues are fundamental.
DMAC, DKIM, SPF, S/MIME, PGP are all ugly workarounds. The issues are fundamental.
those ugly workarounds are actually brilliant signs of adaptability (not signs of failure). SMTP isn't inadequate, it's resilient. There's a good chance we'll still have SMTP around another 50-500 years.
No, we won't w/o breaking changes. There's no way.
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.
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.
email has come a long way with SPF, DKIM, and DMARC, and its cool that anyone can purchase a slice of the global namespace that is transferable between providers, but AFAIK the biggest road block to using email in a distributed self sovereign way is reputation and getting your messages delivered to google and outlook users partially because of the nonstop spam.
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 ?
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 ?
A quick back-of-the-envelope calculation says that USD 0.1 would be about 700 Wh, so, give or take, a high-performance desktop processor running full tilt for over four hours.
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).
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).
> 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.
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.
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.
Yes, but if the third server down the line didn't propagate the email, there's not much the client can do. That's what sucks about email as a protocol; it's been taken over by a handful of providers who will refuse to play ball with anyone outside their club, or who doesn't have the time to monitor the continuously-updated black lists.
There’s a fairly direct route to solving this with email. The problem that needs to be solved is that knowledge of an email address is the only thing needed to send to it. Introducing recipient consent as an additional requirement solves spam and phishing.
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.
[0] https://www.biscuitsec.org
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.
[0] https://www.biscuitsec.org
"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."