The protocol is the API.
September 26, 2025
Open source has clearly won. Yes, there are plenty of closed source products and businesses. But the shared infrastructure—the commons—runs on open source.
We might take this for granted, but it wasn’t a foregone conclusion thirty five years ago. There were powerful forces that wanted open source to lose. Some believed in the open source model but didn’t think it could ever compete with closed source. Many categories of tools only existed as closed source. A Microsoft CEO called open source cancer—a decade before Microsoft has rebuilt its empire around it. The open source movement may not have lived up to the ideals of the “free software”, but it won in industry adoption. Nobody gets fired for choosing open source these days. For much crucial software, open source is now the default.
I believe we are at a similar juncture with social apps as we have been with open source thirty five years ago. There’s a new movement on the block. I like to call it “open social”. There are competing visions for what “open social” should be like. I think the AT Protocol created by Bluesky is the most convincing take on it so far. It’s not perfect, and it’s a work in progress, but there’s nothing I know quite like it.
In this post, I’ll explain the ideas of the AT Protocol, lovingly called atproto, and how it changes the relationship between the user, the developer, and the product.
I don’t expect atproto and its ecosystem (known as the Atmosphere) to win hearts overnight. Like open source, it might take a few decades to become ubiquitous. By explaining these ideas here, I’m hoping to slightly nudge this timeline. Despite the grip of today’s social media companies, I believe open social will eventually seem inevitable in retrospect—just like open source does now. Good things can happen; all it takes is years of sustained effort by a community of stubborn enthusiasts.
So what is it all about?
What open source did for code, open social does for data.
Before Social
The web is a beautiful invention.
You type https://alice.com and you end up on Alice’s website.
Or you type https://bob.com and you end up on Bob’s website.
In a sense, your browser is a portal to millions of different worlds, each with its own little jurisdiction. Only Alice decides what appears on Alice’s website. Only Bob decides what appears on Bob’s website. They meaningfully “own their data”.
This doesn’t mean that they’re isolated. On the contrary, Alice can embed Bob’s picture with an <img src>, and Bob can link to Alice’s page with <a href>:
Alice and Bob can link to each other, but they remain in charge of their sites.
What do I mean by saying Alice and Bob are in charge of their own sites? Even if they’re not physically hosting their content on their own computers, they could always change hosting. For example, if Alice’s hosting provider starts deleting her pages or injecting ads into them, Alice can take her content to another host, and point https://alice.com at another computer. The visitors won’t need to know.
This is important. Hosting providers have no real leverage over Alice and Bob. If the hosting provider “turns evil” and starts messing with your site, you can just walk away and host it elsewhere (as long as you have a backup). You’re not going to lose your traffic. All existing links will seamlessly resolve to the new destination.
If Alice changes her hosting, Bob won’t need to update any links to Alice’s website. Alice’s site will keep working as if nothing had happened. At worst, a DNS change might make it inaccessible for a few hours, but then the web will be repaired:
Imagine how different the incentives would be if links were tied to physical hosts!
If changing a hosting provider caused Alice to lose her traffic, she would think many times before changing providers. Perhaps she’d stick with her existing provider even if it was messing with her site, as losing her connections is even worse. Luckily, web’s decentralized design avoids this. Because it’s easy to walk away, hosting providers are forced to compete, and hosting is now a commodity.
I think the web is a beautiful idea. It links decentralized islands controlled by different people and companies into one interconnected surface that anyone can index and navigate. Links describe a relationship between logical documents rather than between physical servers. As a result, you’re not a hostage to your hosting.
As a wise person said, in theory, there is no difference between theory and practice, but in practice there is. So what’s been happening with the web?
Closed Social
In the early 90’s, the main way to publish something on the web was to have your own website. Today, most people publish content by using a social media app.
Alice and Bob are still publishing things. But instead of publishing at domains like alice.com and bob.com, they publish at usernames like @alice and @bob allocated by a social media company. The things they publish are not HTML pages, but app-specific entities such as profiles, posts, comments, likes, and so on.
These entities are usually stored in a database on the social company’s servers. The most common way to visualize a database is as a sequence of rows, but you could also visualize it as a graph. This makes it look very similar to web itself:
What does this social graph enable that a web of personal sites doesn’t?
The advantage of storing structured app-specific entities, such as posts and likes, instead of HTML documents is obvious. App-specific entities such as posts and likes have a richer structure: you can always turn them into HTML documents later, but you can also aggregate them, filter them, query, sort, and recombine them in different ways before that. This allows you to create many projections of the same data—a profile page, a list of posts, an individual post with comments.
Where this really shines, though, is when many people use the same social app. Since everyone’s public content is now in a single database, it is easy to aggregate across content published by many people. This enables social features like global search, notifications, feeds, personalized algorithms, shared moderation, etc.
It’s specifically this social aggregation that blows the “personal sites” paradigm out of the water. People are social creatures, and we want to congregate in shared spaces. We don’t just want to visit each other’s sites—we want to hang out together, and social apps provide the shared infrastructure. Social aggregation features like notifications, feeds, and search are non-negotiable in modern social products.
Today, the most common way to implement these features is shaped like this:
There still exists a web-like logical model of our data—our profiles, our posts, our follows, our likes, all the things that we’ve created—but it lives within some social app’s database. What’s exposed to the web are only projections of that model—the Home screen, the Notifications screen, the HTML pages for individual posts.
This architecture makes sense. It is the easiest way to evolve the “personal sites” paradigm to support aggregation so it’s not surprising today’s apps have largely converged on it. People create accounts on social apps, which lets those apps build aggregated features, which entices more people to sign up for those apps.
However, something got lost in the process. The web we’re actually creating—our posts, our follows, our likes—is no longer meaningfully ours. Even though much of what we’re creating is public, it is not a part of the open web. We can’t change our “hosting provider” because we’re now one step removed from how the internet works. We, and the web we create, have become rows in somebody else’s database:
This creates an imbalance.
When Alice used to publish her stuff on alice.com, she was not tied to any particular hosting provider. If she were unhappy with a hosting provider, she knew that she could swap it out without losing any traffic or breaking any links:
That kept the hosting providers in check.
But now that Alice publishes her stuff on a social media platform, she can no longer “walk away” without losing something. If she signs up to another social platform, she would be forced to start from scratch, even if she wants to retain her connections. There is no way for Alice to sever the relationship with a particular app without ripping herself, and anything she created there, out of its social graph:
The web Alice created—who she follows, what she likes, what she has posted—is trapped in a box that’s owned by somebody else. To leave it is to leave it behind.
On an individual level, it might not be a huge deal.
Alice can rebuild her social presence connection by connection somewhere else. Eventually she might even have the same reach as on the previous platform.
However, collectively, the net effect is that social platforms—at first, gradually, and then suddenly—turn their backs on their users. If you can’t leave without losing something important, the platform has no incentives to respect you as a user.
Maybe the app gets squeezed by investors, and every third post is an ad. Maybe it gets bought by a congolomerate that wanted to get rid of competition, and is now on life support. Maybe it runs out of funding, and your content goes down in two days. Maybe the founders get acquihired—an exciting new chapter. Maybe the app was bought by some guy, and now you’re slowly getting cooked by the algorithm.
If your next platform doesn’t respect you as a user, you might try to leave it, too.
But what are you going to do? Will you “export your data”? What will you do with that lonely shard of a social graph? You can upload it somewhere as an archive but it’s ripped out of its social context—a pitiful memento of your self-imposed exile.
Those megabytes of JSON you got on your way out are dead data. It’s like a branch torn apart from its tree. It doesn’t belong anywhere. To give a new life to our data, we’d have to collectively export it and then collectively import it into some next agreed-upon social app—a near-impossible feat of coordination. Even then, the network effects are so strong that most people would soon find their way back.
You can’t leave a social app without leaving behind the web you’ve created.
What if you could keep it?
Open Social
Alice and Bob are still using social apps. Those apps don’t look much different from today’s social apps. You could hardly tell that something has changed.
Something has changed, though. (Can you spot it?)
Notice that Alice’s handle is now @alice.com. It is not allocated by a social media company. Rather, her handle is the universal “internet handle”, i.e. a domain. Alice owns the alice.com domain, so she can use it as a handle on any open social app. (On most open social apps, she goes by @alice.com, but for others she wants a distinct disconnected identity, so she owns another handle she’d rather not share.)
Bob owns a domain too, even though he isn’t technical. He might not even know what a “domain” is. Bob just thinks of @bob.com as his “internet handle”. Some open social apps will offer you a free subdomain on registration, just like Gmail gives you a free Gmail address, or may offer an extra flow for buying a domain. You’re not locked into your first choice, and can swap to a different domain later.
Your internet handle being something you actually own is the most user-visible aspect of open social apps. But the much bigger difference is invisible to the user.
When you previously saw the social graph above, it was trapped inside a social app’s database. There was a box around that graph—it wasn’t a part of the web. With open social, Alice’s data—her posts, likes, follows, etc—is hosted on the web itself. Alongside her personal site, Alice now has a personal repository of her data:
This “repository” is a regular web server that implements the AT Protocol spec. The only job of Alice’s personal repository is to store and serve data created by Alice in the form of signed JSON. Alice is technical, so she likes to sometimes inspect her repo using open source tools like pdsls, Taproot, or atproto-browser.
Bob, however, isn’t technical. He doesn’t even know that there is a “repository” with his “data”. He got a repository behind the scenes when he signed up for his first open social app. His repository stores his data (from all open social apps).
Have another look at this picture:
These aren’t rows in somebody’s database. This is a web of hyperlinked JSON. Just like every HTML page has an https:// URI so other pages can link to it, every JSON record has an at:// URI, so any other JSON record can link to it. (On this and other illustrations, @alice.com is a shorthand for at://alice.com.) The at:// protocol is a bunch of conventions on top of DNS, HTTP, and JSON.
Now have a look at the arrows between their records. Alice follows Bob, so she has a follow record linking to Bob’s profile record. Bob commented on Alice’s post, so he has a comment record that links to Alice’s post record. Alice liked his comment, so she has a like record with a link to his comment record. Everything Alice creates stays in her repo under her control, everything Bob creates stays in his repo under his control, and links express the connections—just like in HTML.
All of this happens behind the scenes and is invisibile to a non-technical user. The user doesn’t need to think about where their data is stored until it matters, just like the user doesn’t think about how servers work when navigating the web.
Alice’s and Bob’s repositories could be hosted on the same machine. Or they could be hosted by different companies or communities. Maybe Alice is self-hosting her repository, while Bob uses a free hosting service that came by default with his first open social app. They may even be running completely different implementations. If both servers follow the AT protocol, they can participate in this web of JSON.
Note that https://alice.com and at://alice.com do not need to resolve to the same server. This is intentional so that having a nice handle like @alice.com doesn’t force Alice to host her own data, to mess with her wesite, or even to have a site at all. If she owns alice.com, she can point at://alice.com at any server.
If Alice is unhappy with her hosting, she can pack up and leave:
(This requires a modicum of technical skill today but it’s getting more accessible.)
Just like with moving a personal site, changing where her repo is being served from doesn’t require cooperation from the previous host. It also doesn’t disrupt her ability to log into apps and doesn’t break any links. The web repairs itself:
It is worth pausing for a moment to appreciate what we have here.
Every bit of public data that Alice and Bob created—their posts, their likes, their comments, their recipes, their scrobbles—is meaningfully owned by them. It’s not in a database subject to some CEO’s whims, but hosted directly on the open web, with ability to “walk away” without losing traffic or breaking any links.
Like the web of personal sites, this model is centered around the user.
What does it mean for apps?
Each open social app is like a CMS (content management system) for a subset of data that lives in its users’ repositories. In that sense, your personal repository serves a role akin to a Google account, a Dropbox folder, or a Git repository, with data from your different open social apps grouped under different “subfolders”.
When you make a post on Bluesky, Bluesky puts that post into your repo:
When you star a project on Tangled, Tangled puts that star into your repo:
When you create a publication on Leaflet, Leaflet puts it in your repo:
You get the idea.
Over time, your repo grows to be a collection of data from different open social apps. This data is open by default—if you wanted to look at my Bluesky posts, or Tangled stars, or Leaflet publications, you wouldn’t need to hit these applications’ APIs. You could just hit my personal repository and enumerate all of its records.
To avoid naming collisions, the data in the repository is grouped by the format:
In any user’s repo, Bluesky posts go with other Bluesky posts, Leaflet publications go with Leaflet publications, Tangled stars go with Tangled stars, and so on. Each data format is controlled and evolved by developers of the relevant application.
I’ve drawn a dotted line to separate them but perhaps this is misleading.
Since the data from different apps “lives together”, there’s a much lower barrier for open social apps to piggyback on each other’s data. In a way, it starts to feel like a connected multiverse of apps, with data from one app “bleeding into” other apps.
When I signed up for Tangled, I chose to use my existing @danabra.mov handle. That makes sense since identity can be shared between open social apps. What’s more interesting is that Tangled prefilled my avatar based on my Bluesky profile. It didn’t need to hit the Bluesky API to do that; it just read the Bluesky profile record in my repository. Every app can choose to piggyback on data from other apps.
That might remind you of Gravatar, but it works for every piece of data. Every open social app can take advantage of data created by every other open social app:
There is no API to hit, no integrations to build, nothing to get locked out of. All the data is in the user’s repository, so you can parse it (as typed JSON), and use it.
The protocol is the API.
This has deep implications for the lifecycle of products. If a product gets shut down, the data doesn’t disappear. It’s still in its users’ repos. Someone can build a replacement that makes this data comes back to life. Someone can build a new product that incorporates some of that data, or lets users choose what to import. Someone can build an alternative projection of existing data—a forked product.
This also reduces the “cold start” problem for new apps. If some of the data you care about already exists on the network, you can bootstrap your product off of that. For example, if you’re launching a short video app, you can piggyback on the Bluesky follow records so that people don’t have to find each other again. But if that doesn’t make sense for your app, you can have your own follow records instead, or offer a one-time import. All existing data is up for reuse and remixing.
Some open social apps are explicitly based around this sort or remixing. Anisota is primarily a Bluesky client, but it natively supports showing Leaflet documents. Popfeed can cross-post reviews to both Bluesky and Leaflet. If Leaflet does gets very popular, there’s nothing stopping Bluesky itself from supporting a Leaflet document as another type of post attachment. In fact, some third-party Bluesky client could decide to do that first, and the official one could eventually follow.
This is why I like “open social” as a term.
Open social frees up our data like open source freed up our code. Open social ensures that products can get a new life, that people can’t be locked out of what they have created, and that products can be forked and remixed. You don’t need an “everything app” when data from different apps circulates in the open web.
If you’re technical, by now you might have a burning question.
How the hell does aggregation work?!
Since every user’s records live in that user’s repository, there are millions (potentially billions?) repositories. How can an app efficiently query, sort, filter, and aggregate information from them? Surely it can’t search them on demand.
I’ve previously used a CMS as an analogy—for example, a blogging app could directly write posts to your repository and then read posts from it when someone visits your blog. This “singleplayer” use case would not require aggregation at all.
To avoid hitting the user’s repository every time you want to display their blog post, you can connect to the user’s repository by a websocket. Every time a record relevant to your app is created, updated, or deleted, you can update your database:
This database isn’t the source of truth for user’s data—it’s more like an app-specific cache that lets you avoid going to the user repo whenever you need some data.
Coincidentally, that’s the exact mechanism you would use for aggregation. You listen to events from all of your app users’ repositories, write them to a local database, and query that database as much as you like with zero extra latency.
This might remind you of how Google Reader crawls RSS (rip).
To avoid opening a million event socket connections, it makes sense to listen to a stream that retransmits events from all known repositories on the network:
You can then filter down such a stream to just the events you’re interested in, and then update your local database in response to the events your app cares about.
For example, Leaflet is only interested in events concerning pub.leaflet.* records. However, Leaflet can also choose to listen to other events. If Leaflet wanted to add a feature that shows backlinks to Bluesky discussions of a Leaflet document, it would simply start tracking bsky.app.feed.post records too.
You can try it yourself by clicking on this link:
This is a realtime stream of every single event on the network. It’s dominated by app.bsky.* records because Bluesky is the most-used app, but you can filter it down to other record types. This retransmitter (called a “relay”) is operated by Bluesky, but you don’t have to depend on it. The Blacksky community runs their own relay implementation at wss://atproto.africa, which you can try here.
Another important detail is that commits are cryptographically signed, which means that you don’t need to trust a relay or a cache of network data. You can verify that the records haven’t been tampered with, and each commit is legitimate.
As time goes by, we’ll see more infrastructure built around and for open social apps. Graze is letting users build their own algorithmic feeds, and Slices is an upcoming developer platform that does large-scale repository indexing for you.
These are all technical details, though.
What matters is the big picture.
The Big Picture
The pre-social web of “personalized sites” got data ownership, hosting independence, and linking right. Alice and Bob fully participate in the web:
The closed social web innovated in scaling and in social aggregation features. Notifications, search, and feeds are non-negotiable in modern social products:
However, the closed social web has also excluded us from the web. The web we create is no longer meaningfully ours. We’re just rows in somebody else’s database.
Open social frees the web we’re creating from somebody else’s boxes. Our profiles, likes, follows, recipes, scrobbles, and other content meaningfully belong to us:
The data no longer lives inside the products; the products aggregate over our data:
This blurs the boundaries between apps. Every open social app can use, remix, link to, and riff on data from every other open social app.
The web we’ve created remains after the products we used to create it are gone. Developers can build new products to recontextualize it. No one can take it away.
As more products are built in the open social paradigm, there’s going to be a shift.
People might not ever start using technical concepts like “decentralization” but they do understand when data from one app can seamlessly flow into other apps.
People might not care about “federation” but they do notice when they log into a competing product, and their data is already there, and their reach is intact.
And people do understand when they’re being fucked with.
For a long time, open social will rely on a community of stubborn enthusiasts who see the promise of the approach and are willing to bear the pains of building (and failing) in a new ecosystem. But I don’t think that dooms the effort. That’s the history of every big community-driven change. Somebody has to work through the kinks. Like with open source, open social is a compounding effort. Every mildly successful open social app lifts all open social apps. Every piece of shared infrastructure can benefit somebody else. At some point, open is bound to win.
I just hope it doesn’t take thirty five years.
Pay what you likeRead the original article
Comments
The author is talking about owning a domain and how having that domain gives you ownership over your data... But I can't but think that, at least in the US, domain names are rented from private Internet service providers. There is no ownership involved. One way or another, we are still paying a company.
The assumption of the article is that ISPs are stable and net neutral enough that one would not worry about the ISP going under or seeking some personal vendetta against you and booting your domain. A separate entity may no longer be hosting our data, but a private entity is the gatekeeper of whether anyone is able to see your data.
All that to say, if we want true ownership of domains, ISPs need to be a nationalized, democratized service.
By gr__or 2025-09-278:22 While I agree with the sentiment, I think it confuses ISPs with registrars. There are still many ISPs that do that service as well, it's less common than it used to be.
It is quite common for national TLDs (like .de, .jp or .cn) to be managed by not-for-profit entities, under contract with their respective governments... which might also not be great wrt censorship.
There is also the general issue of equal access, where shorter, more memorable domains get more expensive and hodling domain names is only disincentivized for people without enough funds. I would very much like to see an alternative system to domain names, probably something more in the web of trust space.
There are alternatives to DNS, like GNS (GNU Name System): https://www.gnunet.org/en/gns.html
By ryangibb 2025-09-2711:07 The difficulty with the GNS is getting the public keys that enable the decentralisation. Key signing parties seem to have their limits.
There’s a bunch of alternative DNS roots out there, that are similarly hierarchical, but really interesting: https://en.wikipedia.org/wiki/Alternative_DNS_root#Implement...
By doublerabbit 2025-09-2710:36 Opennic too, they even allow you to host your own tld.
It's getting harder to change DNS settings on Windows, even systemd makes it a PITA to update DNS entries.
By infinitifall 2025-09-278:211 reply There are clearnet websites for flat earthers, anti-vaxxers, cults, hacker groups, classified document leakers, nazi groups and terrorist organisations. Finding a registrar that lets you say what you want is a solved problem.
By a2128 2025-09-2711:44 Currently most people publish stuff on big platforms so governments, activists and billionaires will go after these platforms to influence or control what's being talked about. I worry that if we never had big platforms, or we moved past them, all of the focus would be on going after registrars and hosts instead. It's not a bulletproof system unfortunately
That was very well written. I have to admit that because AT Protocol was Bluesky's I thought it was some corpo version of ActivityPub, but based on this post it makes a lot of sense. The data is in a 'repository' of my choice. I think I like that very much and it aligns with the kind of general principle I have where it's better to apply filtering etc. on the read side rather than on the write side so that I can publish all sorts of things that I want into my repo and others can then read etc. that stuff.
The arrows do seem to imply that commenting on my posts goes into my repo, but I'm sure that's just an imprecision trying to express an idea. The whole thing seems very cool and decentralized.
When I went to see what it takes to run a separate PDS on AT, though, I see that it's all nice and packaged up and has certain assumptions:
1. It takes care of SSL etc.
2. It will stand up HTTPS/WSS servers to handle a bunch of RPC
So in practice, you don't get https://roshangeorge.dev and at://roshangeorge.dev because for the latter you kind of need https://roshangeorge.dev/xrpc and wss://roshangeorge.dev
Therefore, you probably end up with https://roshangeorge.dev and at://at.roshangeorge.dev and then you can run https://at.roshangeorge.dev and wss://at.roshangeorge.dev
All minor stuff and doesn't take away from the main point, but it was a thing.
By danabramov 2025-09-2622:401 reply >The arrows do seem to imply that commenting on my posts goes into my repo, but I'm sure that's just an imprecision trying to express an idea. The whole thing seems very cool and decentralized.
The way I used arrows might’ve been a bit confusing because I use two types of them.
The solid ones pointing from @alice.com downwards indicate ownership. They’re the same thing as grouping by color. All blue stuff is Alice’s.
The dashed ones pointing between records are links. Those are equivalent of <a href>. Any record can link to any other record, no matter which repositories either is in.
When you comment on someone’s post, your comment goes into your repo, but it has a link to the parent post (which may be in any repo). That’s usually how you want to represent it in the data model so that anyone indexing both records can reconstruct the relationship.
In the example, Bob comments on Alice’s post. So Bob’s comment is in Bob’s repo and Alice’s post is in Alice’s repo.
To clarify your specific point, a person commenting on your post will create record in their repo. In fact one can never create records in somebody else’s repo. That’s the central premise.
Hope that makes sense.
By vermilingua 2025-09-277:412 reply This makes sense but doesn’t this imply that displaying comments under a post is a very expensive operation?
Also not totally clear to me (apologies if I missed it in the post) is where repositories live, I have a bsky account with my own domain, but I am not running anything to host a repo. Am I correct in assuming that bsky is hosting my repo, but I would have the option to self host or move it elsewhere and continue using bsky?
By danabramov 2025-09-279:59 > doesn’t this imply that displaying comments under a post is a very expensive operation?
It would be expensive if you don’t do your own aggregation. The recommendation for social atproto apps is to aggregate the records you care about into a local database and essentially build your app-specific index/cache of the network.
Ctrl+F to this part: “Coincidentally, that’s the exact mechanism you would use for aggregation. You listen to events from all of your app users’ repositories, write them to a local database, and query that database as much as you like with zero extra latency.”.
(One interesting consequence is that indexing the network can also be done by someone on your behalf, see https://slices.network/ for an upcoming experiment in that area.)
> Also not totally clear to me (apologies if I missed it in the post) is where repositories live, I have a bsky account with my own domain, but I am not running anything to host a repo.
Yeah, Ctrl+F here: ”Note that https://alice.com and at://alice.com do not need to resolve to the same server. This is intentional so that having a nice handle like @alice.com doesn’t force Alice to host her own data, to mess with her website, or even to have a site at all. If she owns alice.com, she can point at://alice.com at any server.”
You can inspect where at:// points for your handle in an online browser like http://pdsls.dev. If you put your handle there you’ll see the physical server it resolves to at the top.
Presumably you signed up from Bluesky so yes, Bluesky is hosting your repo by default. You can move it somewhere else with no disruption. See https://whtwnd.com/bnewbold.net/3l5ii332pf32u for how to do this from CLI and https://pdsmoover.com/info.html for something less technical.
By nasso_dev 2025-09-278:53 Displaying comments is cheap because the AppView (the "cache" layer that consumes the aggregated feed of records from the relay) can maintain a relational database of the social web/graph.
When it receives a post, it creates a row in the Post table. When it receives a comment, it creates a row in the Comment table, which has a column pointing to the Post it's replying to. Then, getting all comments under a post is easy SQL.
About your second question: yes, you're correct. What handle you use and where your data is hosted are completely separate matters.
By whyrusleeping 2025-09-2620:171 reply The default pds packaging takes care of SSL, but thats not a requirement, just something we try to make easy for users.
Also at:// URIs are of the form at://DID/..., and your human readable handle is bound to your DID through DNS TXT records _atproto.roshangeorge.dev, but applications all know to render that as just roshangeorge.dev. That DID points to a document that specifies where your server lives, so the HTTPS/WSS routes can live wherever you want them to.
Also likes/replies/etc on your posts go in their authors repos not yours, your intuition is correct there.
By extraduder_ire 2025-09-2620:27 You can authenticate a handle via a file in ./well-known/ at the domain too, which is how bluesky does it for their default handles.
Wow, I always imagined Activitypub to be the better protocol and AT a cheap knock-off, but reading this article made me realize at is, actually, way better - primarily because multiple programs can access the same identity. This is really a great feature to have! This article was a real mind-opener for me.
Every one of these "How AT proto works" explainers focuses on data ownership—which is where ATProto shines—and glosses over data processing, where ATProto is decidedly weaker than ActivityPub. ATProto is built on a global, public view of the world, where all events are visible to a trusted global "AppServer" that can make all of the decisions for you—how to create your feed, who can see who's posts, etc—all of those decisions have to be made by a trusted intermediary. ActivityPub is more like RSS or email—your local server only has to manage the feeds you subscribe to, and your inbox is directly built from all of the posts you have access to. People you subscribe to send you your posts, and you don't have to process them at all.
This is why Bluesky could never have "private likes" in the same way Twitter or ActivityPub does—every AppView needs to track the like counts of every post in the network manually. It's a huge hassle! I just don't see this architecture winning out in the long term, when compared to the AP feed-subscription architecture.
Actually, this was how AP was originally designed as well—it was just that the most popular early implementations took shortcuts to remove that functionality to fit them into their existing architecture. This is a direct consequence of the fact that the biggest AP implementations when it was initially adopted were descendants of older OStatus social networks, and not built to be "ActivityPub-native" from the ground up.primarily because multiple programs can access the same identityBy frumiousirc 2025-09-2711:34 > This is why Bluesky could never have "private likes" in the same way Twitter or ActivityPub does
I didn't know "private likes" even existed, but if atproto includes public key encryption, I could publish a record containing a "like" that I have encrypted with the "liked" user's public key. Only that user would know what the record contained. Though, the fact that the encrypted message exists and had a cleartext "@name" is itself informative to adversaries. Concealing that level of info would require other measures.
By QuantumFunnel 2025-09-2710:28 Private likes are the only way forward on social media if we're to finally decouple free speech from the vindictive outrage mob feedback loop
Wow thanks for the valuable info. Would you recommend, for people who wants to add AP to their existing username/password application?
We are currently working on something based on https://fedify.dev
Would you consider that can provide more complete AP functionality?
By 1dom 2025-09-277:48 I mess around with fedify a lot, it's great. It's fun to integrate with existing websites.
I've thought a lot about ATProto and integrating it in similar ways. I'd love to have a look at what you're doing and how. The struggle I have is that I think the ATProto repos have a fairly strong cryptographic structure compared to AP
If someone requests an object over AP, that object contents can come from anywhere easily, and can be signed easy. So for me, when someone requests an activitypub object of one of my notes via fedify, it just reads the truth from my markdown note files and returns it. If I edit my markdown files, it's no real issue, the next request gets the latest version of that markdown (there's some signing nuances in places, but it's generally straightforward)
With ATProto PDS and repositories use things like Merkle Search Trees and other things which I assume means the backend data needs to be a lot more... consistent. Like the data has to live in the PDS, and that has to become the source of truth to maintain the merkle structures, including updates.
But with AP via fedify, it feels super easy and nice for my source of truth to be whatever backend store I like (markdown notes).
I've done enough with crypto to see the benefits provided by the transparent verifiable history of merkle like structures, but honestly, this is social media not cash: I don't care if someone wants to subtly change something to manage how they come across with their own social media. In that respect, I feel the ATProto repositories overcomplicate things a bit.
The AT vs AP issue is full of nuance. Our community has gone back and forth on this: https://github.com/bevyengine/bevy/discussions/18302
By t_mann 2025-09-2711:18 Interesting discussion, and good points highlighted about Bluesky's did model that means you essentially don't own your identity either (in typical scenarios and when it will likely matter most). That takes a big chunk out of the "host your own data" narrative.
One point I disagree on that's also mentioned in the replies: I don't think a global state should be seen as necessary or even desirable. Sure, it helps people who optimize for clicks/likes/attention as a business model But that shouldn't be the only concern. Having some degree of uncertainty around the global state can help reinforce a healthy skepticism towards what you're seeing in general. The 'correct' global number of upvotes on a post, or the majority of what has been said about a subject might still be manipulated to the point of being essentially fake. Optimizing for virality is not desirable if you think of the platform as a public good. Think about what it has done for the centralized platforms, and the consequences it's had in the real world.
> We should pick a platform that is federated, where you have ownership and autonomy over your identity and your audience. Social media should not be own-able by a single group or person. Social media is serious business. It ties directly to human rights and business outcomes. It shouldn't be in anyone else's control but yours.
I agree, but why not also apply the same logic to the other two communication platforms you are using (Discord and GitHub)?
By styanax 2025-09-2710:38 > I agree, but why not also apply the same logic to the other two communication platforms you are using (Discord and GitHub)?
Aside, this infuriates me - "here's our open source project/website, join our Discord!" (even Lemmy instances). sigh
By the_gipsy 2025-09-2620:32 Really nice analysis, thank you.
By doctorpangloss 2025-09-2621:493 reply This is not meant as a criticism at all, I like Bevy. Are you familiar with the Mr. Beast PowerPoint that said:
> Your goal here is to make the best YOUTUBE videos possible. That’s the number one goal of this production company. It’s not to make the best produced videos. Not to make the funniest videos. Not to make the best looking videos. Not the highest quality videos.. It’s to make the best YOUTUBE videos possible.
When I glance at the Bevy discussion link you shared, my reaction is:
> Your goal here is to make the best GITHUB OPEN SOURCE game engine possible. It's not to make the most performant game engine. Not to make the game engine that powers the best games. Not to make the best looking graphics in a game engine. Not the highest quality game engine or game editing experience. It's to make the best GITHUB OPEN SOURCE game engine.
By CaptainOfCoit 2025-09-270:121 reply > Your goal here is to make the best GITHUB OPEN SOURCE game engine possible.
That sounds awful if applied to Bevy, and seems you misunderstand what "Mr. Beast" is trying to say.
They're not saying make the best game engine, but make the game engine that would do best by GitHub-popular metrics, which is absolutely the wrong way to go.
I hope they continue to simply make the best game engine available, as before, and ignore useful metrics or focusing on where it's hosted.
By debugnik 2025-09-278:16 They didn't misunderstand, they're calling out Bevy's priorities.
Bevy is still incomplete as an engine. AFAIK there's only one commercially successful game made with it, Tiny Glade, and it doesn't even use Bevy's renderer but a custom one.
Yet the Bevy developers distract the project with essays and debates about the politics of their federated social media presence. You don't need that to build a game engine, but you do to build a "GITHUB OPEN SOURCE" game engine. I don't think there's anything inherently wrong with it, but that's clearly the focus here.
If your goal is to be viral and not care about the quality, then maybe following Mr. Beast's advice might make sense. If you'd rather risk popularity by trying to what you think will actually be better without knowing whether it will end up being viral, it makes sense probably to take anything he says with a grain of salt.
By doctorpangloss 2025-09-271:152 reply I guess my point is, writing 3,000 words on social media choices isn't going to make the game engine any better. But I can see how it is really important to the community and developers, which is to say, it's really important if the product is not a game engine but An Open Source (Esoteric) Game Engine Hosted On GitHub. Do you see what I am saying? That is the difference between making the best videos and making the best YOUTUBE videos. Mr. Beast isn't confusing, he's capitalizing the important part of what he is trying to say!
I fully understand what you're saying; I just don't agree with it. For starters, people can be complex and have more than one goal. The effect of making an open source project isn't necessarily just the utility of the project itself, and if some of those other potential effects are desired, the best way to do things won't necessarily be the same as if there's only one output that someone cares about.
For another thing, even if there aren't any other specific effects that are desired, there still might be some that are specifically not wanted, and avoiding those might be important. Mr. Beast is a exactly the type of example that demonstrates this point; by focusing on making the "best" YouTube content as measured purely by popularity, he's done all sort of things that someone might very understandably want to avoid. I agree that he's not confusing, but that's not the issue with him. He's extremely transparent in how little he cares about whether what he does actually helps anyone other than himself (or if he hurts other people in the process of helping himself). I suspect this is quite different from the mentality of most open source developers, who are putting in personal time and effort towards contributing to something that realistically has little likelihood of direct personal benefits for those involved. What you're perceiving as a lack of focus comes across to me as having the humility and thoughtfulness to try to look at the big picture and understand one's actions in the context of a larger environment that isn't improved in the long term by pursuing a single narrow goal to the exclusion of literally everything else.
By doctorpangloss 2025-09-274:161 reply Okay… Unity and Unreal have a lot less focus than Bevy, but are much better game engines. They will be shipping more great games every day than Bevy will in the next year, including beloved meaningful ones, like Silksong and Indiecute and Cuddlygame or whatever. And hardly anyone there, like most big corpo employees, is directly benefitted from the better games, they get paid the same amount of money, but the rub is also, everyone I know working at Unity and Epic is really sincere and loves games.
Of course I understand these are different things. Bevy is not at all competing with Unity.
Because Bevy is trying to be best GITHUB OPEN SOURCE game engine. I’m just trying to be a little jocular about how… you know, I didn’t say unfocused, but surely it seems a little silly to write 3000 words in response to a community worried about which open source social media federation protocols to adopt. That giant thread IS the product, it makes perfect sense from the POV that Bevy is trying to be the best OPEN SOURCE GITHUB GAME ENGINE, in the same way that Mr Beast is making the best YOUTUBE videos or Egyptology professors are making the best EGYPTOLOGY writing or painters are making the best PERSONALLY MEANINGFUL FINE ART or whatever. I like Bevy!
By swiftcoder 2025-09-277:30 > Okay… Unity and Unreal have a lot less focus than Bevy
Unity and Unreal also have billions of dollars in funding
By curious_ralts 2025-09-275:53 One could argue the opposite, let's take bevy as an example: more popularity could bring in more contributors or more funding which would hopefully result in making a better engine. The same could apply to Mr. Beast videos (more views translate to more money which translate to better production and staff which translate to more or better videos) but the goals are inherently different (maximizing profit which rewards quantity over quality)
By cropcirclbureau 2025-09-2623:171 reply Community drama has always been the achilles heel of large, open-source projects which are volunteer driven. Focus on community is critical to delivering this, especially when your product relies on mind share.
By debugnik 2025-09-278:42 In my experience, focus on community is how you get community drama in the first place.
By danabramov 2025-09-2618:111 reply Thanks! I’m glad it’s clicking. The comparisons with AP are always frustrating for this reason as it doesn’t try to do anything similar in scope.
By psnehanshu 2025-09-2620:431 reply imo ActivityPub sounds better than ATProto, hence people assume the former is superior. This is a branding issue.
By danabramov 2025-09-2622:43 Yea maybe! I think at:// is an even stronger brand in a sense though. Actually makes sense as something browsers may support one day, “at://alice.com” makes sense at “stuff at alice dot com”, “authenticated transfer” is a decent acronym, “atmosphere” for the ecosystem is just great (and wasn’t even coined by the team).
By verdverm 2025-09-2618:10 You'd probably like this article too, same ideas from the distributed engineer perspective
By paulryanrogers 2025-09-2618:431 reply Does that mean there is a centralized identity service?
By steveklabnik 2025-09-2618:461 reply You have two choices of identity service: did:plc, which is, and did:web, which is not.
In theory additional dids could come into existence too, those are just the two that blueksy supports at the moment.
By danabramov 2025-09-2618:521 reply That’s correct. PLC is being split into an independent entity but that is ongoing: https://docs.bsky.app/blog/plc-directory-org
It’s worth noting that PLC can’t fake your data because each edit is recursively signed. So you can verify a chain of updates. However, PLC can in theory deny you service or ignore your updates.
it's def not doing that right now lol, more than half the ops are adversarial and still accepted (the vast majority contain invalid contents)
By psionides 2025-09-2622:15 Yeah, there are tens of thousands of records referencing a PDS with a certain… controversial president's name in the hostname, which doesn't actually exist at all.
Also someone from Nostr made a tool that let you upload image files and encode them (split into parts) into plc directory records…
By viraptor 2025-09-274:28 > primarily because multiple programs can access the same identity
Why do you think that's different in ActivityPub? As far as I know there's nothing preventing (for example) Mastodon and Pixelfed using the same identity.
By analogpixel 2025-09-2619:021 reply [dead]
So email threads but on a web page, and filtered by subscription instead of senders/receivers. Clever.
How can I add this to my website?
How do you facilitate discovery? IE, what if I want to know about replies people have made without subscribing to their /social page?
By dragonwriter 2025-09-2620:021 reply Responding to the proposal (which is unjustly flagged to death, even if I agree that it isn’t a good idea):
> I came up with a solution that eliminates centralized control, trolls, advertising, and really all forms of harassment, and it doesn't even require a special server.
If it behaved as you describe (only followers see top-level updates and only followers of every person i the chain see replies; which I don’t think the concrete features you describe actually support, but I’ll get to that next), then it also eliminates the thing that makes social media work for both audiences and the people looking for audiences—there is zero discoverability, you can’t even encounter people through conversations.
Of course, with public outgoing feeds where visibility limits are a decision of the viewer’s client (to which all the visibility-deciding work of a server is outsourced, to avoid having a dedicated social server and just rely on regular web pages), it can’t be guaranteed to work that way. It can work that way for a viewer who wants to see that restrictive of a view, but that doesn’t prevent other people from having a more expansive view.
You can choose what you see, but not who can see your stuff or who can engage with it (if you have a client that behaves in the described restrictive manner, you won’t see engagement from people you don’t follow, but they can engage and others with a permissive client can see that engagement.)
By analogpixel 2025-09-2620:24 > there is zero discoverability, you can’t even encounter people through conversations.
based on the spam and harassment on most social sites, I'd call this a feature.
If you read something interesting you can email the person with your thoughts , and if they find it interesting they'll follow you. If you are a troll, they'll delete your message and they don't need to use their platform to support your comments. If everyone used this system, trolls wouldn't have a platform anymore.
Here is a great example of discoverability without comments : https://herman.bearblog.dev/misc-updates/
Herman from bear blog posted about a topic, a bunch of people emailed him their thoughts, and he created a follow up post with the best of those thoughts listed out.
This system definitely won't work for people that have FOMO, or need validation through votes on their comments.
By analogpixel 2025-09-2620:191 reply > How do you facilitate discovery? IE, what if I want to know about replies people have made without subscribing to their /social page?
That's what makes this system so great, you don't see what other people you don't even know say, and you should be ok with that. Don't look for validation from the trolls on the internet. Reading what random people you don't know say is how you get spam and harassment.
> How can I add this to my website?
currently this is a thought experiment, but if anyone wants to work on it, let me know, my contact info is on the post.
Also, this wasn't meant as "the solution" to the problem, more just maybe we should be looking for small solutions that don't require a huge amount of infrastructure to run.
By BrenBarn 2025-09-274:16 > That's what makes this system so great, you don't see what other people you don't even know say
But how do you get started? Are you saying you only look at blogs of people who you've met in real life and who told you their blog URL? Even that is unrealistic because lots of blogs link to other blogs. Why should I be okay with following a link from one blog post to another blog post but not okay with seeing a comment on a blog post?
