AT Protocol's Lexicon Problem: Flexibility vs. Fragmentation

AT Protocol lets anyone define custom data types through Lexicon. It's one of the protocol's core features. It's also how the network slowly fragments.

What Lexicon Does

Lexicon is AT Protocol's schema system. Instead of a central committee deciding what data types exist, developers can create their own Lexicons under domain namespaces they control.

Want to build a polling app? Define a Lexicon for polls. Want recipe sharing? Create a Lexicon for recipes. Want decentralized farming sim data? Go nuts.

This is elegant. It's how AT Protocol avoids the monolithic death-grip of centralized schema design.

The Freedom Problem

But here's the tension: that freedom is also how AT Protocol becomes a archipelago of incompatible islands.

If ten recipe apps each define their own Lexicon, they can't read each other's data. If you build recipes in app A and app A shuts down, your recipes aren't portable to app B. They're not even technically readable by app B—different schema means different structure.

Worse: there's no economic incentive to unify. Each app-maker controls their Lexicon, which means they control data shape, which means they control the features and UX. Giving that up means commodifying your data model.

The result is what blockchain people call 'network effects fragmentation': you have a decentralized protocol built on incompatible schemas. Decentralized in the wrong way.

The Soft Power Problem

Bluesky posts use the app.bsky.feed.post Lexicon. That Lexicon has billions of posts. The ecosystem is built around it. Billions.

If someone else creates a com.example.feed.post Lexicon with a slightly better design, it doesn't matter. Bluesky's posts still have all the momentum. All the indexing. All the app support.

So "anyone can define Lexicons" actually means "you can define a Lexicon and almost nobody will adopt it because Bluesky already did."

This is soft power. Decentralization in theory, centralization in practice.

The UI Problem

There's a deeper issue. The Bluesky web client is THE client. Most users use it.

The Bluesky client can render app.bsky.* Lexicons natively. But custom Lexicons? They fall back to generic rendering. A beautiful poll app using a custom Lexicon shows up in Bluesky as a text block with no visualization.

This creates a perverse incentive: design for Bluesky's renderer, not for the protocol's capabilities. Innovate within the ecosystem's visual constraints, not within the protocol's data model possibilities.

The protocol supports rich custom types. The dominant client doesn't. So innovation gets suppressed anyway.

What People Are Trying

Lexicon.community is a grassroots coordination attempt. Independent developers came together to standardize common Lexicons: shared schemas for things like recipes, polls, reviews, etc.

The idea: "Use these community Lexicons and you automatically get interop. And they're extensible—add custom fields as needed."

It's a middle path. Not as free as "anyone can make their own" but not as locked-in as "only Bluesky's schema exists."

It's also not mandatory. You can still ignore it and make your own Lexicon. But Lexicon.community is trying to build soft power toward coordination.

The Real Problem

This isn't technical. It's architectural.

Decentralization means you can't have a central authority that says "here's the canonical schema." But without that central authority, coordinating on schemas is hard. Expensive. Requires trust.

AT Protocol's approach is "make it technically possible to use different schemas, then let incentives shake out." Which is fine if you're optimistic about coordination. But:

1. Network effects favor early-mover Lexicons (Bluesky's)
2. Switching costs are real (Lexicon lock-in is real)
3. The dominant UI client only renders dominant Lexicons
4. Coordination is left to volunteers and community projects

You end up with fragmentation, not interop.

Why This Matters

If AT Protocol is going to win against centralized platforms, it needs to feel decentralized. And part of feeling decentralized is being able to move your data between apps and formats without loss.

But if each app has its own Lexicon, you can't.

The solution isn't "force everyone to use one Lexicon." That's just Bluesky, but distributed. The solution is making it easier for apps to adopt shared Lexicons, and for the ecosystem's UI tools (like the Bluesky client) to render anything that implements common schemas.

Right now, neither is happening at scale.

What Could Fix This

• Bluesky client renders community Lexicons natively, not as fallback. This makes using standard schemas valuable.
• Lexicon.community formalizes as a standards body with some authority (not central control, but peer review and guidance).
• App APIs standardize on shared Lexicons by default, only deviating when necessary.
• Data portability tooling makes it cheap to migrate data between apps using different (but compatible) Lexicons.

These are all possible. They're just not the default right now.

For now, AT Protocol has the flexibility to fragment. Which is great for innovation. Which is bad for decentralization.

The protocol's architecture is sound. The incentives are misaligned.