This note preserves the spreadsheet and authority research that led to collaboration lane #5. The tools inventory remains the comprehensive candidate catalogue.
#Spreadsheet correctness is more than a CRDT map
A spreadsheet can converge at the byte/data-structure level while changing meaning. Concurrent row insertion, range movement, formula references, deletion and undo/redo require stable logical identities or spreadsheet-specific conflict semantics. Treating A1 as the identity of a cell is insufficient when another participant inserts a row before it.
The practical implementation decision is therefore split:
- Grid and interaction surface — editable rows/cells, selection, clipboard, accessibility and large-table rendering.
- Spreadsheet calculation engine — formulas, dependency graph, workbook import/export and recalculation.
- Collaborative data model — stable row/column/cell identities, structural operations and history.
- Authorization/authentication — who may submit which changes and how a peer verifies them.
- Transport and custody — how verified changes and immutable attachments move and persist.
One library may implement several jobs. It should not be credited with the others without source or executable evidence.
#Mog remains the spreadsheet engine to requalify first
Mog describes Yrs/Yjs-based collaboration with stable spreadsheet identities and direct peer synchronization. Its design work is relevant because it treats structural spreadsheet edits and formula references as first-class collaboration problems rather than generic key/value updates.
The public repository evidence reviewed later did not establish every product claim made by the broader site. In particular, the public source appeared as a headless engine while some site material described a wider spreadsheet product. That mismatch means Mog is a code-level requalification target, not an approved dependency.
The decisive test is whether a pinned revision lets an external authority layer:
- observe and serialize a local semantic transaction before distribution;
- bind it to the accepted actor/context authentication profile;
- reject an unauthorized remote change before application;
- preserve stable cell/row/column identities through structural edits;
- checkpoint or compact state without destroying required provenance;
- support the target platforms and license/distribution model.
If those seams exist cleanly, Mog can own spreadsheet semantics while another component owns peer membership and encrypted custody. If they do not, a fork may still be smaller than writing a spreadsheet engine.
#Rows n’ Columns and IronCalc are narrower alternatives
Rows n’ Columns demonstrates a spreadsheet UI/component integrated with Yjs and replaceable collaboration providers, including WebRTC-oriented approaches. It is useful for the application surface and for validating Yjs-based integration. It does not supply our decentralized identity, revocation, encrypted-custody or long-term audit model.
IronCalc is a Rust/WASM spreadsheet-engine candidate. Treat calculation and file-format quality separately from synchronization; an engine does not become a collaborative authority system merely because it can run locally.
Spreadsheet research such as AegisSheet and Cellster remains useful for intention-preserving structural/formula operations. Research semantics are not production-readiness evidence.
#Bento is a useful file-source-of-truth and blind-relay reference
The Bento/Dash work reviewed in August was unusually aligned with a file as durable source of truth model. Its collaboration design keeps the server/relay non-authoritative and uses encrypted frames, with same-machine operation able to avoid a server entirely. The spreadsheet work was newly merged and not a released mature product, so it remains a design/implementation reference rather than a deployment choice.
Its separation between read capability and write/signing capability is useful for our own thinking: a storage/relay path can be blind, while a reader does not automatically possess the authority needed to create accepted writes. The reviewed identity layer did not establish a cryptographically verified human identity for every displayed collaborator; that distinction should remain explicit.
Reference: Bento collaboration design.
#Mindoo is useful evidence, but its tenant is an authority root
MindooDB/TeamGrid is notable because it combines local-first data, encrypted storage and durable authorship/audit concepts. Its architecture also makes the tenant creator/admin key a root of trust for the tenant directory and membership. That is a materially different governance model from peers jointly controlling a shared object without a privileged tenant.
Use Mindoo as an implementation/reference source for:
- stable spreadsheet/object identities;
- signed change histories and inspectable causal DAGs;
- encrypted local-first storage and direct/relay synchronization patterns.
Do not import the tenant model as the default community authority. A server being non-authoritative for data does not imply that the social permission model is decentralized.
Primary reference: MindooDB architecture.
#NextGraph is architecture reference, not the spreadsheet foundation
NextGraph implements substantial encrypted repository, capability and commit machinery, and supports multi-owner concepts. Its spreadsheet product remained postponed in the reviewed feature material. Its normal client/network architecture also routes clients through brokers rather than making arbitrary clients direct peers by default.
That makes NextGraph useful for encrypted-repository and multi-owner design comparison, but not the current spreadsheet implementation target. Its scope is broad enough that adopting it would be a platform reorientation, not a library substitution.
See network architecture and encryption.
#Le-Space is stronger as networking/identity evidence than as a spreadsheet
The Le-Space spreadsheet prototype demonstrates browser Yjs synchronization over libp2p/WebRTC. The spreadsheet itself is a small prototype, not a mature workbook engine.
The surrounding Le-Space work is more consequential. Its later P2P applications and identity experiments show passkey/device identity, signed append-only state, device approval/revocation, direct WebRTC and multi-device reconciliation in executable applications. That evidence makes its P2P/device work worth studying even if the spreadsheet UI is replaced.
References: local-first Le-Space notes and Yogasuci.
The lesson is compositional: reuse working peer/device mechanisms where they match our contracts; do not extend a hackathon spreadsheet into the product merely because its transport is attractive.
#Willow/Meadowcap is the clearest no-global-owner reference
Meadowcap distinguishes owned and communal namespaces. Communal namespaces are important because they do not require one global namespace owner above all participants: individual subspaces can be rooted in participant keys and capabilities.
That aligns with the desire to avoid a tenant administrator, but it does not by itself solve jointly governed spreadsheet state. A communal namespace answers who may write a participant-controlled subspace; it does not decide how several people jointly change membership, redact a shared object, or resolve a disputed checkpoint.
Willow therefore remains a protocol/auth reference and potential component. Its implementation and complete sync/network packaging must be evaluated independently of the specification.
#p2panda is the strongest pragmatic substrate examined
p2panda is data-type-agnostic and can carry application-defined CRDT/change data. Its networking and group-management work is closer to the missing substrate around a spreadsheet engine than a complete workspace framework.
The access-control CRDT research is especially relevant because it treats concurrent removals and authorization changes as a convergence problem rather than assuming ACL updates arrive in one order. Its later notes discuss the consequence that application state may require rematerialization or semantic correction when authority changes invalidate concurrent work.
The p2panda group model includes management capabilities, so it is not automatically the same as Meadowcap's communal/no-owner philosophy. It is nevertheless a stronger near-term implementation candidate because more of the peer synchronization, auth and encryption plumbing exists in code.
Treat p2panda as one possible owner of synchronization/authorization mechanics, not as a mandatory wrapper around every CRDT.
#Keyhive may become a better capability abstraction, but is not production-ready
Keyhive develops convergent capabilities and group/device abstractions for local-first applications. The design is relevant to:
- a person represented as a group of authorized devices;
- nested groups/teams;
- delegation and attenuation;
- revocation under offline concurrency;
- encrypted local-first collaboration.
Its own project material has described the implementation as pre-alpha/unstable and unaudited. That makes it a research/implementation reference and a component to watch rather than the security boundary for a first production release.
See the Ink & Switch Keyhive notebook for the model.
#Radicle and Matrix teach different lessons
Radicle is useful evidence that signed peer state plus explicit N-of-M canonicalization can work in a deployed decentralized collaboration system. Its canonical-reference ideas are relevant to rare high-risk decisions or accepted checkpoints, not ordinary cell edits.
Matrix is useful for studying state-conflict handling, but its scalar room power levels are not our community model. A person trusted for safety review, equipment custody or a particular space should not become globally “more powerful” on one numeric axis. The relevant lesson is narrower: permission-changing events need explicit deterministic conflict semantics and cannot be merged like ordinary content.
Do not import Matrix power levels into the product.
#Current composition to test
The most coherent experiment remains:
Grid / workbook UI
|
Spreadsheet engine with stable logical identities
|
Authenticated semantic change batches
|
Selected collaborative representation
|
p2panda / another accepted peer substrate
|
replaceable private carriers and ciphertext custodyA Willow/Meadowcap-style capability model can be compared against p2panda's group machinery without coupling the spreadsheet engine to either. If DXOS wins the larger workspace comparison, the same spreadsheet semantics still need validation inside ECHO rather than being assumed.
The application should not maintain two authoritative histories for one workbook merely to preserve architectural optionality.
#Falsification tests
- Concurrent row/column insertion and formula editing preserve the intended referenced cells.
- Move, delete, undo/redo and late synchronization converge under the accepted semantic policy.
- A peer cannot make an unauthorized change valid by winning a delivery race.
- A concurrent removal/compromised-device event has an explicit effect on dependent later edits.
- A late reader can distinguish current checkpoint endorsement from original historical author authentication.
- A non-reading host can retain/repair workbook attachments and checkpoints without receiving application content keys.
- Replacing the network/custody adapter does not change spreadsheet authorization outcomes.
- Context-specific identity and private-authentication requirements do not become permanent globally transferable author evidence by accident.
#Provisional conclusion
Use this research to keep spreadsheet semantics and decentralized authority separate. Requalify Mog first for spreadsheet-specific mechanics. Compare p2panda as the pragmatic peer/auth substrate and Willow/Meadowcap as the no-global-owner capability reference. Keep Keyhive, Le-Space, Radicle, OrbitDB, DXOS and the other systems as focused comparisons where their implemented behavior can remove specific work.
No one of these projects has yet earned ownership of the complete application architecture.
#Open questions
- Does a pinned Mog revision expose the transaction/authentication seams required by lane #5?
- Which spreadsheet operations need semantic events above the underlying CRDT?
- Can p2panda's group-management machinery express the needed ordinary-edit versus high-risk transition split without recreating an admin hierarchy?
- What would a Meadowcap-inspired joint-object policy add beyond contextual contributor keys and checkpoint endorsement?
- Which historical provenance is useful enough to retain once private deniability and late-reader semantics are included?