docs(plans): Lody session sharing v2, a design exploration

[pythonlearner1025]

What and why

A design exploration for Lody session sharing v2, on top of the shipped-dark v1 in plans/LODY-SHARING.md. It is meant to be argued with, not merged as a decision: the asks are org-wide shares with a Google-Docs-shaped dialog, org and public links, org admins reading every session whether or not they hold a seat, non-members pulled in as guests, instant scope changes and revocation, and fork or move of a session between workspaces.

What the document does:

• Section 1 lists every research source read (BlitzOS plans and code, the vendored Lody sources, Lody's docs, the Loro protocol) and what each settled, so any claim can be traced back.
• Section 3 measures what Lody actually offers: a multiplayer-ready document model (dual authoring, message queue lease, same-machine fork, presence vocabulary) and no per-session ACL, no read-only, no sync-layer auth, no move.
• Section 4 restates the asks as constraints and corrects the ones that collide with the measured system.
• Sections 5 and 6 make the one architecture decision v2 cannot dodge: box-only (M0), box-as-truth plus a non-authoritative control-plane catalog and opt-in snapshots (M1, recommended), or a live hub (M2). Section 6 is M1 in depth: components, the five data flows, trust and authority, staleness, failure modes, security, cost, and the questions a different answer would reopen.
• Sections 7 to 14 are the mechanisms: data model, guest reach and claim computation, the viewer surface, the editor ceiling, revocation, links, the transfer bundle for fork and move, attribution and audit.
• Sections 15 to 17 are phases, decisions needed, and upstream PR opportunities.
• Appendix A draws all three architectures and the shared flows in ASCII with a tradeoff table.

Two v1 findings surfaced during the research and are recorded as corrections to make in phase A:

• a level change from rw to ro upserts the row but never drains, so a live socket keeps write until the tab reconnects (core/session-shares.ts:247-256);
• the daemon pushes the whole workspace presence snapshot to every data-plane connection and the bridge forwards it untouched, so a grantee receives the status of every session on the owner's box, granted or not (local-loro-data-plane-server.ts:239-240, :397-400).

No code changes. Nothing is built.

Checklist

• npm run typecheck passes — not run; docs-only change under plans/, which no gate reads
• npm run lint:gate passes — same
• npm test passes — same
• lint-baseline.json was not raised
• Any new payload crossing a runtime boundary has fixtures — none added; the document names the corpora a build would need
• Go changes — none
• Docs updated — this is the doc

🤖 Generated with Claude Code