The amount of chatter from ATmosphere developers around an “everything app” has me thinking of an article from almost exactly 10 years ago.
Back in 2016, Joel Monegro at USV wrote about “fat protocols”. An excerpt from my note about it from a few years later:
His thesis was that decentralized protocols were aiming to be fatter than HTTP or SMTP, meaning, they wanted to capture more value than the applications built on top.
I never got the fat protocol argument - at least from the point of view that it seems like something one can only apply retroactively, since it’s about where value ends up being captured.
[Crypto] protocols always want to capture value, so we could argue that they always want to end up being as fat as possible, but that doesn’t mean that they’ll succeed, or that some app on top won’t capture more.
One reason why the fat protocol thesis didn’t sit well with me was personal preference — I prefer the Unix approach of small, atomic building blocks you can chain, to the Big Monolithic Application path that Windows and others were following for a while there. A fat protocol seemed monolithic, and monoliths tend to be easier to topple.
I suspect that’s also a reason why I’m attracted to ATProto — it feels like small Lego content blocks are the exact right fit for it.
Now, Monegro was focused on blockchain protocols at the time, but there is one thing he mentioned that is in stark contrast to the ATProto space:
the market cap of the protocol always grows faster than the combined value of the applications built on top, since the success of the application layer drives further speculation at the protocol layer.
ATProto inverts this. The protocol defines how data gets stored and spread around the network, and little beyond that — it encodes no logic whatsoever, so all decision making happens on the applications themselves. There is no market cap to measure, no value capture at the protocol layer by design.
This is application primacy: unlike smart contracts, the protocol refuses to be the place where things happen.
Given this lack of value capture at the protocol layer, any economic value will need to be generated at the application layer (we can squint and see infrastructure projects as a class of developer-focused application).
Which brings us back to the question: will we see an ATmospheric “everything app”?
I don’t currently think so.
I’ve got thoughts on that which I’ll need to post from a keyboard later, around inversion of control.
ATProto can potentially be an “everything” protocol (once we have permissioned data), but said IoC means we are more likely to see an app proliferation instead of WeChat’s single entry point.
— Ricardo J. Méndez (@ricardo.bsky.social) May 10, 2026 at 11:58 AM
Consider the characteristics that allow for this application primacy:
- It is mostly a green field at this particular stage;
- Application developers are starting both from a similar point, and with similar resources;
- All data is public, under the user’s control, and the only potential leverage a team could have is lexicon control (something I noted on Cuckoo begets Offshoot); however…
- Even if a Lexicon creator were to turn antagonistic to the community, migrating data should be trivial (something already demonstrated in a more benign context by Leaflet providing a migration path for Whtwnd content, after the latter was abandoned).
If the protocol can’t encode logic or capture value, application developers can’t entrench through protocol-level lock-in. The leverage that exists in most platform plays simply isn’t available here.
If you are a developer, you can think of ATProto applications as injected dependencies in a dependency injection pattern: instead of the application being the host into which services are injected, the application itself is what gets injected into the user’s data flow. Users have their data; they only need something with the right shape to handle it.
It doesn’t matter to them what that something is, though, as long as it accepts what data the user wants to give it, and sends out what the user expects.
(There’s something incredibly empowering for users there that I don’t imagine most of them will understand at first — but with enough examples, the penny will drop.)
This means the only way for value capture is out-execution. The conditions won’t allow you to cheat. Being first gives you an edge, being smarter about execution is what will keep you ahead.
I expect developers will be able to out-execute only by focusing on a particular, thinly defined vertical where they have an edge. That is not an “everything app”.
This is not just another instance of Ricardo hoarsely soapboxing the Focus Gospel. The way the investment landscape around ATProto is looking — which is a post of its own — I don’t expect a lot of teams will get to raise a fat round with which to go nuts. That means bootstrapping, or making do with a sensible angel round; and surviving under those conditions will require singleminded, laser-guided focus.
Now, if in order to make an “everything app” you need not only distribution but a deep war chest that allows you to experiment and iterate while bringing in users, there is a prime candidate to do it: Bluesky PBC.
Bluesky PBC could go evil and try to centralize everything on their user front end, aiming to be an ATmospheric WeChat, the Big Fish followed by a wake of scavengers nibbling at its leftovers. That could work if they get some massive growth not only on the platform but on their mobile client, and come up with some applet standard, and figure out the UX, and the community adopts it instead of going for the open web, and people like the way it works, and businesses decide to build on it. All of those line up, then maybe it could become an “everything app”. That’s a lot of conditionals, though.
For now, I’m still betting on composable data being the future.
Composable, composable, composable, composable.
Composable, composable, composable, composable, composable, composable.
Composable, composable, composable, composable, composable, composable, composable, composable, composable, composable, composable, composable, composable, composable.
— Ricardo J. Méndez (@ricardo.bsky.social) May 11, 2026 at 11:04 AM
[image or embed]
(Christ that’s terrible alt-text)