TLDR: Collab WIW is a DOCX editor with MS Word parity that supports real-time collaborative editing. The collab layer is end to end encrypted and uses ephemeral rooms with stable share URLs. Ever collab room lives in only memory. Collaborator saved copies can bring the room back online at the same URL and reconcile offline edits.

The MS Word parity DOCX editor: I made a previous HN post about the editor itself. It is a pure JS DOCX editor that renders and edits the original document directly in the DOM instead of converting it into some other format.

I benchmarked it pretty heavily against thousands of pages to push for pixel and feature parity, including equations, tables, 3D objects, headers, footnotes, etc... I am not going to get too deep into that because I already posted a ShowHN earlier. The parity report has all of the fixtures I tested and the actual results.

The server: The collab BE was actually inspired by OpenFront.io :). Users send small edit intents to the server. In an encrypted room the server cannot process those edits because it cannot read them. It just gives each encrypted envelope the next sequence number and sends the same ordered stream to everybody in the room.

Collaborative rooms: The rooms are ephemeral and the server keeps their encrypted document state in memory. I chose these constraints because this is a public demo. I wanted people to create and share a document ad-hoc without making an account. I also don't your data plz, no thank you.

Also because intents are tracked by document there is some support offline editing support and document reconciliation when it comes back up. Its still a bit ugly so there are limits, if the document can't be cleanly fast forwarded, the editor will try to reconcile up to 50 intents. If there are no conflicts the document fast forward to 2000 tailing intents. After that point you just gotta create a new draft. Just cleaner that way. I am still actively working on improving this system and figuring out how it can be improved.

E2EE:

1. Documents, edits, images, cursor positions, etc... are encrypted in your browser and stay encrypted on the server. The document key is generated in the browser and lives in the share link's fragment, and never gets sent to the server. The server just sequences the sealed data.

2. A document also requires require a share code that you send separately from the link. The browser stretches that code and mixes it into key derivation, so the link by itself is not enough to decrypt the room.

4. Resource limits are placed basically everywhere.

Blog covers more of it so check it out.

Show HN: Collaborative Docx Editor with MS Word Parity