Sovereign Storage & Sync Stack — Final Scoring & Ranking

Syncthing is a peer-to-peer file synchronization system designed to eliminate the central server requirement. The protocol uses mutual authentication and TLS; device identity is key-based.

• Pure P2P topology with optional discovery/relay infrastructure that can be replaced or avoided (official site, docs).
• Untrusted (Encrypted) Devices enable folder-level ciphertext storage on an untrusted peer via a password (untrusted devices docs).
• Hostile lens nuance: discovery servers can learn device IDs/IPs unless disabled or self-hosted (security model).
• Simplicity advantage: single daemon + Web UI; comparatively small operational surface vs multi-service platforms (downloads).

Peergos is a peer-to-peer encrypted global filesystem with fine-grained access control, designed to resist surveillance of both data content and friendship graphs.

• Explicit privacy-by-design goal: only the user should read data, metadata, and friend list (features).
• Social graph protection: follow requests sent over Tor to hidden services to hide network metadata (social graph security).
• Hostile lens emphasis: metadata/graph protection is treated as a first-class requirement, not a bolt-on (metadata notes).
• Tradeoff: heavier stack than minimal daemons (more moving parts → larger attack surface) (GitHub repo).

Tahoe-LAFS provides decentralized storage with “provider-independent security”: storage servers hold ciphertext shares, and the system remains confidential and retrievable even if some servers fail or are taken over.

• Client encrypts, erasure-codes, and disperses shares across multiple servers (about, architecture).
• Default reconstruction threshold model (e.g., 3-of-10 shares with defaults) supports resilience (erasure coding details).
• Hostile lens nuance: network-level anonymity is not intrinsic; layering via Tor/I2P/VPN is required for IP/topology hiding (privacy analysis (PDF), Tor Project overview).

git-annex manages large file content “alongside Git” and supports many remote backends. It is an orchestration primitive rather than a universal encrypted filesystem.

• Special remotes store annexed file contents outside normal Git remotes and can be tested and configured (special remotes, using special remotes).
• Encryption scope is bounded: repo metadata (filenames/history) remains visible to anyone with repo access (encryption notes).
• Hostile lens best fit: pair git-annex with untrusted backends (S3, rsync, Tahoe, etc.) using encrypted special remotes (encrypted annex workflow).

CryptPad is an end-to-end encrypted collaboration suite (docs, sheets, drive). The server cannot read document contents under its stated threat model, but it serves the client-side application (JS), creating a supply-chain trust axis.

• Cryptographic design documented in the CryptPad whitepaper (whitepaper (PDF)).
• Browser crypto dependency: encryption requires JavaScript in the browser (instance docs note).
• Hostile lens nuance: web apps inherently trust the instance to deliver non-malicious JS (security guide, independent review).

Blossom is a specification for HTTP endpoints that store “blobs” addressed by SHA-256 hashes on public servers, using Nostr public/private keys for identity and signed authorization events.

• Spec claim: “blobs addressed by their sha256 hash” and Nostr key identities (spec repo).
• Hostile lens nuance: no native encryption layer in the protocol; confidentiality requires client-side encryption conventions.
• Maturity signal: ongoing spec hardening discussions (e.g., authorization edge cases) (auth clarification PR).

IPFS is a set of open protocols for addressing and transferring content using peer-to-peer networking and content addressing. It is modular by design and does not ship with a built-in privacy layer.

• Core claim: no built-in privacy layer or encryption in the protocol core (IPFS privacy & encryption).
• Best practice guidance: private networks can limit participation; encryption is still the responsibility of higher layers (privacy best practices, private swarm note).
• Hostile lens fit: excellent for public publishing and for distributing already-encrypted blobs; not a “private drive” by default.

MinIO is a high-performance, S3-compatible object storage server. It is operationally valuable as a backend, but governance and product bifurcation increase capture risk in a hostile lens.

• Dual licensing: AGPLv3 + commercial license (license page, repo).
• Product split: “two product binaries” (MinIO Object Store vs AIStor), with AIStor under commercial license (AIStor overview, AIStor download).
• Hostile lens fit: strong for internal object storage; not a privacy-by-design, zero-knowledge layer.

Nextcloud is a self-hosted file sync and collaboration platform. Under hostile assumptions, the encryption story is limited by metadata visibility and published breaks in E2EE sharing designs.

• Server-side encryption limitation: SSE does not encrypt filenames or folder structures (SSE documentation).
• Published cryptographic break: “Share with Care: Breaking E2EE in Nextcloud” (paper (PDF), discussion summary).
• Hostile lens fit: strong “trusted admin” groupware; not a malicious-admin-resistant vault.

Seafile is an EFSS platform with encrypted libraries. Under a hostile server/admin model, the encryption system leaks structure and has documented weaknesses and ecosystem-level breaks.

• Official guidance: encrypted libraries created via web interface send password/keys through the server; E2E protection requires creating encrypted libraries from the desktop client (security features).
• Long-standing critique: “Encrypted libraries leak lots of information” (metadata exposure and crypto issues) (issue #350).
• Formal research: “End-to-End Encrypted Cloud Storage in the Wild: A Broken Ecosystem” covers severe vulnerabilities across products, including Seafile (paper (PDF), ACM entry).

Pydio Cells targets enterprise document collaboration and compliance use cases. Its encryption is designed to keep data “under control” on third-party storage, but keys remain server-admin-managed in the documented model.

• Datasource encryption: AES-GCM with a 256-bit master key generated by the admin (encryption docs).
• Operational nuance: master key workflows are exposed via API endpoints (create/import/export) (create key API, import key API).
• Hostile lens fit: encryption protects against some storage-provider risks, but not against a malicious admin/server holding keys.

ownCloud Infinite Scale (oCIS) publishes Apache-2.0 source code, while “stable, supported binary builds” distributed by the vendor are covered by a non-OSS freemium EULA — a material capture vector in hostile governance analysis.

• License statement: Apache-2.0 source + EULA for stable supported binaries (official license page).
• Documented conflict: community issue discussing LICENSE vs EULA ambiguity (issue #6570).
• EULA primary text: (EULA PDF).
• Hostile lens fit: usable as an edge platform if built from source and treated as replaceable; unsuitable as a trust-minimal core component.