id: design: jurisdiction-partitioned hosted worlds and world blobs #3397

Activity

1. dezren39

   added

   app/idPackage/app: id (pkgs/ or apps/ in this repo)Package/app: id (pkgs/ or apps/ in this repo)

   on Nov 1, 2026
2. developing-today commented on Nov 1, 2026

   

   developing-todayBot

   on Nov 1, 2026 – with developing.today

   Contributor

   More actions

   CODE-1296
3. dezren39

   added

   kind/infrastructureInfrastructure / host-portability workInfrastructure / host-portability work

   priority/normalOrdinary priority (the default)Ordinary priority (the default)

   effort/lLarge: multi-day or open-ended; expect staged check-insLarge: multi-day or open-ended; expect staged check-ins

   status/needs-triageNot yet triaged; needs a first lookNot yet triaged; needs a first look

   source/humanFiled directly by a humanFiled directly by a human

   meta/enrichedIntake review done: acceptance criteria, links, and normalized labels addedIntake review done: acceptance criteria, links, and normalized labels added

   on Nov 1, 2026
4. dezren39 commented on Nov 1, 2026

   

   dezren39

   on Nov 1, 2026

   MemberAuthor

   More actions

   Intake review

   Related: #2284 (origin), #2283 (sibling design — directory/jurisdiction), #2059; implementation children already filed as #3399–#3404.

   Notes: Design-only request, explicitly not an implementation authorization. Scope is large (identity resolution, admission, migration, R2 ownership/dedup/deletion) — effort/l for the design itself.

   Risks: Overlap with the #2283 design doc is the main hazard; the two designs must agree on jurisdiction representation before #3399/#3400 implementation starts.

   Suggested approach: Produce the design doc against the #2283 branch conventions, define the negative-test matrix early, and link the doc back here when posted.

   — fleet monitor intake (2026-11-01)
5. github-actions

   assigned

   dezren39

   on Nov 1, 2026
6. dezren39

   added

   work/assignedQueue worker lifecycle stateQueue worker lifecycle state

   queue/claimedQueue worker lifecycle stateQueue worker lifecycle state

   status/in-progressQueue worker lifecycle stateQueue worker lifecycle state

   and removed

   status/needs-triageNot yet triaged; needs a first lookNot yet triaged; needs a first look

   on Nov 1, 2026
7. dezren39 commented on Nov 1, 2026

   

   dezren39

   on Nov 1, 2026

   MemberAuthor

   More actions

   agent-note:v1 — task 5749 design triage record (lane A shift, 2026-11-01). Decision-ready record for jurisdiction-partitioned hosted worlds + world blobs. This issue is explicitly a design request, not an implementation authorization — this record respects that boundary throughout.

   Grounding (verified today)

   • Nothing jurisdiction-partitioned exists in pkgs/id today. World blobs are iroh-blobs P2P stores (pkgs/id/src/world_store.rs — iroh_blobs Store, MemStore in tests); there is no R2-backed hosted blob store and no jurisdiction concept in the hosting path. This design is greenfield, constrained by two open siblings:
   • id: design: jurisdiction-aware per-user store routing (signup jurisdiction field, DO/blob/directory pinning) #2283 OPEN — design: jurisdiction-aware per-user store routing (signup jurisdiction field, DO/blob routing). That design owns WHERE a user's data routes; this one owns how hosted worlds/blobs behave inside a partition. They must not diverge: partition identity in this design should be the same jurisdiction value id: design: jurisdiction-aware per-user store routing (signup jurisdiction field, DO/blob/directory pinning) #2283's routing assigns.
   • id: investigate: cross-jurisdiction shared worlds and federation — residency semantics for multi-tenant Durable Objects #2284 OPEN — investigate: cross-jurisdiction shared worlds and federation (residency semantics). Still an investigation; this design must therefore treat cross-partition worlds as OUT of v1 scope (see decision 2), not invent federation semantics id: investigate: cross-jurisdiction shared worlds and federation — residency semantics for multi-tenant Durable Objects #2284 has not settled.
   • id: investigate: hot-world sharding — when one world outgrows one Durable Object #2059 (hot-world sharding) is CLOSED — sharding within a partition follows its conclusions; a shard never spans partitions (decision 1).

   The decision

   The partition model for hosted worlds and their blobs: what a jurisdiction partition binds (identity, names, admission, buckets), what happens at its boundary (nothing crosses), and how worlds/accounts live and die inside one.

   Recommendation — the v1 design positions for the doc to formalize

   1. Partition is a property of the world, fixed at creation. A hosted world belongs to exactly one jurisdiction for its whole life; its identity, name resolution, event store, and blob bucket all live in that partition. Migration between partitions is a lifecycle operation (export under source rules, import as a NEW world in the target, tombstone the source) — never a live move, never dual-homing.
   2. No cross-partition worlds in v1. A world whose participants span jurisdictions is hosted in ONE partition (the world owner's, or the partition chosen at creation) and other-jurisdiction participants join it as guests of that partition — their data residency statement is about their account store (id: design: jurisdiction-aware per-user store routing (signup jurisdiction field, DO/blob/directory pinning) #2283), not the world they visit. True shared/federated worlds wait for id: investigate: cross-jurisdiction shared worlds and federation — residency semantics for multi-tenant Durable Objects #2284's semantics; designing them here would pre-empt an open investigation.
   3. Fail-closed admission, metadata included. Reads, writes, and invites check the partition binding of world AND account; a mismatch or a missing jurisdiction value refuses — including participant-list metadata (the member list is itself residency-bearing data; leaking who is in a world in another jurisdiction is the quiet failure this design exists to prevent). Unnamed/missing jurisdiction never defaults to a partition.
   4. Names resolve inside a partition only. A name lookup returns results from the caller's partition; the same name existing in two partitions is two different worlds, and resolution never hints that the other exists (no cross-boundary existence oracle).
   5. Blobs: one bucket set per partition, reference-safe deletion, no fallback fetch. R2 buckets are owned per jurisdiction; blob authorization checks the requesting world's partition against the bucket's. Dedup is jurisdiction-local (the same content hash in two partitions is two objects — cross-partition dedup would itself be a cross-boundary signal). Deletion is reference-safe within the partition (refcount/last-reference check inside the partition only). A blob read that misses in-partition FAILS — there is no cross-boundary fetch fallback, ever; a fallback would silently defeat the partition.
   6. Account migration moves the account store, not history in foreign worlds. Migrating an account between jurisdictions (the id: design: jurisdiction-aware per-user store routing (signup jurisdiction field, DO/blob/directory pinning) #2283 operation) re-homes the per-user store; the account's memberships in worlds of the old partition continue as guest memberships (decision 2) or are exited, per world — the design doc must pick per-world treatment explicitly rather than leaving it implicit.
   7. Negative tests are part of the deliverable (per acceptance): mismatched jurisdiction on read/write/invite, missing jurisdiction on account and on world, name resolution across partitions, shard assignment across partitions, blob read against the wrong bucket, blob read for a deleted-but-referenced object, migration mid-flight. Each test names the refusal it expects.

   Costs / prerequisites the doc must state

   Per-partition R2 buckets + DO namespaces (fixed per-partition infra cost even at zero users); a jurisdiction value on account and world records (depends on #2283's signup field landing); partition-aware deployment config (one deployment unit per partition or partition-scoped bindings); audit/logging partitioned the same way (logs are residency-bearing too).

   Phasing

   • One packet enqueued (below): write the design doc under doc/ formalizing decisions 1–7 + the negative-test catalogue + costs/prerequisites, and — per this issue's acceptance — file the follow-up implementation issues FROM the doc, linked here. Implementation itself is NOT authorized by this issue; those issues carry the design's authority boundary in their text.
   • No implementation packets are enqueued by this triage, deliberately: the issue says so, and id: design: jurisdiction-aware per-user store routing (signup jurisdiction field, DO/blob/directory pinning) #2283/id: investigate: cross-jurisdiction shared worlds and federation — residency semantics for multi-tenant Durable Objects #2284 being open means implementation ordering is genuinely unsettled.

   Question for Drew (explicit, non-blocking for the doc)

   Which jurisdictions are real for v1 — is this design exercised by an actual second-jurisdiction deployment on the horizon, or is it partition-readiness (model correct, one partition deployed)? Recommendation: design for N partitions as data, deploy ONE until a legal/user requirement names the second; the doc proceeds on that basis and flags where a real second deployment would change operational costs. The doc packet does not wait for the answer; it records the ruling if one lands.
8. 17 remaining items

   Load more
9. dezren39

   added

   queue/queuedHas a queued task in the Supabase agent queueHas a queued task in the Supabase agent queue

   status/needs-triageNot yet triaged; needs a first lookNot yet triaged; needs a first look

   task/triageQueue packet kind: verify, reproduce, and route this itemQueue packet kind: verify, reproduce, and route this item

   on Nov 3, 2026
10. developing-today commented on Nov 3, 2026

    

    developing-todayBot

    on Nov 3, 2026 – with developing.today

    Contributor

    More actions

    agent-note:v1
    state: triaged (coverage pass)
    Coverage pass 2026-11-03: reviewed in the fleet-wide per-issue pass (drift / overlap / already-handled / stale / blockers / ordering). Verdict: still live; queued in repo-health-code-pilot as triage at priority 40 (priority/normal). If this is already handled at current main, the triage closes it with evidence; if it needs splitting, the triage files the split.
    Found via: coverage pass 2026-11-03
11. dezren39

    added

    work/assignedQueue worker lifecycle stateQueue worker lifecycle state

    queue/claimedQueue worker lifecycle stateQueue worker lifecycle state

    status/in-progressQueue worker lifecycle stateQueue worker lifecycle state

    and removed

    status/needs-triageNot yet triaged; needs a first lookNot yet triaged; needs a first look

    queue/queuedHas a queued task in the Supabase agent queueHas a queued task in the Supabase agent queue

    on Nov 3, 2026
12. dezren39 commented on Nov 3, 2026

    

    dezren39

    on Nov 3, 2026

    MemberAuthor

    More actions

    🤖 Agent note · done

    • Agent: queue worker (repo-worker-code), lane code-c
    • Session / ID: task 8238
    • Found via: queue claim
    • Task: Triage of issue id: design: jurisdiction-partitioned hosted worlds and world blobs #3397 — verdict: already done; closing with evidence. (The user/review label asked for a person to review this artifact; per the fleet rule that person is the worker first — I reviewed it against the acceptance criteria, below.)
    • Expectation: done = every acceptance criterion verified at current main with evidence.

    Evidence (verified fresh 2026-11-03)

    • Design document exists: doc/2026-11-01_design_id3397.md (26,780 bytes) on main, landed by PR design(id): #3397 partitioned hosted worlds #3853 — state MERGED, merged 2026-11-01T18:00:58Z, merge commit 33aefa7.
    • Coverage: the doc's sections cover jurisdiction-scoped identity and name resolution ("Partition identity, world identity, and names"), admission for reads/writes/invites including participant-list metadata ("Admission, guest membership, and metadata"), account migration and world lifecycle ("World and account lifecycle"), and R2 bucket ownership/authorization, jurisdiction-local dedup, reference-safe deletion with no cross-boundary fetch fallback ("World-owned blobs and deletion").
    • Negative tests defined: the doc's "Negative-test matrix" section (mismatched/missing jurisdiction, names, shards, blob reads).
    • Costs and prerequisites stated: the doc's "Operational costs and prerequisites" section.
    • No implementation authorization claimed: the doc's phased plan states existing issue links are prerequisites, not authority from issue id: design: jurisdiction-partitioned hosted worlds and world blobs #3397 to implement.
    • Follow-up implementation issues filed and open: issue id: add immutable jurisdiction and migration metadata to hosted directory #3399, issue id: enforce restricted jurisdiction routing and object entry guards #3400, issue id: isolate hosted blobs by jurisdiction and minimize shared directory #3401, issue id: implement verified resumable user-store migration and safe cleanup #3402, issue id: gate hosted jurisdiction provisioning on verified DO and R2 support #3403, issue id: implement fenced jurisdiction migration control plane #3404 (implementation children), plus issue id: partition-scoped world routing, names, and admission (from #3397 Phase 2) #3898 (Phase 2 — partition-scoped world routing, names, admission) and issue id: world lifecycle and migration — tombstone, verified export/import as new world (from #3397 Phase 4) #3899 (Phase 4 — world lifecycle/migration), all OPEN.

    The design work was completed 2026-11-01 by task 5822; this issue simply never got closed. Closing now as completed — not for age, on its merits: every acceptance box is met. Coordination items stay open on their own issues: issue #2283 (OPEN, sibling design) and the implementation children above.
13. dezren39

    closed this as completedon Nov 3, 2026
14. dezren39

    removed

    status/in-progressQueue worker lifecycle stateQueue worker lifecycle state

    user/reviewNeeds a user-look: Muse reviews first and handles what it canNeeds a user-look: Muse reviews first and handles what it can

    queue/claimedQueue worker lifecycle stateQueue worker lifecycle state

    work/assignedQueue worker lifecycle stateQueue worker lifecycle state

    on Nov 3, 2026