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. The server keeps each live room in memory, while every browser keeps a durable copy of the document and its edit history. A saved browser copy can bring the room back online at the same URL and reconcile offline edits when collaborators return.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 edits offline and have some level of 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, which browsers do not send to the server. The server just sequences the sealed data, but it cannot open it.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.