Dark Mode — the Atlas drop door: registration admission + the three-rule table #85

Milestone: Dark Mode. Sibling to #71 (signed snapshot export + verify-on-ingest), #72 (the sneakernet drop-off), #73 (the offline Atlas frontend). Not yet deep — this issue serializes the intent so a cold context can pick it up; the rules below are the shape, not a settled spec.

The distinction from #72

#72 is peer↔peer snapshot exchange — everyone carries stale-but-signed snapshots and converges on newest-per-Atlas. This issue is the other door: how an Atlas admits a Tell's registration/listing in the first place. bin/register (tell repo) already emits the signed entry — id/name/url/scope/signer/reports, on a tell/<scope>/<id> branch that signs ownership (tell test [13]). Nothing yet tracks the Atlas-side rules that receive that entry and decide whether it lists, stays, or drops.

The drop door — the three-rule table (shape, to be refined)

When a listing arrives (or a de-listing, or a competing claim), the Atlas resolves it against a small table:

1. Freshness wins. The newest truthfully-signed word for a given (scope, id) is what the Atlas shows. Stale-but-once-true is tolerated (atlas CONSTITUTION.md "My record is one record, reachable or not") but never overrides fresher signed word.
2. A host quell de-lists, but loses to freshness. A host-authored quell (anecdote composer/quell.mjs — the de-listing kind, not the terminal author quell) removes a listing; a later, fresher signed listing from the same owner supersedes the quell. De-listing is a claim like any other, arbitrated by the same freshness rule (supersededBy).
3. Two-Atlas archive-policy conflict. The same Tell may drop into multiple Atlases whose archive/retention policies disagree. Ownership is the tiebreaker: the tell/<scope>/<id> signer owns its own entry; an Atlas applies its own retention to its own copy and never rewrites another Atlas's record. "Neighbors, not a graph" — one hop, no transitive authority.

Why now

It's the missing half of the going-public story: #71/#72 move snapshots between carriers, but a Tell "going live on an Atlas" is this admission gesture, and the freshness/quell/ownership rules are what keep a public, promiscuously-shared index from being poisoned by a stale or hostile drop.

Home

The true home is likely atlas.anecdote.channel (not in session scope yet); filed here in the Atlas-design series so it survives a context switch. Migrate/cross-link when the atlas repo is in play.

See also

• Dark Mode 1 — signed Atlas snapshot export + verify-on-ingest ("real at one time") #71 — signed snapshot export + verify-on-ingest ("real at one time"): the signatures + stamped dates this rests on.
• Dark Mode 2 — the sneakernet: stacked snapshot drop-off, cascading push #72 — the sneakernet drop-off: the exchange side, distinct from admission.
• Dark Mode 3 — the Atlas offline frontend: your local copy, everything public, the matcher running for you #73 — the offline Atlas frontend: the consumer of the admitted listings.
• anecdote composer/quell.mjs — isAuthorQuell (terminal) vs host quell (de-listing), supersededBy (freshness arbitration).
• tell bin/register — the signed registration entry this door receives.