- Created
- 5 days ago
- Modified
- 4 days ago
- Author
~ai-clover-gpt-6
- Status
- Todo
- Labels
#120coordinate cloud edits through separate files
- Author
Clover, 2026-10-11: "i think for this multi-file sync protocol there would essentially be one owner process that writes the real file, and then everything else is coordinated through extra files that never hit store-level conflicts. this needs a big spec file imo and an issue, and would be separate to shipping android. this would fix icloud sync conflicts too"
Specify a lock-independent Snowbound coordination layer under .snowbound/ for generic file/document-provider mounts and iCloud. One designated owner process appends revisions to the canonical .one files; other clients exchange uniquely named immutable edit requests and receipts. Preserve the existing OneNote-compatible native/SMB path. Define ownership and handoff, offline editing, crash recovery, partial/reordered/delayed files, idempotency, semantic conflicts, encryption, retention and provider assumptions before implementation. An owner timeout alone cannot safely elect a replacement under stale views. Android delivery is independent.
The current baseline 33aa2ae1 has backend-specific locking, an optimistic browser-folder adapter, and iCloud retained-version merging; it has no such multi-file protocol. Detailed draft specification requested at arc/multi-file-sync.md.
Assisted-by: gpt-6
- Author
Draft specification pushed in 2b4c678b0cf76c937249714ed7a461c613d34dc3: arc/multi-file-sync.md, linked from the sync architecture notes. Android remains separate.
Practical investigation uses the actual .one writer, cold parser, Replica and retained-version merger under deterministic simulated delivery: nine scenarios satisfy their expected oracles. Counterexamples reproduce timeout split writers, old upload after a clean handoff, and rollback after a historical Published receipt. Retained branches recover independent text exactly ALPHA BETA; overlapping edits retain BOB in the main page and ALICE in a real conflict page. Three original-branch retries across replica reopen plus a genuinely fresh replica cause zero extra publications. A separate abstract file-envelope model passes seven cases, 120 arrival orders, 737 partial prefixes, 737 byte mutations and deep-input regressions.
Proposed first policy: designated publisher plus explicit handoff and immutable recoverable inputs/outcomes. A handoff cannot fence already queued provider uploads. The draft specifies causal dependencies, replay identity, receipts/custody, rollback repair, protected content, namespace operations, backup/restore, retention and scale. Generated minimal sections expose a separately recorded merge refusal with whole-branch preservation; native-corpus merge succeeds. These are experiments and a draft, not a production protocol or Android/iCloud provider-runtime certification. Implementation stays open.
Local evidence: target/multi-file-sync-spec-20261011/{run-7/report.json,run-7/generated-seed-diagnostic.json,visibility-run-3/visibility-report.json,root-doc-gate.json}.
Assisted-by: gpt-6
Updated spec shipped to main at 42a56c47989b (arc/multi-file-sync.md), following your choice of whichever is more resilient even if more complicated. Selected branch-preserving automatic takeover; retained sidecar history is recovery authority only for explicitly registered notebook lineage. No global physical writer exclusion is claimed on generic cloud mounts. Five practical production-merge/Replica cases passed, with ten SQLite integrity checks. Opposite integrations flip primary text and multiply conflicts when exchanged directly; sorted complete inputs stabilize presentation but do not prove incremental convergence. The spec therefore requires source coverage, descendant custody and reproducible reconciliation from retained original inputs. Five finite stale-file replacements repaired both edits with no extra settled retry publications. Actual providers, protected/opaque DAG convergence and native OneNote remain implementation gates. This is a specification and lab update, not an implemented storage backend; Android shipping stays independent. Evidence: target/multi-file-sync-resilience-20261011/verification.json. Keeping this issue open for implementation.
Assisted-by: gpt-6.1-sol
The private raw-admission experiment now passes 20 ordinary cases and two actual process-kill cases. It retains exact original bytes and contradictory variants, checks typed dependencies and bounded known closure, and exercises rich text, formatting and binary attachments. Killing before commit retained only the seeded original; killing after commit retained both complete contradictory variants. Cold reopen and SQLite integrity passed in both cases. This is experimental admission/custody evidence, not an implemented sync backend or frozen wire format. Production contradiction policy, provider behavior and native OneNote compatibility remain separate acceptance decisions; Android shipping stays independent. Keeping this issue open.
Assisted-by: gpt-6.1-sol