RFC: evaluate Fileverse middleware as the Phase 3 collaboration transport

[criptogus]

This is an RFC — design discussion before any code.

Context

Phase 3 of docs/ROADMAP.md calls for local-first multi-user collaboration (CRDT layer, presence, a reference sync server) and currently assumes we build the sync/identity layer ourselves. Fileverse has an open-source (AGPL-3.0) middleware that already solves several of the hard parts for its dDocs/dSheets apps: decentralized storage (IPFS), end-to-end encryption, zero-knowledge access control (collaborators prove membership without exposing identity), and shared portals.

Question for this RFC

Should HermesOffice adopt (or interoperate with) the Fileverse middleware as its collaboration transport, instead of building a bespoke sync server?

Points to evaluate:

• License compatibility: their AGPL-3.0 vs our Apache-2.0 tree — likely means talking to it as a service/protocol rather than vendoring code.
• Model fit: our documents are OOXML files with the file as source of truth; their model is web-native. Does a CRDT session layered over our block model round-trip through their portals cleanly?
• Identity: their zero-knowledge access control vs the agent-authorship requirements in Phase 2 (signed comments/revisions).
• Failure independence: the roadmap requires the product to stay 100% functional offline and peer-to-peer — any dependency must degrade to that.
• Alternative: plain Yjs + our own minimal relay in ee/, treating Fileverse only as an export target (Share without SaaS: publish the open document to IPFS / Fileverse #34).

Community input welcome — especially from anyone who has built on the Fileverse stack.