Sharing concepts

nextcloud compared to syncthing

nextcloud	syncthing

Data always on central server. Local data is supported and fine, but no need to download all data i have access to.	all data has to be on the system if I want to have access to it (ignore pattern might work, but maybe complicating).
Access to data in Webbrowser	No access to data via gui
Sharing via weblink	Sharing only to other peers having syncthing installed

Syncthing shares data peer-to-peer — no central server, no cloud intermediary. Each device communicates directly with the others it knows about.

Syncthing Characteristics

Property	Detail
Peer to peer	Devices sync directly; no server required
Self-healing	If a device goes offline, sync resumes automatically when it reconnects
Self-discovering	Devices find each other via local discovery and global announce servers
Known devices only	Sharing requires explicit trust — only devices you add can participate
Known folders only	A folder must be explicitly shared; nothing is exposed by default

Limitations

Granularity is limited — you share entire folders, not individual files or sub-trees
Nesting is not supported — sharing a folder does not share subfolders independently; nested shares cause conflicts and are not recommended
No per-file access control — all devices with access to a folder see all files in it

Typical currently intended use in this project

This project uses Syncthing across >= 3 nodes: a source (primary), an encrypted backup node, and a hot-spare secondary. All three sync directly

The backup node runs in receive-encrypted mode: it stores only encrypted blobs and cannot read file contents. The secondary holds a full readable mirror and can take over if the source is lost. This shall be granted even if hot-spare was offline via having the ability to receive the latest data from the encrypted backup node.

See Scenario 1 for a concrete setup.

Nextcloud Characteristics

Property	Detail
Central server in the middle	All files reside on the server; accessible via browser or sync client.
Web access	Native browser access from anywhere, no client installation required
Granular sharing	Files, individual folders, and sub-trees can be shared independently
Ad-hoc sharing	A public link grants access to anyone — no account required
Federation	Multiple Nextcloud instances can share across server boundaries
Access control	Per-item permissions (view, edit, reshare) for users, groups, or public links
### maybe to consider as source of problems

relies on server — if the server is offline or unreachable,
- not local synced data is gone /not available
- sync is broken
Not Peer to Peer and distribution friendly by nature
- all traffic routes through the server, even between devices on the same network
- pinned to DNS or IP, no autodiscovery
Server-side encryption is an add-on — when enabled, the server cannot index, search, or preview files; key management adds complexity

typical use in this project

Property	Detail
Role	Web access and sharing layer below Syncthing-backed data
Deployment	Docker container on the source host; data folder lives inside a Syncthing-synced path
Data path	Syncthing replicates the data folder across nodes; Nextcloud provides browser and client access to it
Portability	Container/Pod + volume can be migrated to any host; Syncthing restores data independently if needed
External sharing	Public links and per-user shares for collaborators outside the node infrastructure
Status	first test, apart from the usual caveats like ownership issues. No principal architectonical known obstacles or blockers
To check / unclear	does nextcloud keep information about removed data in database(-history ?) forever ?. Especially if removed without using nextcloud

combining nextcloud and syncthing possible ?

how to keep them going out of their way

idea: nextcloud starts in subfolder of syncthing-folder

syncthing treats nextcloud sync data as content
nextcloud can not reach syncthings status data because its above its folder out of sight and permissions

portability possible ?

Portability depends on the scenario. The core challenge: Nextcloud share-links and client connections are bound to a domain name. Moving the server breaks them unless the domain moves with it.

Scenario	Challenge	Mitigation
Backup / restore	Nextcloud data folder can be replicated by Syncthing; container can be relaunched on a new host	Treat container + data volume as the portable unit — Syncthing ensures the data is already there
Person leaves institution or Institution stops or changes service	Institutional domain disappears; all share-links go dead	Use a portable domain independent of the institution; announce new links before leaving, use some persistent dedicated longterm system
Project migrates host	Clients and shares reference the old domain	Pre-announce domain change; keep a redirect proxy at the old address during transition
Project forks	? Splitting one instance means migrating user data and re-issuing all shares	? If a fork is foreseeable, run independent instances from the start

to consider
- nextcloud share-link persistence of
  - Sticks to DNS
- mitigations / what to do how instead
  - accept staleness or forking
  - use use portable DNS
    - and nextcloud might support multiple
  - transfer snapshots to a longtern dedicated repository of some suitable institution
    - see nextcloud -> invenio importer at sciebo ?
    - widespread ad-hoc use of zenodo.org

← Kube3 Use Case: Projektcloud · Core Concepts →

tfakln · v2026-05-19 · Export created: 2026-06-11 15:08 UTC