Skycave · Vision & Experimental Direction

The Open Gaming Graphof the Atmosphere

Skycave should not merely integrate with AT Protocol. It has a credible shot at defining what gaming looks like as a native application category on the open social web — the layer where players, games, matches, rivalries, tournaments, and achievements connect.

4
boring lexicons to start
1
record publisher
1
external game
∞
views over shared facts
i

None of this is built yet. This is a direction, not a promise — a public vision and an experimental protocol path. The live Skycave product stays fast, opinionated, and centralized where centralization makes a better game. This page describes what could grow around it.

The Shift

From a game platform to a gaming graph

The unambitious framing is “a website where Bluesky users play browser games.” Even “the AT Protocol gaming platform” undersells it. The useful framing: Skycave becomes the layer that gives any game an identity, a record, a reputation, and a social context — without needing to run every game itself.

IDENTITY profiles · history · achievements COMPETITION matches · ratings · tournaments DISCOVERY feeds · challenges · social graph SKYCAVE NETWORK the shared gaming layer OPEN GAME LAYER Skycave game Indie game Community game
The bet: three durable pillars feed one shared layer, and the games hang off it — Skycave-built or not.

AT Protocol never defines “game,” “match,” “achievement,” or “tournament.” That gap is the opportunity — Skycave already lives all of them.

The Principle

Centralize execution. Decentralize the rest.

The mistake would be decentralizing 300 ms game moves out of ideology. Live engines, timers, anti-cheat, and WebSocket state stay on purpose-built Skycave infrastructure. The protocol carries the durable, interoperable facts — and only those.

Public AT data
  • completed results
  • achievements
  • public challenges
  • tournaments
  • game definitions
  • records & player stats
  • matchmaking requests
Private / permissioned
  • hidden card hands
  • private invitations
  • unrevealed choices
  • private leagues
  • moderation state
  • admin state
Real-time Skycave
  • WebSocket gameplay
  • timers
  • anti-cheat
  • authoritative engines
  • transient room state
  • short-lived actions

// This boundary is what keeps the architecture from becoming decentralization theatre.

Ownership vs Authority

The player owns the history; the referee certifies it

Durable gaming history should belong to the player’s AT identity — but a user must not be able to publish “I scored 999999” and have it count. The fix is to split ownership from authority: a trusted referee service publishes the canonical result; the player’s repository holds a signed receipt that points at it.

REFEREE SERVICE did:plc:skycave space.skycave.match.result winner · game · score engineVersion · completedAt space.skycave.playReceipt result: strong-ref → PLAYER REPO did:plc:alice publishes writes references
A signature proves “this DID published this record” — never “this result actually happened.” Competitive facts come from the referee, not the winner.
Building Blocks

What becomes portable

Once results are durable facts, the pieces Skycave already has stop being account-page features and start being objects other applications can read, index, and act on.

◈

Portable gaming profile

Not “who are you inside Skycave” but “who are you as a player across the Atmosphere” — history, titles, achievements, and bests, reconstructable from records another app can display.

⟨⟩

Skycave as an API for games

A developer shouldn’t rebuild identity, leaderboards, tournaments, and challenges. An SDK could hand them all of it — an open equivalent of Game Center, built on portable AT identities.

skycave.createMatch(...) → completeMatch(...)
⊞

Games published by anyone

A game definition points at its developer’s DID and its own launch URL. Skycave discovers, reviews, and lists it — without engineering every game itself.

space.skycave.game.definition
⚔

Challenges as objects

A challenge stops being a link and gains a lifecycle: created → accepted → match → result — discoverable across surfaces, resolvable into the same match.

space.skycave.challenge
♚

Portable tournaments

The Weekend Tournament becomes one consumer of a shared format. A Blacksky Summer Cup or a University Mancala Night can run on the same competition infrastructure and belong to its community.

space.skycave.tournament.*
✦

Open trophies

Achievements carry an issuer. Skycave today; a community or an external developer tomorrow. The profile becomes an open trophy cabinet with verifiable provenance.

space.skycave.achievementAward
≣

Alternative leaderboards

Skycave publishes reliable facts; anyone can interpret them — total wins, Elo, Blacksky-only, Nigerian players, August season, mutuals only. No single true ranking.

◎

Social-graph matchmaking

Not “who’s online” but “3 mutuals play Mancala,” “your rival is online,” “someone you follow wants a Connect 4 opponent.” A gaming lens over a graph that already exists.

space.skycave.matchmaking.request
►

Feeds as arcade lobbies

A custom feed turns a social post into a playable object: Ray scored 31 on Flag Rush → tap → you’re playing Flag Rush. The feed becomes part of the lobby.

The Lexicons

A small, experimental schema family

Not all at once. The first objective is to discover which concepts actually deserve durable, protocol-level representation — starting with four boring ones and letting the rest earn their place.

space.skycave.* — proposed family
# start here — the four that carry the thesis
space.skycave.game.definition
space.skycave.match.result
space.skycave.achievementAward
space.skycave.challenge

# candidates that must earn durability
space.skycave.match
space.skycave.playReceipt
space.skycave.tournament
space.skycave.tournament.entry
space.skycave.tournament.result
space.skycave.season
space.skycave.rating
space.skycave.rivalry
space.skycave.matchmaking.request
a conceivable Skycave Game SDK
const match = await skycave.createMatch({
  game: "com.someone.hex",
  players: [alice, bob]
})

await skycave.completeMatch({
  match,
  winner: alice,
  result: { ... }
})

// the referee certifies. the players own
// the receipt. another app can read both.
The Architecture

A safe migration path, not a rewrite

The production database stays authoritative through the whole experiment. An event outbox mirrors selected completed events onto the protocol — so independent views can be built without betting the live platform on an unproven design.

GAME ENGINE AUTHORITATIVE DB EVENT OUTBOX SKYCAVE API AT PUBLISHER mirror selected AT PROTOCOL AT INDEX SKYCAVE UI CAVEVIEW THIRD PARTY
The DB stays the source of truth; AT records mirror durable events. Two independent frontends can read the same verified history — one privileged, one not.
The Roadmap

Ordered around proofs, not features

Each phase exists to answer one question. If a phase’s proof fails, the thesis is revisited before anything expands. The sequence is the point.

Phase 0 · Boundary

Design the protocol boundary

Decide what becomes AT data. Define the referee/issuer trust model, namespace conventions, versioning, and correction semantics. Threat-model forged results. Ship nothing yet.

exit → who may publish a Skycave record, who may trust it, and how is it corrected?
Phase 1 · Four Lexicons

Mirror completed events

Definitions, validation, a feature-flagged record publisher, outbox integration. Mirror selected completed events only. Don’t touch production reads.

exit → a real match produces a valid, independently retrievable AT record.
Phase 2 · Independent Index

Index without DB access

A small app-specific index over the Skycave lexicons — built deliberately without access to production game tables.

exit → the index reconstructs a useful slice of a player’s history from records alone.
Phase 3 · Caveview

A second, ugly frontend

No production DB, no privileged APIs — reads only the independent index. Not meant to be beautiful. It’s an interoperability proof.

exit → two independent apps show the same verified history.
Phase 4 · Native Challenge

The first interactive object

created → accepted → expired → completed, linked to canonical matches.

exit → a challenge made on one surface resolves on another.
Phase 5 · Open Trophies

Issuer-signed achievements

Achievement + award records with issuer, subject, and evidence. A trophy cabinet sourced from indexed records.

exit → Skycave shows an award from a trusted non-core issuer.
Phase 6 · External Game

The most important test

Invite one outside developer to build a tiny game hosted outside Skycave, with a minimal SDK. The point is integration, not game quality.

exit → an external game produces trusted results in Skycave profiles. If it fails badly, revisit the thesis.
Phase 7 · Open Game Dock

Approved external games in discovery

Developer verification, trust levels, moderation, health checks, launch-URL and de-listing policy.

exit → several independent games participate without materially raising operational risk.
Phase 8 · Protocol Matchmaking

Discovery, not execution

Expiring LFG records + views (people you follow, community LFG, rival available). Rooms still run centrally.

exit → protocol discovery yields real completed matches without unacceptable spam.
Phase 9 · Portable Tournaments

Community-run competition

Tournament lexicons; selected communities host their own events on Skycave infrastructure.

exit → a third-party community runs a full tournament; players keep portable results.
Phase 10 · Seasons & AppViews

Many views, one fact set

Season records + enough reliable data that alternative ranking services can emerge.

exit → Skycave is no longer the only software that can produce useful views over its records.
Phase 11 · Agents

Only after the ecosystem is healthy

Caver as an AT identity; agent-capable game declarations; humans vs the Atmosphere. Not a distraction from the core network.

The Proofs

Five gates, in order

Proof 1

Can a completed game become a trustworthy AT record?

if no → stop
Proof 2

Can an independent index reconstruct useful history?

if no → weak story
Proof 3

Can a second frontend show it without privileged access?

if no → still closed
Proof 4

Can an external developer integrate a game?

if no → still a catalogue
Proof 5

Can a community run competition on top of it?

if yes → it’s infrastructure
Governance & Trust

An open graph creates problems a game site can postpone

These are product-architecture questions, not merely protocol ones — and they need answers before the graph opens, not after.

Result authority

Who may issue canonical results?

Developer trust

How does Skycave decide which third-party games are trustworthy?

Cheating

How are suspicious results marked, invalidated, or superseded?

Corrections

What happens when an authoritative result was wrong?

Removed games

Can old results stay valid after a game is de-listed?

Achievement issuers

Can anyone create achievements? Can Skycave distinguish verified awards?

Namespace evolution

How are lexicons versioned without breaking compatibility?

A signature only proves this DID published this record — never that the result happened. Trust must be explicit, and it has levels. Competitive facts should come from an authorized referee, not the winning player.

01player assertion
02game-developer assertion
03community-issued assertion
04trusted referee · Skycave-verified

// weakest → strongest. consumers choose the floor they’ll accept.

What This Is Not

Earn the architecture; don’t announce it

Until the proofs succeed, the project stays deliberately experimental — and it is never marketed as something it isn’t.

live match state on AT Protocol replacing the primary database migrating profiles fully onto AT data accepting untrusted external results an unrestricted game marketplace promising protocol stability a universal “gaming standard” claim tokenization / digital-ownership narratives a blockchain-style economy
Current product

Games for Bluesky, Blacksky, and beyond.

Emerging developer story

Build games for the social web without rebuilding identity, competition, and community.

Long-term protocol story

The open gaming graph of the Atmosphere.

The Bet
4 boring lexicons 1 record publisher 1 independent index 1 ugly second frontend 1 external game

Centralize execution.
Decentralize identity, durable history, interoperability, and discovery.

If those five pieces work, Skycave has demonstrated something much larger than AT login — an interoperable gaming network. The mindset stays honest: don’t announce that Skycave invented decentralized gaming. Prove another developer can participate first.