Centralised and Decentralised File Synchronisation

Alright, so this is a kind of a quick post on the topic of centralised and decentralised file synchronisation, and why you should care about which type you use for your files.

Let’s introduce some basics:

• At its most basic, centralised file synchronisation has one central server, though this can be expanded. Each device has to connect through that or another central node which contains the files: there is no “other” option. If you have used any “Big Tech” “Cloud” service, you have probably encountered this type of synchronisation (think iCloud, Google Drive, etc.).

• In decentralised synchronisation, on the other hand, there is no one “central hub”, although a certain node can be set to be always on to act as a buffer. By principle, devices interface directly with each other. An example of such a system is syncthing or resilio sync.

Why you should care:

• Centralised sync is usually slower: while this is dependant entirely on your internet speed, centralised sync is usually slower. A lot of decentralised synchronisation systems allow devices, not only to interface directly, but also simultaneously with multiple devices at once, yielding better speeds. Transfers over local networks are usually faster and also more efficient; not to mention that when there is no internet, it still works because it can function “off the grid” for the aforementioned reasons. Centralised sync does not have this advantage.

• Where is the central node? — heck does anyone know (except Big Tech). With decentralised file synchronisation, you control which devices sync and which don’t. When syncing through a centralised service you have no idea where your files are stored.

• Open source: choosing an open source solution (even as a service) ensures that you know what kind of software is being run on the back end. Most centralised sync providers are completely closed source, meaning that you do not know how your data is being stored or processed. In open source software, the protocol is being checked by different people, very often yielding better security than otherwise. Whenever a flaw is found, it is usually ironed out quicker than closed source alternatives.

Some downsides to decentralisation:

Even though it may seem that decentralised sync is ideal for every scenario, it is not:

• The lack of a central node can be a problem: since there is no “central node”, files are not readily accessible from “anywhere”; you have to have access to one of the actively syncing devices if you want to access your files. There are perhaps some workarounds for this, but generally this is the case.

• Syncing over the internet can be troublesome: there may be certain problems when syncing over the internet; that is: if you want to sync devices on different networks. Since there isn’t a central server that is open to the internet, you may need to work around various NATs and firewalls.

• You’re on your own: ultimately, when using decentralised sync, your data is in your hands. If you don’t keep backups and mess something up, there is usually very little that can be done. Furthermore, you are responsible for configuring everything which can be irksome if you are not tech-savvy. Keeping file revisions can also be a hassle to set up. Sometimes ease of mind is something one wants to have: going for Big Tech and trusting them with your data may be a solution.

Conclusions and personal opinions

Personally, I see the benefits of both, for various use case scenarios. There are plenty of self-hosted alternatives for centralised and decentralised sync.

The big names in terms of self-hosted centralised sync include among other:

• Nextcloud
• ownCloud

The big names in terms of self-hosted decentralised sync include among others:

• Syncthing
• resilio sync

I use both Syncthing and Nextcloud for different applications.

Finally, I encourage everyone to think about how they are storing and backing up their data; just to be mindful of how, sometimes valuable, memories and information are kept¹.