The Politics Are in the Order of Implementation

I know this probably sounds like a crank complaint. An engineer hears a scheduling critique. A governance person hears a process complaint. A platform person hears “you should have done things differently” and gets defensive. Someone else hears criticism of a system that is, in obvious ways, still better than Twitter. Fine. Those are all intelligible reactions. They are also part of the problem, because the thing I am trying to point at only really becomes visible once you stop looking at each decision one at a time and look at the stack. That is usually where these systems hide their politics: not in any one outrageous move, but in the order things get built, normalized, and later explained.

ATProto’s spring roadmap is useful precisely because it is not scandalous. The public-data side is now described as “broadly complete.” Major changes to public-data synchronization are expected to move through the new IETF process. Meanwhile the next frontier is “permissioned data”: non-public data with explicit access control, with significant implementation and experimentation still ahead, and multiple teams already working on it in parallel. There is also a push to move more account-management functionality down into the PDS layer instead of making every app request those permissions or reimplement those flows itself. None of that is crazy. None of it even requires bad faith. The roadmap reads like a series of reasonable next steps, which is exactly why it matters. [1]

The single most important line, though, is not in the roadmap. It is in the charter. The ATP working group is scoped to public user data records and public synchronization. Transfer of non-public or limited-visibility data is explicitly out of scope. Not “for now.” Not “pending further discussion.” Out of scope. That is the boundary. The writeup is equally plain that the work is grounded in pre-standardization implementation and deployment experience. In other words, the formal process is being built around the already-legible public core while the more consequential new layer begins taking shape somewhere else, faster, through experimentation, code, integration pressure, and whatever conventions harden first because somebody shipped them and the network had to cope. [2]

That is the pattern. The politics are in the order of implementation.

I have been writing some version of this critique for long enough that being proven right by a protocol roadmap does not feel satisfying. It feels familiar. The annoying part is not that anyone is doing something obviously evil. The annoying part is that everyone involved can still sound reasonable while the result gets worse. Permissioned data does need experimentation before it can be standardized. Public sync probably does belong on slower, more formal rails once it stabilizes. Multiple teams building in parallel is healthier than one company dictating the whole future. Pulling account-management functions into the PDS is a sensible substrate move. All true. The problem is that these decisions do not arrive as a philosophical argument. They arrive as a calendar. And calendars have politics. [1]

A stack of individually reasonable sequencing decisions can produce opaque governance as an emergent property. That is the whole point. Nobody has to sit in a room and decide “we should build a system where public effects rest on increasingly non-public premises.” Nobody has to declare “the real governance venue should sit outside the place where legitimacy is later performed.” Nobody has to choose the stack as a political object. The stack emerges from parallel teams making locally rational choices under time pressure, while everybody talks about their own part in the clean, narrow language appropriate to their role. And then later, once the behavior has hardened, the system gets described as though it simply grew that way.

That is why I keep resisting the two lazy explanations people reach for. On one side: conspiracy. On the other: innocence. Either someone is plotting opaque governance, or everything is fine because every local decision is defensible. Neither reading is good enough. You do not need a conspiracy when you have a temporal structure that produces the same outcome. And “good intentions” is too weak a defense because good intentions do not cancel sequencing effects. They often just make people less likely to notice them. The sentence I keep coming back to is simpler than all the diagnostic jargon: the problem is not intent. It is sequencing.

Once you look at ATProto through that lens, the shape is hard to miss. The public substrate moves onto standards rails just as the less-public layer begins forming through implementation and adoption. The formal constitutional shell goes around the part of the system that is already legible enough to standardize. The frontier where new practical power will live is the part still being worked out through experiments, parallel implementations, and early integration. This is not some weird exception to how modern infrastructure works. It is almost normal now. Running code and market adoption decide more of the architecture than anyone wants to admit, and later a standards body arrives to narrow ambiguity, document behavior, and confer institutional legitimacy on the parts that have stopped moving quite so much. The IETF still matters. It just matters more as constitutional paperwork than as frontier architecture in cases like this. That is not a moral condemnation. It is a temporal description. [2]

And when commitment outruns verification, governance migrates to wherever decisions become irreversible first.

That is what all the heavier Δt language was trying to get at; that’s the line. The gap matters, yes. But the more useful claim is directional: power does not hover abstractly in the gap. It accumulates at the seam where things harden before they are fully contestable. In this case that means the seam between private or permissioned state and the user-visible application surface. The roadmap says permissioned data will require new protocol concepts, new sync mechanisms, new data flows, and updates across PDSes, SDKs, specs, and moderation tooling. That is a polite way of saying the new layer will not remain a hidden technical detail. It will translate into visible behavior, and the translation layer is where governance precedent gets set whether or not anyone chooses to call it that. [1]

This is the part people keep wanting the legitimacy narrative to solve by existing. There is a strong tendency in tech to think that once a standards body, governance process, or review channel appears, the hard political problem has somehow been domesticated. But standards bodies certify one kind of thing. They do not magically erase the temporal relationship between what shipped, what won adoption, what became too costly to unwind, and what later got written down in the approved vocabulary. The charter materials say this out loud in their own way: the ATP work is based on prior implementation and deployment experience, and proposed changes have to be weighed against deployed implementations. Again, nothing scandalous. Also not nothing. By the time the formal process arrives, a meaningful part of the architecture may already be sitting there in practice, pretending it grew naturally. [3]

The likely result is not total invisibility. It is worse in a more boring way. The public governance layer remains visible enough to matter. Public labels, public records, public sync, public effects: that part stays legible enough to sustain discourse and consequence. But the rationales feeding those effects become harder to inspect as permissioned data becomes a real protocol layer and moderation tooling adapts around it. The architecture starts producing visible consequences resting on invisible premises, with an official reason for why the asymmetry has to exist. That is exactly the kind of system that eventually learns to say, quite sincerely, you cannot see the evidence, but trust the process.

I am tired of that sentence. More specifically, I am tired of the technological conditions that keep manufacturing it. It always arrives dressed as reasonableness. It is usually spoken by people who are not lying in any ordinary sense. They are describing a real process. They are just describing it from inside a structure where the effective venue of decision has already shifted elsewhere. That is what makes this stuff so hard to talk about without sounding like a crank. Nothing is dramatic enough to trigger the scandal reflex. Nothing is cleanly centralized enough to give you a villain. Nobody is exactly wrong. And yet the resulting governance arrangement is still more obscure than the one people think they are legitimating.

That is the methodological problem here, and not just for ATProto. How do you describe the failure geometry of something that is only really visible from outside the implementation order, when almost everyone working on it is inside? How do you criticize a stack nobody decided, built by people making reasonable choices, without getting dragged into the stupid binary where either you are alleging sinister intent or you are supposed to shut up because every local step was defensible? I do not think there is a glamorous answer to that. I think there is just the work of pointing at the calendar and refusing to let people pretend it is neutral.

ATProto did not set out to build opaque governance. It set out to solve a series of real technical and social problems in a reasonable order. I believe that. I also think that order has politics, whether anyone enjoys hearing it or not. Because power does not need to be centralized to become obscure. It only needs to be exercised through layers that harden in practice before they harden in spec, law, or public understanding.

That is why this roadmap matters. Not because it reveals a hidden master plan. Because it shows, in plain language, how a system can become harder to audit without anyone having to make “auditability gets worse” as an explicit goal. That is the pattern. Same trick as ever. New paperwork.

And the politics are in the order of implementation.

[1] https://atproto.com/blog/2026-spring-roadmap

[2] https://datatracker.ietf.org/doc/charter-ietf-atp/

[3] https://datatracker.ietf.org/doc/charter-ietf-atp/writeup/