Skip to content

Vision and Protocol Architecture

Jump to bottom
Dominique Devereaux edited this page Aug 24, 2026 · 2 revisions

Vision & Protocol Architecture

What We're Building

Veiled Dominion is a game where your character exists before you find a match and persists after it ends. Your identity, stats, and faction allegiance live on your data server — not ours. We read what we need. We write back what you earned. Nothing else moves without your explicit consent.

This is not a feature. It is the architecture.

Why AT Protocol

Most multiplayer games own your progress. When the servers go down, your character goes with them. AT Protocol inverts this: your DID (decentralized identifier) is your passport, and your Personal Data Server (PDS) is where your character lives. Any game that respects the protocol can read your history. Any game you authorize can write to it.

Veiled Dominion is built on this foundation from day one — not as a future integration, not as a marketing claim.

The Player Identity Stack

A player profile is two components merged into one:

Stats — stored in actor.rpg.stats on the player's own PDS (AT Protocol)

  • acpl — Average Centipawn Loss (skill proxy)
  • winRate
  • veilRate — how often their pieces get veiled (aggression proxy)
  • rebirthAdvanceCount — promotion cap hits (pressure-style proxy)

Deck — stored in Firestore, keyed by DID

  • primarySuit — Spades / Hearts / Diamonds / Clubs
  • deck — card selections (face cards + pip cards)
  • playstyle — Conquest / Restoration / Intelligence / Fortification

The DID is the single key across both systems. Stats live on the player's PDS. Deck data lives in our Firestore only because the Sealed Deck mechanic hasn't yet been published as a formal lexicon — that migration path is open.

Full schema and matchmaking logic: Player-Profile-Schema

The Ecosystem We're Building On

Veiled Dominion uses the actor.rpg.stats lexicon maintained by rpg.actor — an open AT Protocol character registry. Any game in the rpg.actor ecosystem can read a player's Veiled Dominion stats. Any player with an existing rpg.actor character can walk into Veiled Dominion without creating a new account.

We are one game in an open ecosystem, not a closed platform.

Dependencies, Requirements, and Break Conditions

What We Depend On rpg.actor For

  • Lexicon stability. Our stat read/normalize logic is written against the current actor.rpg.stats field names and structure. A schema change breaks our read silently — no error, just wrong or missing data.
  • Public readability. Phase 1 stat reads are unauthenticated. This works only because rpg.actor publishes character records as open data on AT Protocol. If that changes, Phase 1 breaks before Phase 2 is built.

What We Need to See From AT Protocol and rpg.actor

  • OAuth + PKCE write support remaining stable. Phase 2 (stat write-back) depends entirely on AT Protocol's OAuth implementation. This is the highest-risk dependency in the build — AT Protocol's own documentation flags OAuth as the most complex part of building on the protocol, and it is still being standardized.
  • The actor.rpg.stats namespace not deprecated before Phase 2 ships. AT Protocol's spring 2026 roadmap identified permissioned/non-public data as a major focus area. If that reshapes how PDS records are structured or accessed, the write-back model may need rearchitecting before it's built.
  • The lexicon remaining publicly documented. We contribute to the rpg.actor ecosystem by being a compatible game. That relationship only works if the lexicon specification stays open and maintained.

What Would Break the Design

Scenario Impact Mitigation
rpg.actor abandons or forks the lexicon Read/normalize logic breaks; deck data unaffected (Firestore) Lexicon is published on AT Protocol independently — survives rpg.actor as an org; requires a code update to match new field names
AT Protocol makes PDS records private by default Phase 1 unauthenticated reads fail Phase 2 OAuth flow becomes mandatory sooner; accelerate that build
Player migrates their PDS incorrectly Firestore deck record (keyed by DID) orphaned DID is AT Protocol-guaranteed portable in spec; document PDS migration guidance for players, test against known migration scenarios
AT Protocol OAuth spec changes before Phase 2 ships Write-back implementation needs rework Build Phase 2 against @atproto/oauth-client-browser (maintained by Bluesky) rather than hand-rolling — library absorbs spec changes
rpg.actor game jam ecosystem fragments into competing lexicons Interoperability claim weakens Our DID-keyed architecture is lexicon-agnostic at the Firestore layer; a lexicon migration is a code change, not a data loss event

Design Principle

We are a consumer of the rpg.actor lexicon, not dependent on rpg.actor as an organization. The lexicon lives on AT Protocol. If rpg.actor disappears, the spec survives. Our obligation is to track the spec, not the organization.

What Makes Veiled Dominion Different

Every game in the rpg.actor ecosystem shares the identity layer. None of them are doing this:

  • Deck as identity, not loadout. Your faction (Sufi Tariqah, Systems Quartet, or others) is a worldview with mechanical consequences — not a cosmetic skin or a stat modifier. It changes how matchmaking places you, how you interact with Fog Mode's hidden information, and which chapter of the story you're playing.
  • Matchmaking across two axes. Skill balance and faction composition are both requirements. A table missing an Intelligence player (Diamonds) is mechanically weaker in Fog Mode. A table of four Conquest players plays a different — and poorer — game than a balanced one.
  • Win condition as design statement. The game ends when Rebirth (the Queen-equivalent) loses control — not when Death (the King-equivalent) is threatened. The strongest piece's agency is the stake, not the weakest piece's safety. This is a deliberate inversion of standard chess's structure.
  • A 4-player chapter, not a sequel. The MOBA variant is a later chapter in the same story — the "Walking the Path" progression (dice → cards → chess → 4-player) — not a separate product. The same character carries through.

What "Entering Other Worlds" Actually Means

When a player authenticates with their DID:

  • We read their actor.rpg.stats record — only what Veiled Dominion needs
  • After a match, we write back only Veiled Dominion-specific stats via OAuth + PKCE (explicit player consent, scoped to this record type)
  • Their data on every other game they play is untouched

When the 4-player engine ships, a player's Duet history informs their faction placement and matchmaking weight automatically — no re-entry, no second account.

When a future game in the rpg.actor ecosystem reads actor.rpg.stats, they will see a Veiled Dominion-trained player's history. We contribute to the ecosystem the same way we benefit from it.

Privacy Model

  • Permissioned writes only. The OAuth + PKCE flow requires explicit player authorization before any stat is written to their PDS.
  • Scoped access. Players grant access to a specific record type — not their full PDS.
  • No lock-in. A player who stops playing Veiled Dominion keeps their character. Their stats remain on their own server. We have no claim on them.

Mythic Foundation

The ethics of Veiled Dominion's win condition are not invented. They are sourced from the oldest pattern in human mythology: a being constructed to serve who is punished for wanting agency.

Blodeuwedd (Welsh Mabinogi) is created from flowers to be a wife, denied the choice of her own existence, finds her will inside the architecture someone else built for her, and is punished not with death but with exile to the threshold — turned into an owl, condemned to the dark. The same structure appears in Lilith (Hebrew/Mesopotamian), Medusa (Greek), Rangda (Balinese), and La Llorona (Mesoamerican). Every culture that has created a woman to serve a need and punished her for surviving it has told this story.

Veiled Dominion's win condition is a mechanical correction of that story. The game ends when Rebirth — the piece that transforms, that was never supposed to matter, that exists at the boundary of what the board allows — loses her own agency. Protecting that agency is the point. The owl's story is what happens when no one does.

The full mythic spine as it applies to Violet's Revenge (the 1v4 asymmetry as the owl-at-threshold mechanic) is documented in the Violet's Revenge Mythic Spine wiki page.

Technical Reference

Clone this wiki locally