Abstract
The AT Protocol ecosystem has grown rapidly since federation opened in February 2024, reaching over 30 million accounts and spawning a developer community building everything from microblogging clients to event management to recipe sharing. Yet the ecosystem's growth has been overwhelmingly at the application layer — apps that use ATProto's existing Lexicon schemas or define narrow, single-purpose schemas for specific features.
What remains absent is protocol-layer infrastructure for creative authorship — the schemas that would allow any application to create persistent worlds, track characters and their actions, manage music catalogs and sample lineage, run competitions that produce verifiable history, trace creative works to their origins, and ensure that every contribution carries permanent attribution.
This paper argues that this gap should be filled at the protocol layer — as a set of open, shared Lexicon schemas — rather than at the application layer, where fragmentation and lock-in are the predictable outcomes. It surveys what exists in the ecosystem today, identifies the specific gap, explains why the gap matters, and introduces the Ptah Protocol as a concrete proposal for filling it.
1. The ATProto Ecosystem in 2026
ATProto's architecture separates identity, data storage, and application logic. Users own their data in personal repositories on Personal Data Servers (PDSs). Applications — called AppViews — index and serve that data for specific purposes. Schemas — called Lexicons — define the shape of records. Multiple applications can read the same records and produce different experiences.
This architecture has produced a growing ecosystem of applications:
Microblogging and social: Bluesky (the reference application), Frontpage (link aggregation), Whitewind and Leaflet (long-form writing), Flashes (photo sharing), and numerous alternative clients.
Events and RSVPs: Smoke Signal, built by Nick Gerakines, defines event and RSVP schemas now governed by the Lexicon Community — an independent body that ensures communal ownership of shared schemas.
Location data: The ATProto Community Fund's second funded project, backed by Skyseed, is building standardized location schemas under the community.lexicon.location.* namespace.
Infrastructure: Blacksky operates a complete independent ATProto stack including a PDS, relay, and moderation services, built in Rust. Multiple projects are building independent relays, AppViews, and tooling.
What all of these share is that they are either applications built on existing schemas or narrow-purpose schemas for specific features. Events. Locations. Recipes. Posts. Each solves one problem well.
2. The Gap: No Protocol Layer for Creative Authorship
No one in the ATProto ecosystem has defined a protocol layer — a set of open Lexicon schemas that any application can read and any builder can use — for the following unified set of capabilities:
- Persistent worlds with defined governance, intellectual property models, and rendering metadata
- Characters that exist inside worlds, with identity that separates the inhabitant from the user controlling them
- Templates — shared identity types that multiple characters can embody, with policies governing who can create instances
- Actions that constitute the heartbeat of a world — things that happen, attributed to characters, timestamped and permanent
- Events with structured formats, participants, stakes, results, and verifiable witnesses
- Logs — accumulated history that traces back through source references to the actions and events that generated it
- Origins with attribution chains that track every hand a piece of creative work passes through
- Locations that nest infinitely inside worlds, giving events and actions an address where history accumulates
- Collections that bundle works together — albums, anthologies, seasons, curated sets
- Traces that track lineage between works — covers, remixes, adaptations, samples, sequels
- Usage terms and permissions — what’s allowed, where, for how long, and under what conditions
- Versions that track edit history within a work — from draft to published to revised
These capabilities are related. A world needs characters. Characters take actions. Actions feed into events. Events generate logs. Origins trace attribution chains. Traces record creative lineage. Collections bundle works. Usage governs rights. The system is interconnected — and that interconnection is precisely why it should be defined as a protocol, not as a collection of unrelated app features.
What exists adjacent to this gap
Smoke Signal handles events and RSVPs. It does not handle worlds, characters, narrative history, or creative attribution. Its event schema is purpose-built for real-world gatherings, not for competitive events inside fictional or competitive worlds. Smoke Signal is an important precedent — it proves that non-microblogging Lexicons can thrive on ATProto — but it occupies a different space.
ProtoShards is a conceptual exploration by developer Kevin Hoffman, published as a blog post in September 2025. It imagines decentralized gaming on ATProto using custom Lexicons for realm locations, NPCs, ledger entries, and player inventories. ProtoShards demonstrates that the idea of game-like worlds on ATProto is imaginable, but it remains a single developer's prototype — not an open protocol, not published to the network, not designed for multi-application interoperability, and not unified with creative attribution, lineage, or rights.
The Lexicon Community governs shared schemas through an independent steering committee. This is a governance model, not a world-building protocol. It is relevant because it demonstrates how communally-owned schemas can work on ATProto — and because any world-building protocol should be designed with the possibility of eventual communal governance in mind.
What does not exist
Nobody has published a set of Lexicon schemas that unify world-building, creative attribution, lineage tracking, usage rights, and version history into a single interoperable protocol layer. The gap is not in any one of these capabilities — it is in their unification as a coherent protocol that any ATProto application can build on.
3. Why This Should Be a Protocol, Not an App
The ATProto ecosystem's own history demonstrates why.
When Bluesky launched, long-form writing was an obvious use case, but no one defined a shared Lexicon for it early. Multiple developers built competing blog platforms with incompatible schemas. The result: fragmentation. A post on Whitewind cannot be rendered by Leaflet's AppView. Content is siloed by application, not portable across the ecosystem. This is the exact problem ATProto was designed to prevent — and it happened because the schema layer was left to individual apps rather than defined as shared infrastructure.
By contrast, Smoke Signal's event schemas are now governed by the Lexicon Community. Any application that reads community.lexicon.event.* records can render events. The data is portable. The ecosystem benefits.
Creative authorship infrastructure is more complex than events and RSVPs. It involves interconnected record types with cross-references, governance models, intellectual property considerations, attribution chains, lineage tracking, and usage rights. If this complexity is left to individual applications to define, the fragmentation will be worse than what happened with long-form writing — because the record types reference each other. A character defined in one app’s schema cannot participate in events defined by another app’s schema. A sample traced in one system cannot be verified by another. The interconnection breaks at the boundary.
Defining this at the protocol layer means:
- Any AppView can index creative records. A literary world-building client, a music catalog manager, a competitive gaming platform, and a tabletop RPG campaign manager can all read the same underlying records.
- Creative attribution is portable. A character, a song credit, or a contribution created in one application carries its authorship record into any other application that reads the schema.
- History is verifiable across applications. Log entries trace back to source actions and events regardless of which client was used to create them.
- The ecosystem avoids premature lock-in. No single application owns the creative authorship primitive. Builders choose the best client for their needs, and their data comes with them.
4. The Ptah Protocol — A Concrete Proposal
The Ptah Protocol defines fifteen Lexicon record types plus a shared definitions file under the world.ptah.* namespace. Production schemas are published and live on the ATProto network. The protocol is MIT/Apache-2.0 dual-licensed.
The fifteen record types — World, Character, Template, Action, Event, Log, Origin, Location, Collection, Cadence, Trace, Usage, Version, Flax, and Defs — are designed as a minimal, extensible set that covers the full lifecycle of a creative work: creation, inhabitation, action, competition, history, attribution, geography, curation, lineage, temporal orchestration, rights, and versioning.
Design principles
Attribution is infrastructure, not metadata. Every record carries a permanent, immutable link to its creator. Authorship travels with every object.
The protocol records; clients render. The schemas define the data. How that data is displayed belongs to the rendering layer. Multiple clients can read the same records and produce meaningfully different world experiences.
Open by default. All categorical fields use knownValues (extensible) rather than enum (closed). New action types, event formats, governance modes, and location categories can be added without breaking the schema.
Minimal required fields. Each record requires only who created it, what world it belongs to, when it was created, and what it's called. Everything else is optional. This makes the schema usable for a literary world with rich descriptions and a competitive card game with minimal metadata.
What makes this different from ProtoShards
ProtoShards imagines game-specific records (inventories, ledger entries, quest completions). The Ptah Protocol defines creative authorship infrastructure — records that work for music catalogs, film franchises, literary worlds, competitive card games, tabletop RPG campaigns, and anything else that involves creative works with attribution and lineage. The protocol is genre-agnostic and media-agnostic. It does not assume gaming. It does not assume fiction. It assumes that creative works exist, people contribute to them, history accumulates, and authorship matters.
What makes this different from building an app
The Ptah Protocol does not include an AppView, a client, or a rendering layer. It is pure schema — the shared foundation that any application can build on. The first AppView, the first client, and the first rendering experience will be built as applications that consume these schemas. But the schemas themselves are infrastructure, not product.
5. Demonstrated Viability
The protocol has been pressure-tested against four complete example worlds spanning different genres and use cases:
- RENAISSANCE — music, original IP. Tests attribution chains with 100+ contributors, sample lineage across decades, and the full Origin/Trace/Usage record stack.
- The Marvel Cinematic Universe — franchise, shared universe. Tests Template/Character splits, cross-film event records, phase-level Collections, and comic-to-film Traces.
- Blacksky Spades — competitive tournament, original IP. Tests structured competition with brackets, scoring, witnesses, and season records.
- The Shattered Reach — tabletop RPG campaign, collaborative commons. Tests Game Master/player dynamics, character progression, and campaign journals as logs.
All four worlds are expressed using the same fifteen record types without modification. The schema holds music catalogs, film franchises, competitive card games, and collaborative tabletop RPG campaigns.
Seven adversarial failure modes have been tested, including log wars, malicious contributors, action floods, and canon override attempts. The schema survived all seven. Three external review processes confirmed the design.
Additionally, the protocol's rendering viability has been demonstrated through four simultaneous Flask AppViews reading the same live ATProto records from the Sister + Midnite original IP world — an afrofuturist apocalyptic western novella published as the protocol's first complete world seed. The four clients produce: a literary ePaper journal, a Substack-style publication platform, a post-apocalyptic newspaper, and a children's book reader. One world. Four windows. All real.
6. Ecosystem Alignment
The Ptah Protocol is designed to complement, not compete with, existing ATProto ecosystem infrastructure:
- Smoke Signal handles real-world events and RSVPs. The Ptah Protocol handles in-world competitive events. The two could interoperate — an in-world tournament could be announced via Smoke Signal — but they serve different purposes.
- Location data schemas define real-world geography. Ptah Location records define narrative geography inside worlds. Cross-referencing is possible but not required.
- Blacksky operates the PDS that hosts the protocol's identity and schemas. The Ptah Protocol's design philosophy — community-operated, open, culturally specific — aligns with Blacksky's infrastructure values.
- The Lexicon Community provides a governance model for communally-owned schemas. The Ptah Protocol is currently originator-governed but designed with the possibility of eventual communal governance — the same trajectory Smoke Signal's schemas followed.
7. What Comes Next
Production schemas are published and live on the ATProto network under the world.ptah.* namespace. All fifteen record types are resolvable on the network.
Near-term work focuses on AppView architecture — a namespace-scoped indexer for world.ptah.* records — and the Distribution API that enables rendering clients generating revenue from Ptah worlds to automatically distribute to the full attribution chain. The rendering proof is complete. The payment layer is next.
The protocol is open. The schemas are published. The gap is documented. The question is not whether world infrastructure belongs on the open social web — it is whether the ATProto community builds it together as shared infrastructure, or lets it fragment across incompatible applications.