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. Two rows, one root cause — plus a correction. ICAP is the protocol a file server uses to hand every incoming file to an external scanner — antivirus or a DLP engine — and act on the verdict before accepting it. Document classification is the compliance layer above that: 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 carried inside the document — and the server then enforces what each level permits: no external share, no public link, a shorter link expiry, a retention and deletion 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 built on its workflow and tagging engine.

Both rows need the same two things: a server that can read the file, and a server every access has to pass through so it can say no. MeshHold's peers hold ciphertext, and there is nothing in the middle to say no — holding the vault key is the access. So these are not features 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 content scanning or label enforcement, this is the wrong tool, and no amount of roadmap fixes that.

The correction: ownCloud's 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. 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.