I hear people say that about Nextcloud often, which is part of why I haven’t bothered setting it up yet.
Is there a technical reason why it’s slow and clunky? Any problematic choices with how it was built?
I hear people say that about Nextcloud often, which is part of why I haven’t bothered setting it up yet.
Is there a technical reason why it’s slow and clunky? Any problematic choices with how it was built?
Synching is currently the fastest and lightest you will find, but the concept is different from Seafile or Nextcloud. With Synching there is no central server, you have resources (folders) shared between nodes on a peer-to-peer basis. This has several advantages, the most obvious one is that if a node goes down the rest continues working, but also that if a file is available in two or more nodes when a new node enters it will download that file from all the nodes in which it is available. As a disadvantage we could say that there is no web server where to see the shared files, so you will not be able to enter a URL with username and password and browse the files and upload or download. You will not be able to share files with third parties through a URL either.
I know exactly how Synching works, the point is not the p2p nature of it, the point is that Nextcloud’s sync performance and reliability isn’t even comparable because the desktop clients, sync algorithm and server side tech (PHP) won’t ever be as performant at dealing with files as Go is.
The way Nextcloud implemented sync is totally their decision and fault. Syncthing can be used in a more “client > server” architecture and there are professional deployments of that provided by Kastelo for enterprise customers with SSO integrations, web interfaces, user management and whatnot.
Nextcloud could’ve just implemented all their web UI and then rely on the Syncthing code for the desktop / mobile clients sync. Without even changing Syncthing’s code, one way to achieve this would be launch a single Syncthing instance per NC user and then build a GUI around that that would communicate with the NC API do handle key exchanges with the core Syncthing process. Then add a few share options in the context menu and done.
This situation illustrates very clearly the issue with Nextcloud development and their decisions - they could’ve just leveraged the great engine that Syncthing has a backend for sync but instead, as stubborn as they are, they came up with an half assed-solution that in true Nextcloud fashion never delivers as promised.
User management on syncthing ? I’d be interested by your source mate. This would incline me to try it. I currently use a ldap server for me and my friends. And seafile with the ldap.
You may want to read my post again as there’s currently no user management in Syncthing. I just said that Kastelo provides a payed and very proprietary solution with user management for enterprise customers.
Anyways for anyone who wants to code a solution like that it isn’t impossible, I proceeded to outline what Kastelo does on their solution and what Netcloud cloud’ve done.–
Ok, I thought it was separated from the notion of pro support, like argument 1 and argument 2. But I suppose that’s on me.
Anyway, too bad, I would have looked forward to it :D. I don’t need a client server model. But i do need replication and multi user access.
You can setup one Syncthing instance per user for that. That’s the way it was designed to work.