Documents and Spreadsheets

Write together, with no office server anywhere.

Write a document in the browser, on the phone, or on the laptop, and have somebody else type in it at the same time — with no office server anywhere, and no account to make.

MeshHold's editor is its own, and it speaks OpenDocument natively: it reads and writes .odt and .ods in the daemon, on every platform it runs on. There is nothing to install beside it and nothing to keep running: the document is a file in a vault like any other, so it replicates, versions, mounts, shares and stays available offline by the machinery that was already there.

What the editor does

Headings and paragraph styles, fonts and colour, lists with multi-level numbering, tables, pictures, links, footnotes, a table of contents, find and replace. Comments you can resolve, and tracked changes you can accept or reject. Pages that look like pages — the same page LibreOffice prints, measured against it rather than approximated.

Spreadsheets get cells and formats, formulas, several sheets, charts, conditional formatting and data validation.

None of that needs a server. The document is parsed and written by the daemon on your own machine, and drawn by the browser in front of you.

Editing together

Open the same document on two nodes and both people type into it. The changes travel node to node over the mesh, so two laptops on a local network with no internet still edit the same document — there is no office server to be unavailable, because there is no office server.

What each person sees is who else has it open and where their edits land. What nobody has to do is resolve a conflict: the document is a CRDT, so two versions that diverged — one of them offline for an hour — merge rather than fork.

Opening a .docx somebody sent you

The editor's format is ODF. A .docx, .doc, .rtf, .xls, .xlsx or .ppt is converted first, by LibreOffice on whichever node in your network has one.

Right-click the file and the menu lists the nodes that can do it:

Convert "contract.docx"
  ▸ Convert here                     LibreOffice 25.8
  ▸ Convert on homelab               LibreOffice 25.2
  ─────
  No node in this network can convert.
  Install LibreOffice on a desktop node to enable this.

Three things are worth knowing about that menu.

The list is real before you click it. Each node was asked whether it holds this vault's key and whether its LibreOffice works — not whether it claims to. A node whose LibreOffice is installed but broken says so rather than appearing and failing.

The conversion happens where the file already is. The node doing the work holds the vault key, so it reads the blocks the ordinary way and writes the result back as a new file beside the original. Nothing is uploaded, and the original is never touched — the .odt appears next to the .docx, and if one is already there it is left alone.

A phone converts on the desktop. LibreOffice does not run on Android and never will, so a phone asks a node that shares the vault with it. A network with no LibreOffice anywhere converts nothing, which the menu says plainly instead of hiding the option.

Conversion is one-way. The .docx becomes an .odt and from then on it is an ODF document; the original stays where it was.

Exporting

Two exports, and which you get depends on which control you press.

Print is the built-in one. The editor lays out real pages, so the browser's own print pipeline produces a PDF that matches what you were looking at. It needs no node, no LibreOffice and no network, and it works on a phone.

Export… goes through LibreOffice, for what print cannot do: another format (.docx, .xlsx, .rtf, CSV), or a PDF carrying

• a watermark across every page,
• a password to open it,
• restrictions on printing, editing and copying,
• PDF/A for an archive,
• or only some pages.

Those options need LibreOffice 7.4 or newer on the node doing the work. Against an older one the dialog offers the format and hides the options, rather than showing a checkbox that would quietly do nothing.

One caveat said plainly: PDF permissions are enforced by the reader, not by the file. A compliant viewer honours "no printing" and a determined one ignores it. Treat them as a stated intention rather than as protection.

Deciding who may use your machine

Conversion spends the CPU of whichever node does it, so the node's owner decides.

Work for peers in Settings is on by default: any node in your network may ask this one to convert something. Turning it off removes this node from everyone else's menu within seconds and refuses anything already asked. It also pauses itself while the device is in low power — a phone saving its battery has not agreed to spend it on somebody else's document.

Only nodes with a work key narrows that further, for a network with a rented server or a half-trusted guest in it. Mint a key with the jobs capability, hand it to the nodes you want, and everyone else is refused.

Neither switch is a data boundary, and it is worth being clear why. A node that converts your document already holds the vault key — that is the whole arrangement, and it is why nothing has to be uploaded. What these switches control is CPU, not access: a node you would not trust with the document should not be in the vault in the first place.

Where documents live

In a vault, as files. That is not a detail — it is why:

• every save is a version, and the whole history is one click away;
• a document replicates to the nodes that hold the vault, so it is on your laptop when the phone that wrote it is off;
• it can be mounted as a drive and opened in desktop LibreOffice or Word instead, if that is what a particular document needs;
• it can be handed to somebody through a public link, decrypted in their browser;
• and it is available offline, because it was never anywhere else.

Against ONLYOFFICE and Google Docs

Three editors that all let two people type in one document, and that is about where the agreement ends. ONLYOFFICE Docs is an office suite with a server behind it: you install Docs on a machine, integrate it with a storage system, and it opens .docx natively because OOXML is its own format. Google Docs is a service: nothing to install at all, and the document lives in Google's storage in Google's own format. MeshHold's editor is neither — it is ODF in the daemon you are already running, with the document sitting in a vault as a file.

These are our rows, which is the weaker position to argue from, so where a — is a design decision rather than a thing not yet built it says so, and the groups where MeshHold loses outright — things placed on the page, and everything under Beyond typing — are in the table rather than left out of it.

Notes

1. ONLYOFFICE Docs Community is a server: 4 GB of RAM and 40 GB of disk on an amd64 Linux machine, plus the storage system it integrates with. The Desktop Editors run without it, but co-editing does not — that is what Docs is for. MeshHold's editor runs inside the daemon that is already replicating your vaults, so there is no second thing to install, update or watch.
2. Android, and any phone browser pointed at a node. There is no iOS app and no macOS build — if your household runs on Apple hardware, the two other columns work today and this one does not.
3. ONLYOFFICE's own format is OOXML, and its x2t engine converts an .odt on open and back again on save. That is the mirror image of the trade here: MeshHold parses and writes ODF directly, and converts .docx instead.
4. This is the reason for the whole design. A save rewrites the parts that changed and leaves every other archive entry — the pictures especially — as the bytes it found them, so opening a document and closing it does not quietly produce a different file. It is also what makes the storage underneath cheap: unchanged bytes re-seal to the same encrypted blocks and travel nowhere.
5. An ODF package encrypts per entry and records it in a manifest that stays readable, so the editor can say "this document has a password" instead of failing on every part with "content.xml is corrupt". Opening one is not supported; the refusal is deliberate and legible.
6. Watermark, open password, restrictions on printing, editing and copying, PDF/A, or a page range — produced by LibreOffice on whichever node in your network has it. Worth repeating from Exporting: PDF permissions are enforced by the reader, not by the file.
7. Body text and Heading 1–4, applied through the document's own named styles — applying one renames the element and mints the style if the document has none. Styles the file already carries are preserved and go on working; what is missing is a gallery for inventing new ones here.
8. The first master page, written back into the file. A different first page, or different left and right pages, is read and preserved but not edited here.
9. spellcheck is set on the editable, so the browser or the WebView does it with whatever dictionaries the platform has. Nothing of ours checks spelling, and building it is deliberately not planned: rewriting, explaining and translating are things you ask the agent, which names the node and the model before anything is sent anywhere.
10. Which costs what you would expect — the clip is inside the document, so the document is as large as the clip. It is there because a vault can carry it, not because a word processor usually can.
11. The oracle is LibreOffice's own PDF of the same file, compared by the character offset each page starts at rather than by eye. Letters, invoices and quotes come out with the page count LibreOffice gives them. One case is open, and stated rather than hidden: a table row taller than a page — a three-column bilingual contract is exactly that — overflows instead of splitting across pages.
12. Presence and carets ride the sync exchange, which is a one-shot exchange rather than an open stream, so what you see is as fresh as the last round trip — about a second while somebody is typing. Google and ONLYOFFICE hold a socket open to a server and are quicker; they also need the server.
13. Not a backlog item. office:annotation in ODF has no thread, and the two producers that tried disagree: LibreOffice 6.4 drops loext:parent-name, and Word's .odt export flattens replies into separate comments on the same words. A thread invented here would survive only until somebody opened the file in either of them.
14. And not planned. A macro language is a second way to program a document; the answer here is the agent session, which already has approvals, a model picker and a history.
15. The key travels in the URL fragment, so the gateway serving the link never sees it and never holds the plaintext. See Public links.

Which one to pick

ONLYOFFICE Docs if the documents that matter are .docx and they come from Word — its fidelity is the best of the three, and the feature list above is the longest for a reason. Expect to run a server for it.

Google Docs if nothing may be installed and everybody already has a Google account. Nothing else is as quick to start, and the collaboration is still the smoothest.

MeshHold's editor when the document should not leave your own machines: when there is no internet and two laptops still have to edit the same file, when the file has to stay a file — versioned, replicated, mountable, encrypted at rest — and when ODF is the format you actually want rather than one that gets converted twice on the way through. It is the youngest of the three, and the table above is meant to make it obvious where that shows.

What it does not do

• It does not edit .docx in place. ODF is the format; foreign files are converted in, and exported back out as new files.
• It does not run without LibreOffice for foreign formats. Native ODF documents need nothing; a .docx needs a node with LibreOffice somewhere in the network.
• It is not Secure View. A watermark on an exported PDF marks the copy you hand over; it does not stop the recipient saving, printing or forwarding it. Preventing that needs a server that renders documents the viewer never receives, and MeshHold decrypts on the client by design.