Integrate persistent collaborative EtherCalc workbooks with experiment results and IPFS versions
I maintainer di solito rispondono entro 1 giorno
@Winter-Soren ci sta già lavorando.
Dal 28/10/2026.
Valutazione
Questa issue non è ancora stata valutata.
Descrizione
Outcome
Embed current audreyt/EtherCalc in QMesh so completed pharma, finance, and circuit runs can be explored together in persistent collaborative workbooks, with deliberate IPFS version backups. Demo target: October 31, 2026 (Asia/Kolkata), November 1 buffer.
Accepted design and scope
- Pin and test current TypeScript/Hono/workerd upstream; use bundled SocialCalc. Deploy a separate persistent service, embedded inside the existing application.
- One workbook feature and domain adapters. Idempotent creation keyed to immutable run identity/version; reopening never overwrites collaborator work.
- Preserve original scientific JSON and artifact references alongside useful tables, units, method, configuration and provenance. Source snapshots remain separate from editable comparison/notes sheets.
- Authenticate workbook access using existing app identity, with owner/editor/viewer permissions, invitations, stable links and shared-workbook discovery. Protect UI, HTTP, export and WebSocket paths; links alone do not authorize access.
- Explicitly add an owned experiment to a shared workbook with data-sharing consent. No implicit sharing of future runs.
- Agent reads bounded ranges and explains results; any supported edits use explicit approval. Opening/recalculating sheets must not submit paid jobs.
- Persist live rooms on mounted durable storage and workbook/access/run/version metadata in the app database.
- Explicit Save version to IPFS with deliberate public-data consent; upload native sheet saves, original JSON and manifest, retain actual returned CID, verify retrieval and restore coherently into a NEW workbook. Reuse persistent Kubo; credentials stay server-side.
- Document decisions, setup, collaboration, persistence, demo and verification in QMeshPy/documentations. One issue covers both repositories.
Acceptance criteria
- Completed pharma, finance and circuit results open correctly populated embedded spreadsheets; repeated export reopens the same workbook.
- Two independent authenticated browser sessions collaborate in the same room; viewer mutations and unauthorized UI/API/export/WebSocket requests fail.
- Collaborator can deliberately add their owned experiment without mutating either source run.
- Workbook edits survive browser reload and service restart.
- Bounded agent context works without automatic paid job execution.
- Snapshot records actual provider CID, reports failure accurately, is retrievable without browser-local data, and restores all sheets/formulas/formatting/source metadata into a new workbook.
- Mapping, idempotency, permissions, invitations, proxy boundaries, snapshot and failure-recovery tests pass; project checks and real Chrome demo evidence are recorded honestly.
- Separate documentation branch is committed and pushed, with reproducible demo steps and precise remaining limitations.
Explicit non-goals
Browser-to-browser libp2p replication/offline CRDT merge, duplicate SocialCalc integration, automatic initial/public IPFS publication, per-keystroke IPFS synchronization, unrelated wallet work, merging main, contacting demo recipients or publishing a video.
- Lingua principale
- Python
- Stelle
- 2
- Fork
- 4
- Merge medio
- 8h 37m
- PR unite (30g)
- 29
Preparare l'ambiente
- Include un Dockerfile o un file Docker Compose
- Nessun modello di pull request
- Nessuna guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di QMeshPy/distributed-quantum
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 66/100
QMeshPy/distributed-quantum#112 ·
I maintainer di solito rispondono entro 1 giorno
-
enhancement good first issue helia storage tier-1
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
QMeshPy/distributed-quantum#53 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
QMeshPy/distributed-quantum#111 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 48/100
QMeshPy/distributed-quantum#110 ·
I maintainer di solito rispondono entro 1 giorno
-
chain-integration enhancement payments research-spike tier-2
Difficoltà 4/5 3-5 giorni Idoneità per principianti 55/100
QMeshPy/distributed-quantum#78 ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di QMeshPy/distributed-quantum
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 86/100
-
Validate finite output clamping limits in StepPredictor.prepare_clamping_params to prevent silent NaN/Inf propagationForse già presa @muskan-creates352 l’ha presa oggi. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
mllam/neural-lam#848 ·
I maintainer di solito rispondono entro 2 giorni
-
infra
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 88/100
fab-geocommuns/RNB-coeur#1166 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
deepspeedai/DeepSpeed#8951 ·
I maintainer di solito rispondono entro 2 giorni
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
aws/context-ontology-accelerator#343 ·
I maintainer di solito rispondono entro 1 giorno