Integrate persistent collaborative EtherCalc workbooks with experiment results and IPFS versions
Los mantenedores suelen responder en 1 día
@Winter-Soren ya está trabajando en esto.
Desde el 28/10/2026.
Evaluación
Este issue todavía no se ha evaluado.
Descripción
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.
- Lenguaje dominante
- Python
- Estrellas
- 2
- Forks
- 4
- Merge medio
- 15 h 49 min
- PR fusionados (30 d)
- 50
Preparar el entorno
- Incluye un Dockerfile o un archivo de Docker Compose
- Sin plantilla de pull request
- Sin guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de QMeshPy/distributed-quantum
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 66/100
QMeshPy/distributed-quantum#112 ·
Los mantenedores suelen responder en 1 día
-
enhancement good first issue helia storage tier-1
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
QMeshPy/distributed-quantum#53 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 35/100
QMeshPy/distributed-quantum#111 ·
Los mantenedores suelen responder en 1 día
-
chain-integration enhancement payments research-spike tier-2
Dificultad 4/5 3-5 días Aptitud para principiantes 55/100
QMeshPy/distributed-quantum#78 ·
Los mantenedores suelen responder en 1 día
-
documentation good first issue kubo storage tier-1
Dificultad 2/5 1-3 horas Aptitud para principiantes 42/100
QMeshPy/distributed-quantum#75 ·
Los mantenedores suelen responder en 1 día
Todos los issues de QMeshPy/distributed-quantum
Issues similares
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
aws/sagemaker-python-sdk#6554 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 78/100
huggingface/diffusers#15170 ·
Los mantenedores suelen responder en 1 día
-
[BUG] LLM conflict check ignores MNEMOSYNE_LLM_MAX_TOKENS, so reasoning models return empty repliesAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
mnemosyne-oss/mnemosyne#1325 ·
Los mantenedores suelen responder en 1 día
-
enhancement meshtastic-2.8
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
pskillen/meshflow-api#459 ·