games.atmosphere.experience
Developers publish one record per experience to their own PDS. Portals index it and show it in the directory. The requires field declares what AT Protocol records a player must have in their PDS to be able to interact. Records should include a developer.did (an AT Protocol DID) rather than relying on a social handle.
Rule types
All rules in requires must pass as requisites for access.
All rules in includes are optional signals of additional utility.
record — player holds a specific record from a collectionfield — definition for relevant record fields in checkmatches — requisite states or compositions to satisfy conditionvouch — refferential approval records from validating authoritiesall / any / not — composition sub-rules
The vouch pattern
vouch reads from an authority repo (not the player's), and offers a method of referential approval. These are commonly other experiences that issue stats, items, or other elements that need to be verified from a source to validate the player's repo claims. Developers of experiences must design and discern their own reliances, and maintain assurance with authorities they authenticate with.
Example — Clown Wars
// This record lives on @clun's PDS at https://rpg.actor.
// Authority collections it draws from:
// at://did:plc:vgld2e4x2rfk3kzwfcwhxok4/equipment.rpg.give
// at://did:plc:vgld2e4x2rfk3kzwfcwhxok4/actor.rpg.master
{
"$type": "games.atmosphere.experience",
"name": "Clown Wars",
"tagline": "Hilarious Arena Combat",
"url": "https://clownwars.example.com",
"developer": { "did": "did:plc:vgld2e4x2rfk3kzwfcwhxok4", "name": "Clun" },
"requires": [
// Sprite: checked in the player's own repo.
// The player creates and owns this — no authority issues it.
// 'record' reads the player's PDS.
{
"check": "record",
"nsid": "actor.rpg.sprite",
"acquire": "https://rpg.actor"
},
// Clown shoes: checked in @clun's repo, not the player's.
// @clun must have issued an equipment.rpg.give naming this player as recipient.
// 'vouch' reads the authority's PDS — the player cannot write this themselves.
{
"check": "vouch",
"authority": "clun.rpg.actor",
"nsid": "equipment.rpg.give",
"playerField": "recipient",
"filters": [{ "field": "item", "op": "eq", "value": "clown_shoes" }]
},
// Cannon stats: also checked in @clun's repo.
// @clun must have registered a master record for this player under the clunscannon system.
// Same vouch pattern — authority-held, not self-issued.
{
"check": "vouch",
"authority": "clun.rpg.actor",
"nsid": "actor.rpg.master",
"playerField": "player",
"filters": [{ "field": "system", "op": "eq", "value": "clunscannon" }]
}
],
// Optional. Not a gate — if present in the player's own repo, the game uses it.
"includes": [
{
"nsid": "actor.rpg.stats",
"purpose": "DCC character sheet unlocks the Cleric of Saint-S\u00f4ulard variant class"
}
]
}
How this is evaluated
A portal resolves each requirement by reading AT Protocol repos directly — no API call to the developer, no central authority. The result is a pass or fail based entirely on what public records exist.
record — Query the player’s own repo for any record in actor.rpg.sprite. The player created this themselves. If it’s missing, the portal surfaces the acquire link. No authority is involved.vouch — Query @clun’s repo for a record in equipment.rpg.give where recipient matches the player’s DID and item is clown_shoes. This record lives on @clun’s PDS — only @clun can write it. The player’s own copy of the item is a claim; this is the proof.vouch — Query @clun’s repo for a record in actor.rpg.master where player matches the player’s DID and system is clunscannon. @clun registers who has a validated cannon score. A player cannot fabricate this registration.
The includes entry is never a gate. When the player has an actor.rpg.stats record in their own repo containing DCC data, the game can read it and unlock an extra class — but its absence doesn’t block entry.
A developer publishing one record like this is all that’s needed to participate in the network. Portals index it, read it, and resolve eligibility through the AT Protocol graph.
