MeshHold vs ownCloud vs Nextcloud

Every row of ownCloud's own comparison table, answered for all three — including the ones MeshHold loses.

ownCloud publishes a feature table comparing itself to Nextcloud. It is a vendor's table about its own fork, so it is shaped to flatter the author — but the criteria on it are the ones buyers actually ask about, which makes it a useful stress test. Every row of it is below, with MeshHold as a third column, plus rows of our own — some folded into the group where they belong, and the last four groups entirely ours, for the things their table has no reason to contain.

Their table carries its own date: compiled, it says, in September 2020. That is a long time in this market — it predates production Infinite Scale and ownCloud's sale to Kiteworks — so read the two vendor columns as ownCloud's 2020 view of the world, not as today's fact.

Cells marked ^oc are ownCloud's claim about a competitor rather than something we verified; a dash there means their table explicitly marks the feature absent. Where MeshHold has nothing, the cell says so.

Notes

1. ownCloud was acquired by Kiteworks, and in January 2025 the Infinite Scale engineering team left to start OpenCloud. "ownCloud" in 2026 means a US-owned brand whose flagship rewrite changed hands.
2. ownCloud's table marks this row "Enterprise subscribers only" for Nextcloud. That is wrong: docs.nextcloud.com publishes the full user, admin and developer manuals under CC-BY.
3. ownCloud Classic. Infinite Scale runs as Go services instead.
4. No accounts — you hold a key per vault, chat, tunnel exit or mesh network, and holding it is the permission. Keys are named, expiring and revocable, and one capability never unlocks another. Good for a household or a lab; wrong for 200 employees whose access should follow an AD group.
5. A file's key is derived from its own plaintext and encryption happens on the device before replication, so a node storing your blocks without the vault key is the normal case. The trade-off: an attacker holding a candidate plaintext can test whether you stored it. See Core Concepts.
6. SHA-256 content-addressed blocks, a whole-file content hash, and hash-chained versions — integrity is how addressing works, not a feature bolted on.
7. These two rows used to share one answer. They no longer do, and the split is the honest part. ICAP is the protocol a file server uses to hand a file to an external scanner — antivirus or a DLP engine — and act on the verdict. Document classification is the compliance layer above it: you define security levels (ownCloud's examples are Public / Internal / Confidential / Strictly Confidential), files get labelled — by hand, by rules on file or user properties, or from metadata inside the document — and the server then enforces what each level permits: no external share, no public link, a shorter expiry, a retention schedule. It is how a regulated buyer answers "show me that a document marked Confidential cannot leave the building"; ownCloud ships it as an Enterprise app on its workflow and tagging engine.

The old note said both were structurally impossible here, because both need a server that can read the file and a server every access has to pass through so it can say no. The second half is still true. The first half never was: the node holding the vault key can read the file perfectly well, and it is the obvious place to scan from. So MeshHold now ships the ICAP client — see Antivirus scanning — and the row is a ✓ with a qualification rather than a dash.

What the qualification means. A server-side product scans on the way in and refuses the upload. MeshHold scans after the write, as a background job, and never blocks a read: nothing waits for a scan, and your own access to your own files is never gated. The verdict is acted on at the doors that lead out — a public link, a federated share, content pushed to a gateway — because those are the ones that pass through our code. It is a record of what an engine said, plus a refusal aimed outward; it is not a checkpoint every access crosses, and it is not sold as one.

Document classification stays a dash, and for the surviving half of the original reason. Enforcement needs a chokepoint, and there is none: holding the vault key is the access, so a label saying "may not leave the building" has nothing to stop a key-holder walking out with the file. That is not a feature we have yet to write but a shape this architecture cannot take, the same way as note 8. If your compliance regime requires platform-side label enforcement, this is the wrong tool, and no amount of roadmap fixes it.

The correction we already owed ownCloud's table: its dash for Nextcloud on ICAP does not hold today. Nextcloud's official files_antivirus app scans through ClamAV, Kaspersky or an ICAP server. 8. These two rows are opposite problems, and it is worth not confusing them. A password-locked vault or chat room wraps its encryption key under Argon2id, so until someone types the password the node holds ciphertext it cannot read — and with hide when locked set, the vault is not even listed, so its existence is hidden too. One password is tried against every locked vault at once. That protects data from someone who should not have access. Secure View is the reverse: the viewer is authorised, and the point is to cripple what they can do with that access — render the document server-side, forbid download, copy and print, and stamp a per-viewer watermark across it so a leaked screenshot names the leaker. That needs a server that decrypts, renders and watermarks while the original bytes never reach the client. MeshHold decrypts on the client by design: hold the vault key and you hold the file. There is no tier between "can read it" and "cannot", so a virtual data room is not a missing feature but a shape this architecture cannot take. Locking is only offered on streaming-only vaults — a vault with a storage_path writes plaintext to disk, which would defeat it. 9. There is no external storage backend to certify — MeshHold is the storage layer, and can be the S3 backend for other apps. 10. ownCloud's table's parting shot, preserved for completeness. 11. A vault's space is the sum of its trusted nodes' free disk; a file too big for any one node is sharded across several. 12. Two different things share the word. A meshhold://join invite hands another device the vault key, and from then on that device has the whole vault. A public link hands one folder to whoever holds a URL, with an expiry and a revoke button, and no account anywhere.

The second row is the part that has no equivalent in the other two
columns. A public link is decrypted **in the recipient's browser**: the
key rides in the URL fragment, which browsers never send to a server, so
the node answering the link holds ciphertext it has no key for. ownCloud
and Nextcloud decrypt server-side and hand over plaintext, which is what
makes their links work with `curl` and ours not — the same property, read
from either end. MeshHold offers an unencrypted per-file link for the
cases that need one, and says plainly in the dialog that the serving node
can then read that file.

What that costs, since the row cannot: JavaScript is required, an
embedded `<img src>` will not work on an encrypted link, and video plays
only in containers the recipient's browser can decode — there is no
transcoding. The gateway also serves the page's own script, so an
actively hostile operator could serve modified code; running the gateway
yourself is the answer, and it is the same daemon.

See [Public Links](/docs/public-links).

13. A view mode on a vault rather than a separate app, so it needs no installing and no second index. It reads each picture's own EXIF on the node — capture date, orientation, camera, coordinates — and groups by the day the shutter fired, never by the file's modification time, which for a photograph is usually the day it was copied. Coordinates stay on the machine: there is no geocoding service to ask, and consequently no grouping by place name and no map. What it will not show you is a HEIC or a raw file: there is no decoder for either in a build that ships without cgo, so those appear as icons with their date and place intact.

14. Internal means the editor is part of MeshHold rather than a second product beside it. The other two integrate one — Collabora or ONLYOFFICE — which is a server to install, run, update and reach; ours is the daemon that is already there, so there is nothing extra to deploy and nothing extra to be down.

    It speaks OpenDocument natively: it reads and writes .odt and .ods in the daemon on every platform, in a browser or the phone app, with comments, tracked changes and a page that matches the one LibreOffice prints. The spreadsheet half goes as far as pivot tables, named ranges, array formulas, references into another file in the same folder, and sheet protection — the detail is in Documents and spreadsheets, which carries a row-by-row table against ONLYOFFICE and Google Sheets. Editing together needs no office server and no server at all — the changes travel node to node, so two laptops on a local network with no internet still edit the same document.

    The trade is the other row. A .docx or .xls somebody sends you is not read directly; it is converted to ODF first, by LibreOffice on whichever node in your network has one. That node is chosen in a menu, and the conversion runs where the file already is — nothing is uploaded and the original is never touched. A phone with no LibreOffice therefore converts on the desktop it shares a vault with, and a network with no LibreOffice anywhere converts nothing, which the menu says rather than hides.

15. MeshHold speaks Open Cloud Mesh with Nextcloud, ownCloud and oCIS: a protocol adapter rather than a second storage engine, so a vault is exported to a foreign server rather than replicated to it. Off until an operator turns it on, and then per vault.

    The part worth reading before turning it on: a vault shared this way is not end to end any more. The receiving server can read what it was given, and so can whoever administers it. That is the protocol, not this implementation of it — federation means handing another system access — and it is the same category of decision as a file-mode vault whose plaintext any process on the machine can read. It is opt-in, per vault, and the interface says so at the moment of choosing rather than in a release note.

Which one to pick

Nextcloud if you need SSO against an existing IdP, per-user permissions, an app ecosystem and an EU vendor with a support contract — the most complete "replace Google Workspace on our own hardware", and it is not close.

ownCloud if you want the same shape with a faster SLA, an established partner network and the compliance checkboxes a regulated buyer's list actually names. Go in aware of note 1 and ask about the roadmap.

Public links are no longer the line between them. Both have them; the difference is that Nextcloud's are readable by the server and work with curl, and MeshHold's are readable only by the recipient and do not — pick the property you actually want, not the checkmark.

MeshHold if the server is the part you object to — laptop, phone, NAS and a cheap VPS as one private mesh, where the VPS holds ciphertext it cannot read and the same daemon also gives you the VPN, the tunnels, the S3 endpoint, the chat and the media library. No ownCloud or Nextcloud configuration produces that, because both start by requiring the machine MeshHold is designed not to need.

Start with The Personal Cloud, or Core Concepts for the vocabulary.