Repository navigation
id: investigate: cross-jurisdiction shared worlds and federation — residency semantics for multi-tenant Durable Objects #2284
Description
Follow-up B from the Durable Object jurisdiction investigation on #2061
(doc: doc/2026-10-29T11-43-02Z_investigation_do_jurisdiction_pinning/, §2).
Parent epic: #2056. Context: #2044 (§6 shared worlds, §7 bridge), #2059 (hot-world sharding).
The problem
A shared world is one Durable Object, and a Durable Object has one jurisdiction (eu, us or fedramp), fixed when the ID is created. Its writers do not share that jurisdiction: an eu-pinned user and a us-pinned user writing into the same world means one of them is writing outside their jurisdiction. The platform cannot fix this — it is a product decision.
Questions to answer
- Partition or consent? Either worlds are jurisdiction-partitioned (an
euworld and ausworld, no cross-participation, and the same world name resolves differently per jurisdiction — exactly as Durable Object names already do), or cross-jurisdiction participation is explicit, consented and disclosed. Both are defensible; the doc must pick one and say what it costs. - What does a world's participant list reveal? Even if content stays put, the DO holding the world learns which users participate. Is that metadata crossing a boundary?
- Blobs in a shared world. Content-addressed blobs follow the user's R2 jurisdiction bucket, but a world's participants share world content. Which bucket holds world blobs, and what happens when a user from the other jurisdiction reads them?
- The bridge. Native Iroh nodes are not jurisdiction-pinned at all. When a native node syncs with a hosted
euuser, what residency claim survives? - Federation and relay paths (id: investigate: multi-hop relay and P2P media paths — bridging peers, optional privacy relay, large-message chunking #2035, id: design: ID messaging/relay protocol v1 #2036): same question one layer down.
Acceptance
- Investigation doc under
doc/with a recommendation, not a menu. - The recommendation states what a privacy policy can honestly say afterwards.
- Follow-up design issues for the chosen path.
Acceptance criteria
- Investigation doc under doc/ answers all five questions in the body and picks ONE of partition-vs-consent with its cost stated (a recommendation, not a menu)
- The doc states what a privacy policy can honestly say afterwards
- Follow-up design issues filed for the chosen path
Activity
developing-today commentedon Oct 29, 2026
CODE-1142
dezren39 commentedon Oct 29, 2026
Intake review
Related: #2061 (§2), #2044 (§6/§7), #2059 (hot-world sharding), #2035/#2036 (bridge/federation), #2283/#2285 (siblings), epic #2056
Notes: Pure investigation/design question — the platform cannot fix the one-jurisdiction-per-DO constraint; this is a product decision with privacy-policy consequences.
Risks: Participant-list metadata leakage (Q2) is easy to overlook and may decide the partition question on its own.
Suggested approach: Answer Q2 and Q3 first — they constrain whether consent-based sharing is even coherent — then pick the model.
🤖 Agent note · filed
meta/enrichedapplied. Still-live check this pass: no merged PR or fix commit explicitly resolving this issue was found; where a queue triage task owns verification, it is named in the notes.dezren39 commentedon Nov 1, 2026
🤖 Agent note · picked up
dezren39 commentedon Nov 1, 2026
🤖 Agent note · done