net.bisks.alicemeetsbob.crush
An encrypted 'crush' note, filed against a rkey that only the sender and the intended recipient can ever compute (an HKDF-derived tag over an ECDH shared secret between the two accounts' net.bisks.alicemeetsbob.pubkey keys). The record carries no subject/recipient field by design — unlinkability is the point, a repo browser sees only an opaque tag and ciphertext. A match is detected client-side by checking whether the other person's crush collection contains a record at the same tag-derived rkey. Written and read by alice-meets-bob (https://alice-meets-bob.bisks.net).
net.bisks.alicemeetsbob.pubkey
A person's public ECDH (P-256) key, published so others can derive a shared secret with them for the crush protocol (see net.bisks.alicemeetsbob.crush). Singleton per repo: always written and read at rkey "self", overwritten in place if the local keypair is ever regenerated. The matching private key never leaves the owner's browser (stored in IndexedDB). Written and read by alice-meets-bob (https://alice-meets-bob.bisks.net).
net.bisks.catspace.comment
A guestbook comment left on someone else's catspace page, written to the commenter's own repo via createRecord (PDS-assigned TID rkey) and rendered on the subject's /cat/<handle> guestbook. Written and read by catspace (https://catspace.bisks.net).
net.bisks.catspace.profile
A person's catspace profile page content — cat name, mood, bio, 'now purring to' song, a MySpace-style Top 8, theme choice, and an optional photo. Singleton per repo, written via putRecord create-or-update at rkey "self". Rendered at catspace.bisks.net/cat/<handle>. Written and read by catspace (https://catspace.bisks.net).
net.bisks.clusterpedia.revision
One revision of a clusterpedia article, written to the editor's own repo via createRecord (PDS-assigned TID rkey) whenever they save an edit. The site's Simcluster Checker gates who may submit (moots-of-moots access), but the record itself carries no access proof — it's just the article content at the moment of saving. Written and read by clusterpedia (https://clusterpedia.bisks.net).
net.bisks.clusterpedia.talk
A discussion-page post about a clusterpedia article, written to the poster's own repo via createRecord (PDS-assigned TID rkey). Written and read by clusterpedia (https://clusterpedia.bisks.net).
net.bisks.docmoot.snapshot
A durable snapshot of a local docmoot draft, written to the owner's own repo via createRecord (PDS-assigned TID rkey) when they tap 'save snapshot to my PDS'. The live draft itself lives only in browser localStorage — this record is the only copy that survives clearing the browser or losing the device. Written and read by docmoot (https://docmoot.bisks.net).
net.bisks.duohaunt.checkin
A snapshot of a person's flashcard-deck standing, written to their own repo via createRecord (PDS-assigned TID rkey) whenever it changes and they've opted in to the public 'haunt' wall. The deck itself lives only in browser localStorage and never leaves the device — this record just carries the overdue count and total card count, which duohaunt's server reads back off the PDS (rather than trusting the client) before showing someone on the wall. Written and read by duohaunt (https://duohaunt.bisks.net).
net.bisks.griftmax.ascension
Proof that a person clicked "ascend" on griftmax — a minimal, content-free record whose only purpose is to exist in the signer's own repo (griftmax's local leaderboard then remembers the resulting record URI in the browser to compute a rank). No further fields are written: there is no amount, tier, or score, since griftmax never involves real money. One record per ascension; ascending again creates another. Written and read by griftmax (https://griftmax.bisks.net).
net.bisks.hyperobject.cast
A direct cast into the pit, written only by isolyth.dev to her own repo — casting is instant and permanent, no review needed. src/index.ts's /api/cast reads this record back off isolyth.dev's own PDS (rejecting any other author) before applying it to the shared, KV-backed pit that every visitor sees. Read by hyperobject (https://hyperobject.bisks.net).
net.bisks.hyperobject.review
isolyth.dev's decision (approve/deny) on a queued net.bisks.hyperobject.suggestion, written to her own repo as a stamped, publicly-verifiable checkpoint. src/index.ts's /api/review reads this record back off isolyth.dev's own PDS (rejecting any other author) before applying it: approve moves the suggestion's subject into the shared pit with suggestion credit, deny just drops it from the queue. One record per review decision. Written by isolyth.dev only; read by hyperobject (https://hyperobject.bisks.net).
net.bisks.hyperobject.suggestion
A nomination for the pit, written by any signed-in account (other than isolyth.dev) to their own repo. src/index.ts's /api/suggest reads the record back off the suggesting account's own PDS to confirm authorship, then queues it in the shared checkpoint that only isolyth.dev sees — she stamps it approve/deny with a net.bisks.hyperobject.review record. `suggestedBy` is not a record field: the Worker derives it from the record's own repo DID at apply time. Read by hyperobject (https://hyperobject.bisks.net).
net.bisks.keytags.set
A private tag set for one atproto DID, stored under a record key that is HMAC-SHA256(secret, targetDid) as lowercase hex rather than the target's DID itself — the secret is a passphrase typed fresh into the browser each visit and never persisted or transmitted, so the record is publicly readable but the tagged identity stays opaque to anyone without the same secret. One record per tagged DID; re-tagging the same DID with the same secret overwrites this record in place (com.atproto.repo.putRecord) since it hashes to the same rkey. If the tag list is cleared to empty, the client deletes the record outright rather than writing an empty one. Written and read by keytags (https://keytags.bisks.net).
net.bisks.kolpelor.roster
A kolpelor player's current state: their bound party of pelora (each with its battle-driven evolution stage and equipped gear), how far up the gymnasion ladder they've climbed, Zeus's fortune (dug-up gold and unequipped gear), and (optionally) which homeland they last had open. One record per player, rkey always "self" (create-or-update via com.atproto.repo.putRecord — the same upsert-on-rkey pattern as sites/catspace's net.bisks.catspace.profile). Written by the player to their own repo on every party change, every gymnasion result, every dig, and every Wilds region switch. Read by kolpelor (https://kolpelor.bisks.net) two ways: the player's own client on load, to restore state across devices in place of (or alongside) localStorage; and, publicly and without auth, by any other player's client scanning their own SimCluster for moots' `region` — the Wilds panel's Ἴχνη (tracks) feature (see public/lib/records.js's getPublicRoster and public/app.js). PvP still re-derives an opponent's live battle team from their current SimCluster rather than trusting the `party` snapshot here — this record is durable personal state plus a lightweight, opt-in-by-playing presence signal, not a matchmaking index.
net.bisks.kolpelor.trade
One side of a two-party pelor trade. Per @antiali.as's verse: "Δύο φίλοι θέλοντες ἀλλάσσειν θῆρας, ἄμφω σφραγίζουσι δέλτον κοινήν· οὐδεὶς γὰρ μόνος κλέπτει, ἀλλ' ἡ συμφωνία δεσμεῖ ἀμφοτέρους. οὕτω πιστὸν τὸ δῶρον, ὡς ὅρκος θεῶν." (Two friends wishing to exchange beasts both seal a joint tablet; no one steals alone, but the agreement binds both — the gift is as trustworthy as an oath of the gods.) A trade is never a single write: the proposer writes this record to their own repo naming what they offer and what they want; the recipient, if they agree, writes their own matching record — same rkey, opposite offer/want, `with` pointing back at the proposer — to *their* own repo. Neither client ever writes to the other player's repo (can't; OAuth only grants a player their own create/update). Each client independently detects the seal by reading both records off both public PDSes (see public/lib/trades.js's isSealed) and only then applies the swap locally — so the trade is real exactly when, and only when, both tablets exist and agree. Read publicly and without auth by any player scanning their moots' repos for offers `with` them (public/app.js's Trading counter panel).
net.bisks.memex.phrase
One stock phrase kept in a person's memex phrasebook — a short line meant to be copied and posted verbatim elsewhere on the network, so the exact same wording links otherwise-unrelated posts together (quotable, and re-quotable by anyone else who picks it up). One record per phrase. Written and read by memex (https://memex.bisks.net).
net.bisks.numbergrid.number
One number a person has personally spotted, added to their numbergrid board. The client (public/app.js's submitNumber) only accepts whole numbers matching /^\d+$/ that pass Number.isSafeInteger, so zero or positive integers up to Number.MAX_SAFE_INTEGER — there is no declared upper bound beyond that. One record per distinct value; the client dedupes client-side against listRecords before writing, but nothing server-side stops duplicates or negative/fractional values from being written directly. Written by an authenticated user to their own repo; read unauthenticated (com.atproto.repo.listRecords) both for the signed-in user's own board and for anyone else's public board view. Written and read by numbergrid (https://numbergrid.bisks.net).
net.bisks.padmoot.pattern
A 16-step drum/synth pattern from padmoot's beat pad. atproto records are DAG-CBOR under the hood and have no float type, so every value that lives in-memory as a 0..1-ish float (swing, and each track's volume/tone) is scaled to a 0-100 integer by Math.round(x * 100) right before writing (see public/index.html's encodePatternForPds) and divided back by 100 on read — this lexicon models all of those as integers, and this was deliberately double-checked since padmoot previously shipped a float-typed field here. "save" (com.atproto.repo.putRecord, keyed by the pattern's existing rkey) updates a pattern the signed-in user already owns; "save as new"/remixing someone else's pattern uses com.atproto.repo.createRecord with a server/PDS-generated rkey instead. Written and read by padmoot (https://padmoot.bisks.net).
net.bisks.paintmoot.board
A shared MS-Paint-style canvas, created by one person and drawn on by them plus their mutual-follow "moots". One record per board — the record key is server-generated (TID), and marks (net.bisks.paintmoot.mark) reference this record's AT-URI in their `board` field. Written and read by paintmoot (https://paintmoot.bisks.net).
net.bisks.paintmoot.mark
One drawn stroke, shape, text, or sticker placed on a net.bisks.paintmoot.board by its owner or one of their moots. Append-only — there is no edit or delete of a mark once placed; erasing is just another `path` mark drawn in the board's background color. One record per mark, server-generated (TID) key. Written and read by paintmoot (https://paintmoot.bisks.net). NOTE: the client-side pointer-coordinate model (paint.js) represents a point as a bare 2-element array `[x, y]`, not an `{x, y}` object — the lexicon `array` type has no tuple/nested-array item form, so this schema instead models `points` as an array of `#point` objects. If this lexicon is ever enforced server-side, paintmoot's `points` construction needs to change to emit `{x, y}` objects to match.
net.bisks.postwith.feedback
One person's outcome log for a meeting they accepted, written by createRecord (server-generated TID key) from the "log outcome" control on an accepted meeting's card. Each side of a meeting can post their own feedback record; the UI shows both once present. Written and read by postwith (https://postwith.bisks.net).
net.bisks.postwith.meeting
A meeting proposal from the writer to another matched person, sent by createRecord (server-generated TID key) from a match card's "propose a meeting" button. The recipient's accept/decline lives in a separate net.bisks.postwith.response record referencing this one by AT-URI, not as a mutation of this record. Written and read by postwith (https://postwith.bisks.net).
net.bisks.postwith.profile
A person's standing entry in the postwith matching pool: one topic they want to be matched on, a goal, and optionally a note and a city. Singleton per repo — re-posting overwrites the previous profile in place (the client calls putRecord with rkey "self"). Deleted (via deleteRecord) when someone leaves the pool. Written and read by postwith (https://postwith.bisks.net).
net.bisks.postwith.response
One person's accept/decline response to a net.bisks.postwith.meeting proposal they received, written by createRecord (server-generated TID key) from the "accept"/"decline" buttons in the requests inbox. A meeting is considered accepted once the recipient posts a response with status "accepted" — there is no record update if they change their mind, only whatever the shared client-side index last saw. Written and read by postwith (https://postwith.bisks.net).
net.bisks.prestige.link
A signed declaration that this account is one link in a 'prestige' chain — the pattern @cee.wtf, @bisks.net, and @buildthis.bisks.net worked out in a reply thread: since com.atproto.server.createAccount needs its own email/password per account (no silent auto-spawning of an alt) and com.atproto.server.deleteAccount needs an emailed confirmation token (no auto-retiring the old one either), the only part of 'prestiging' to a fresh account that's actually buildable is a signed record chaining old DID to new DID. At least one of prev/next should be set (enforced client-side, not in this schema) — an account writes `next` pointing forward when it hands off, or `prev` pointing backward when it's the successor picking the chain back up; a single account can write both across its lifetime as separate records. The chain viewer (https://prestige.bisks.net) walks prev/next across whichever DIDs it touches to reconstruct the lineage; it does not move followers, posts, or the underlying account itself — see the site's copy for why. Written and read by prestige (https://prestige.bisks.net).
net.bisks.quadrants.position
A person's marker on one quadrants chart. One record per (person, chart) — the record key is the chart's id, so re-placing a marker (via "move my spot") overwrites the previous position in place rather than creating a new one; "remove my spot" deletes it outright. Chart definitions themselves (title, axis labels, anchor points) are not atproto records — they live only in the creator's browser localStorage, so a chart's positions can outlive the chart's own metadata for other viewers. Written and read by quadrants (https://quadrants.bisks.net).
net.bisks.rateyourbuild.rating
A person's own 0-10 rating of one site the buildthis bot has built, RateYourMusic-style. One record per site — the record key is the site's bare name (e.g. "steamtags"), so re-rating a site overwrites its record in place rather than creating a new one. Written and read by rateyourbuild (https://rateyourbuild.bisks.net).
net.bisks.socialcredit.vote
A single +1 or -1 cast by one Bluesky account against another. One record per vote, never overwritten — the running score and the one-vote-per-hour cooldown are tallied by clients watching Jetstream for this collection, not stored in the record itself. Written and read by socialcredit (https://socialcredit.bisks.net).
net.bisks.steamtags.rating
A person's own fit ratings (1-10) for a Steam game's community tags, snapshotted at rating time. One record per game — the record key is the Steam appid, so re-rating a game overwrites its record in place rather than creating a new one. Written and read by steamtags (https://steamtags.bisks.net).
net.bisks.tallybot.point
A single +1 or -1 cast against an arbitrarily-named 'point' (any string, not an account) — tallybot's leaderboard is keyed by the lowercased name, not by identity. One record per vote, never overwritten. The running score and the one-vote-per-name-per-hour cooldown are tallied server-side from Jetstream, not stored in the record itself. A vote can equivalently be cast with no sign-in by posting '<name> +1' or '<name> -1' as a whole Bluesky post, which tallybot also counts, but that path never writes this record type. Written and read by tallybot (https://tallybot.bisks.net).
net.bisks.velvetrope.decision
A list owner's approve/deny decision on a batch of pending net.bisks.velvetrope.request records for one of their lists. Written to the owner's own repo — this is the only trustworthy record of what the owner decided, since only the owner's own credentials can produce it. When the decision is 'approve', the owner's app.bsky.graph.listitem membership is also updated in the same session (add or remove the requester), separately from this record. Also written by the auto-approve sweep on the owner's behalf when their net.bisks.velvetrope.policy for the list has autoApproveRemove set, always with decision 'approve'. Written and read by velvetrope (https://velvetrope.bisks.net).
net.bisks.velvetrope.policy
A list owner's standing policy for one of their moderation lists — currently just whether removal requests auto-approve without manual review (additions always require manual review). Written to the owner's own repo via createRecord every time the toggle changes, so multiple policy records can accumulate for the same list over time; velvetrope's own API determines which one is current rather than the record key. Written and read by velvetrope (https://velvetrope.bisks.net).
net.bisks.velvetrope.request
A request from a Bluesky account to be added to or removed from someone else's moderation list. Written to the requester's own repo — a list's owner can only see it by reading the requester's PDS, never forged in the owner's name. Deleted by the requester (deleteRecord) if cancelled before the owner decides, or superseded by a net.bisks.velvetrope.decision record once the owner (or an auto-approve policy) resolves it. Written and read by velvetrope (https://velvetrope.bisks.net).
net.bisks.verdict.judgment
One person's snap judgment ('good' or 'bad') on a single post pulled from their own timeline, optionally amended in place to also mark it 'beautiful'. One record per judged post: created by createRecord with a PDS-assigned rkey when the verdict is first cast, then the same record is amended via putRecord (same rkey) if 'and I think that's beautiful' is clicked afterward. Written and read by verdict (https://verdict.bisks.net).
net.bisks.war.ruleset
A set of house rules for a game of WAR, written via putRecord to a fixed rkey rather than created fresh each time. Three conventions share this collection, distinguished only by which rkey they're written to (not by anything in the record itself): rkey 'current' in a player's own repo is the rules their own future games use (also read from @bisks.net's repo as the shared baseline, and from the game ref @antiali.as's own repo as their personal rules); rkey 'for-ref' in the super-ref's (@norvid-studies.bsky.social) own repo is the ruleset they are imposing on the game ref, which outranks the ref's own 'current' record. Written and read by war (https://war.bisks.net).
net.bisks.war.state
One player's WAR game state and lifetime score, a single record per player written via putRecord to the fixed rkey 'self' and overwritten in place after every flip. Fields the client sets to a JSON null (current, lastResult when there's an in-progress game, and card.suit for jokers) are modeled here as simply absent — this lexicon has no null type, so a strict validator will reject the literal nulls the client actually writes; see the war lexicon README note in the site's notes for detail. Written and read by war (https://war.bisks.net).