What frustrates me is that it looks like it works, but once in a while it breaks in a way that is pretty much irreparable (or at least not in a practical way).
I want to run an iOS/Android app that backs up images on my server. I tried the iOS app and when it works, it's cool. It's just that once in a while I get errors like "locked webdav" files and it never seems to recover, or sometimes it just stops synchronising and the only way to recover seems to be to restart the sync from zero. It will gladly upload 80GB of pictures "for nothing", discarding each one when it arrives on the server because it already exists (or so it seems, maybe it just overwrites everything).
The thing is that I want my family to use the app, so I can't access their phone for multiple hours every 2 weeks; it has to work reliably.
If it was just for backing up my photos... well I don't need Nextcloud for that.
Again, alternatives just don't seem to exist, where I can install an app on my parent's iOS and have it synchronise their photo gallery in the background. Except I guess iCloud, that is.
For some reason the app disconnected from my account in the background from time to time (annoying but didn't think it was critical). Once I pasted data on Nextcloud through the Files app integration, it didn't sync because it was disconnected and didn't say anything, and it lost the data.
Syncthing sadly doesn't let you not download some folders or files, but I just moved those to other storage. It beats the Nextcloud headache.
I don't say this to diminish anyone else's contribution or criticize the software, just to call out the absolutely herculean feat this one person accomplished.
I have found that typing normally is really preferably on android and usually I didn't like having to press columns or ctrl or anything so as such since micro is really just such a great thing overall, it fit so perfectly that when I had that device, I was coding more basic python on my phone than I was on my pc
Although back then I was running alpine on UserLand and I learnt a lot trying to make that alpine vm of sorts to work with python as it basically refused to and I think I learnt a lot which I might have forgotten now but the solution was very hacky (maybe gcompat) and I liked it
For us Nextcloud AIO is the best thing under the sun. It works reasonably well for our small company (about 10 ppl) and saves us from Microsoft. I'm very grateful to the developers.
Hopefully they are able to act upon such findings or rewrite it with go :-). Mmh, if Berlin (Germany) wouldn't waste so much money in ill-advised ideology-driven and long-term state-destroying actions and "NGOs" they had enough money to fund 100s of such rewrites. Alas...
* or same, if excluding nextcloud talk, but then missing a chat feature
I find your "open-source-washed" remark deplaced and quite deragoraty. Nextcloud is, imo, totally right to (try to) monetize. They have to, they must further improve the technical backbone to stay competitive with the big boys.
IIRC they also display a banner on the login screen to all users advertising the enterprise license, and start emailing enterprise ads to all admin users.
Their "fair use policy"[1] also includes some "and more" wording.
How dare they. I just want to share photos and calendar with the 502 people in my immediate family.
My biggest gripe with having used it for far longer than I should have was always that it expected far too much maintenance (4 month release cadence) to make sense for individual use.
Doing that kind of regular upkeep on a tool meant for a whole team of people is a far more reasonable cost-benefit analysis. Especially since it only needs one technically savvy person working behind the scenes, and is very intuitive and familiar on its front-end. Making for great savings overall.
The only downside is you can‘t use apps/plugins which require additional local tools (e.g. ocrmypdf) but others can be used just fine.
Calling remotely hosted services works (e.g. if you have elasticsearch on an vps and setup the Nextcloud fulltext search app accordingly)
> NOTE: full bidirectional sync, like what nextcloud and syncthing does, will never be supported! Only single-direction sync (server-to-client, or client-to-server) is possible with copyparty
Is sync not the primary use of nextcloud?
Really impressive, but I think I'll stick to NFS.
Not affiliated, but a very happy user.
I mention iOS, because that was what I needed personally, as there was syncthing for Android since forever.
I had really good luck with Seafile[0]. It's not a full groupware solution, just primarily a really good file syncing/Dropbox solution.
Upsides are everything worked reliably for me, it was much faster, does chunk-level deduplication and some other things, has native apps for everything, is supported by rclone, has a fuse mount option, supports mounting as a "virtual drive" on Windows, supports publicly sharing files, shared "drives", end-to-end encryption, and practically everything else I'd want out of "file syncing solution".
The only thing I didn't like about it is that it stores all of your data as, essentially, opaque chunks on disk that are pieced together using the data in the database. This is how it achieves the performance, deduplication, and other things I _liked_. However it made me a little nervous that I would have a tough time extracting my data if anything went horribly wrong. I took backups. Nothing ever went horribly wrong over 4 or 5 years of running it. I only stopped because I shelved a lot of my self-hosting for a bit.
It's what I want to try next. Written in go, it looks promising.
A good idea is to have it on an always-on server and add your share as an encrypted one (like you set the password on all your apps but not on the server); this pretty much results in a dropbox-like experience since you have a central place to sync even when your other devices are not online
I use it on my phone (configured to only sync on WiFi), laptop (connected 99% of the time), and server (up 100% of the time).
The always-up server/laptop as a "master node" are probably key.
Let me know if you know of any alternative which have helped you but I haven't tried syncthing but I have heard good things about it overall so I feel like I like it already even if I haven't tried it I guess.
It makes a little more sense when you’re using their cloud version, because otherwise you’re storing the data twice.
I know people work around these iOS limitations by setting up springboard widgets that piggyback on background refresh tasks to do uploads. People also create Automator actions (e.g. run every day at time or location based) in the Shortcuts app.
I haven’t tried it but a popular option on iOS seems to be: https://apps.apple.com/app/photosync-transfer-photos/id41585...
I have it installed on my immediate family's devices to ensure all the photos are auto-backed-up to our NAS (which is then backed up to another NAS).
I need to check to make sure it's still working once in a while (every couple of months), but it's usually fine, and even if it's somehow stopped working, getting it running again catches itself up to where it should have been anyway.
Like if I backup photos from iOS, then remove a subset of those from iOS to make space on the phone (but obviously I want to keep them on the cloud), and later the mobile app gets out of sync, I don't want to end up in a situation where some photos are on iOS, some on the cloud, but none of the devices has everything, and I have no easy way to resync them.
I have had the server itself fail in strange ways where I had to restart it. I had to do a full fresh install once when it got hopelessly confused and I was getting database errors saying records either existed when they shouldn't or didn't exist when they should.
I think I am a pretty skilled sysadmin for these types of things, having both designed and administered very large distributed systems for two decades now, but maybe I am doing things wrong, but I think there are just some gotchas still with the project.
iCloud / Google Photos just don't have that, they really never lose a photo. It's very difficult for me to convince my family to move to something that may lose their data, when iCloud / Google Photos works and is really not that expensive.
client_max_body_size 50000M;
proxy_read_timeout 600s;
proxy_send_timeout 600s;
send_timeout 600s;
FWIW, my library is about 22000 items large. Hope this helps someone.
I use it for a family cloud service for chat, shared todo lists, shared calendar and shared editing docs (don't want to put anything private on e.g. google docs).
For all that, it's full of awesome.
I know, it sucks that the official apps are buggy as hell, but the server side is real solid
I've noticed the sync isn't instantaneous, but if I ping one device from the other, it starts immediately. I think Android has some kind of network related sleep somewhere, since the two nixos ones just sync immediately.
I think it takes a long time because the phone CPU is much slower than the desktop but I couldn't tell you what it's doing, the status doesn't say anything useful except noting that files are out of sync and that the other device is connected.
i have lots of txt files on my phone which are just not synced up to my server (the files on the server are 0 byte long).
i'm using txt files to take notes because the Notes app never worked for me (I get sync errors on any android phone while it works on iphone).
The Javascript performance trace shows over 50% of the work is in making the asynchronous calls to pull those calendars and other network calls one by one and then on all the refresh updates it causes putting them onto the page.
Supporting all these N calendar calls is pulls individually for calendar rooms and calendar resources and "principles" for the user. All separate individual network calls some of which must be gating the later individual calendar calls.
Its not just that, it also makes a call for notifications, groups, user status and multiple heartbeats to complete the page as well, all before it tries to get the calendar details.
This is why I think it feels slow, its pulling down the page and then the javascript is pulling down all the bits of data for everything on the screen with individual calls, waiting for the responses before it can progress in many ways to make the further calls of which there can be N many depending on what the user is doing.
So across the local network (2.5Gbps) that is a second and most of it in waiting for the network. If I use the regular 4G level of throttling it takes 33.10 seconds! Really goes to show how bad this design does with extra latency.
When it comes to JS optimization in the browser there's usually a few great big smoking guns:
1. Tons of tiny files: Bundle them! Big bundle > zillions of lazy-loaded files.
2. Lots of AJAX requests: We have WebSockets for a reason!
3. Race conditions: Fix your bugs :shrug:
4. Too many JS-driven animations: Use CSS or JS that just manipulates CSS.
Modern mobile network connections have plenty of bandwidth to deliver great big files/streams but they're still super slow when it comes to round-trip times. Knowing this, it makes perfect sense that Nextcloud would be slow AF on mobile networks because it follows the REST philosophy.
My controversial take: GIVE REST A REST already! WebSockets are vastly superior and they've been around for FIFTEEN YEARS now. Do I understand why they're so much lower latency than REST calls on mobile networks? Not really: In theory, it's still a round-trip but for some reason an open connection can pass data through an order of magnitude (or more) lower latency on something like a 5G connection.
If there's 15MB of JS that gets run immediately after page load, that's a different story. Especially if there's lots of nested calls. Ever drill down deep into a series of function calls inside the performance report for the JS on a web page? The more layers of nesting you have, the greater the overhead.
DRY as a concept is great from a code readability standpoint but it's not ideal performance when it comes to things like JS execution (haha). I'm actually disappointed that modern bundlers don't normally inline calls at the JS layer. IMHO, they rely too much on the JIT to optimize hot call sites when that could've been done by the bundler. Instead, bundlers tend to optimize for file size which is becoming less and less of a concern as bandwidth has far outpaced JS bundle sizes.
The entire JS ecosystem is a giant mess of "tiny package does one thing well" that is dependent on n layers of "other tiny package does one thing well." This results in LOADS of unnecessary nesting when the "tiny package that does one thing well" could've just written their own implementation of that simple thing it relies on.
Don't think of it from the perspective of, "tree shaking is supposed to take care of that." Think of it from the perspective of, "tree shaking is only going to remove dead/duplicated code to save file sizes." It's not going to take that 10-line function that handles with <whatever> and put that logic right where its used (in order to shorten the call tree).
Also, 15MB of JS is nothing on modern "low end devices". Even an old, $5 Raspberry Pi 2 won't flinch at that and anything slower than that... isn't my problem! Haha =)
There comes a point where supporting 10yo devices isn't worth it when what you're offering/"selling" is the latest & greatest technology.
It shouldn't be, "this is why we can't have nice things!" It should be, "this is why YOU can't have nice things!"
Please don't.
Ten years isn't what it used to be in terms of hardware performance. Hell, even back in 2015 you could probably still make do with a computer from 2005 (although it might have been on its last legs). If your software doesn't run properly (or at all) on ten-year-old hardware, it's likely people on five-year-old hardware, or with a lower budget, are getting a pretty shitty experience.
I'll agree that resources are finite and there's a point beyond which further optimizations are not worthwhile from a business sense, but where that point lies should be considered carefully, not picked arbitrarily and the consequences casually handwaved with an "eh, not my problem".
It's because a TLS handshake takes more than one roundtrip to complete. Keeping the connection open means the handshake needs to be done only once, instead of over and over again.
I was very curious so I asked AI to explain why websockets would have such lower latency than regular HTTP and it gave some (uncited, but logical) reasons:
Once a WebSocket is open, each message avoids several sources of delay that an HTTP request can hit—especially on mobile. The big wins are skipping connection setup and radio wakeups, not shaving a few header bytes.
Why WebSocket “ping/pong” often beats HTTP GET /ping on mobile
No connection setup on the hot path
HTTP (worst case): DNS + TCP 3‑way handshake + TLS handshake (HTTPS) before you can send the request. On mobile RTTs (60–200+ ms), that’s 1–3 extra RTTs, i.e., 100–500+ ms just to get started.
HTTP with keep‑alive/H2/H3: Better (no new TCP/TLS), but pools can be empty or closed by OS/radios/idle timers, so you still pay setup sometimes.
WebSocket: You pay the TCP+TLS+Upgrade once. After that, a ping is just one round trip on an already‑open connection.
Mobile radio state promotions
Cellular modems drop to low‑power states when idle. A fresh HTTP request can force an RRC “promotion” from idle to connected, adding tens to hundreds of ms.
A long‑lived WebSocket with periodic keepalives tends to keep the radio in a faster state or makes promotion more likely to already be done, so your message departs immediately.
Trade‑off: keeping the radio “warm” costs battery; most realtime apps tune keepalive intervals to balance latency vs power.
Fewer app/stack layers per message
HTTP request path: request line + headers (often cookies, auth), routing/middleware, logging, etc. Even with HTTP/2 header compression, the server still parses and runs more machinery.
WebSocket after upgrade: tiny frame parsing (client→server frames are 2‑byte header + 4‑byte mask + payload), often handled in a lightweight event loop. Much less per‑message work.
No extra round trips from CORS preflight
A simple GET usually avoids preflight, but if you add non‑safelisted headers (e.g., Authorization) the browser will first send an OPTIONS request. That’s an extra RTT before your GET.
WebSocket doesn’t use CORS preflights; the Upgrade carries an Origin header that servers can validate.
Warm path effects
Persistent connections retain congestion window and NAT/firewall state, reducing first‑packet delays and occasional SYN drops that new HTTP connections can encounter on mobile networks.
Handshake cost: TLS adds 1–2 RTTs (TLS 1.3 is 1‑RTT; 0‑RTT is possible but niche). If you open and close HTTP connections frequently, you keep paying this. A WebSocket pays it once, then amortizes it over many messages.
After the connection is up, the per‑message crypto cost is small compared to network RTT; the latency advantage mainly comes from avoiding repeated handshakes.
For tiny messages, both HTTP and WS fit in one MTU. The few hundred extra bytes of HTTP headers rarely change latency meaningfully on mobile; the dominant factor is extra round trips (connection setup, preflight) and radio state.
If your HTTP requests reuse an existing HTTP/2 or HTTP/3 connection, have no preflight, and the radio is already in a connected state, a minimal GET /ping and a WS ping/pong both take roughly one network RTT. In that best case, latencies can be similar.
In real mobile conditions, the chances of hitting at least one of the slow paths above are high, so WebSocket usually looks faster and more consistent.>Yes and no: There's still a rather large latency improvement even when you're using plain HTTP (not that you should go without encryption).
Of course. An unencrypted HTTP request takes a single roundtrip to complete. The client sends the request and receives the response. The only additional cost is to set up the connection, which is also saved when the connection is kept open with a websocket.
/s
Having used WebSockets a lot, I’ve realised that it’s not the simple fact that WebSockets are duplex or that it’s more efficient than using HTTP long-polling or SSEs or something else… No, the real benefit is that once you have a “socket” object in your hands, and this object lives beyond the normal “request->response” lifecycle, you realise that your users DESERVE a persistent presence on your server.
You start letting your route handlers run longer, so that you can send the result of an action, rather than telling the user to “refresh the page” with a 5-second refresh timer.
You start connecting events/pubsub messages to your users and forwarding relevant updates over the socket you already hold. (Trying to build a delta update system for polling is complicated enough that the developers of most bespoke business software I’ve seen do not go to the effort of building such things… But with WebSockets it’s easy, as you just subscribe before starting the initial DB query and send all broadcasted updates events for your set of objects on the fly.)
You start wanting to output the progress of a route handler to the user as it happens (“Fetching payroll details…”, “Fetching timesheets…”, “Correlating timesheets and clock in/out data…”, “Making payments…”).
Suddenly, as a developer, you can get live debug log output IN THE UI as it happens. This is amazing.
AND THEN YOU WANT TO CANCEL SOMETHING because you realise you accidentally put in the actual payroll system API key. And that gets you thinking… can I add a cancel button in the UI?
Yes, you can! Just make a ‘ctx.progress()’ method. When called, if the user has cancelled the current RPC, then throw a RPCCancelled error that’s caught by the route handling system. There’s an optional first argument for a progress message to the end user. Maybe add a “no-cancel” flag too for critical sections.
And then you think about live collaboration for a bit… that’s a fun rabbit hole to dive down. I usually just do “this is locked for editing” or check the per-document incrementing version number and say “someone else edited this before you started editing, your changes will be lost — please reload”. Figma cracked live collaboration, but it was very difficult based on what they’ve shared on their blog.
And then… one day… the big one hits… where you have a multistep process and you want Y/N confirmation from the user or some other kind of selection. The sockets are duplex! You can send a message BACK to the RPC client, and have it handled by the initiating code! You just need to make it so devs can add event listeners on the RPC call handle on the client! Then, your server-side route handler can just “await” a response! No need to break up the handler into multiple functions. No need to pack state into the DB for resumability. Just await (and make sure the Promise is rejected if the RPC is cancelled).
If you have a very complex UI page with live-updating pieces, and you want parts of it to be filterable or searchable… This is when you add “nested RPCs”. And if the parent RPC is cancelled (because the user closes that tab, or navigates away, or such) then that RPC and all of its children RPCs are cancelled. The server-side route handler is a function closure, that holds a bunch of state that can be used by any of the sub-RPC handlers (they can be added with ‘ctx.addSubMethod’ or such).
The end result is: while building out any feature of any “non-web-scale” app, you can easily add levels of polish that are simply too annoying to obtain when stuck in a REST point of view. Sure, it’s possible to do the same thing there, but you’ll get frustrated (and so development of such features will not be prioritised). Also, perf-wise, REST is good for “web scale” / high-user-counts, but you will hit weird latency issues if you try to use for live, duplex comms.
WebSockets (and soon HTTP3 transport API) are game-changing. I highly recommend trying some of these things.
* If the browser has an optimal path for it, use HTTP (e.g. images where it caches them automatically or file uploads where you get a "free" progress API).
* If I know my end users will be behind some shitty firewall that can't handle WebSockets (like we're still living in the early 2010s), use HTTP.
* Requests will be rare (per client): Use HTTP.
* For all else, use WebSockets.
WSDispatcher.on("pong", pongFunc);
It makes reasoning about your API so simple and human-readable! It's also highly performant and fully async. With a bit of Promise wrapping, you can even make it behave like a synchronous call in your code which keeps the logic nice and concise.
In my latest pet project (collaborative editor) I've got the WebSocket API using a strict "call"/"call:ok" structure. Here's an example from my WEBSOCKET_API.md:
### Create Resource
```javascript
// Create story
send('resources:create', {
resource_type: 'story',
title: 'My New Story',
content: '',
tags: {},
policy: {}
});
// Create chapter (child of story)
send('resources:create', {
resource_type: 'chapter',
parent_id: 'story_abc123', // This would actually be a UUID
title: 'Chapter 1'
});
// Response:
{
type: 'resources:create:ok', // <- Note the ":ok"
resource: { id: '...', resource_type: '...', ... }
}
```
const wsPromise = getWsService(); // Returns the WebSocket singleton
// Create resource (story, chapter, or file)
async function createResource(data: ResourcesCreateRequest) {
loading.value = true;
error.value = null;
try {
const ws = await wsPromise;
const response = await ws.request<ResourcesCreateResponse>(
"resources:create",
data // <- The payload
);
// resources.value because it's a Vue 3 `ref()`:
resources.value.push(response.resource);
return response.resource;
} catch (err: any) {
error.value = err?.message || "Failed to create resource";
throw err;
} finally {
loading.value = false;
}
}
Aside: There's still THREE firewalls that suck so bad they can't handle WebSockets: SophosXG Firewall, WatchGuard, and McAfee Web Gateway.
Then at some point the Nextcloud calendar was "redesigned" and now it's completely terrible. Aesthetically, it looks like it was designed for toddlers. Functionally, adding and editing events is flat out painful. Trying to specify a time range for an event is weird and frustrating. It's better than not having a calendar, but only just.
There are plenty of open source calendar _servers_, but no good open source web-based calendars that I have been able to find.
Efforts like Electric SQL to have APIs/protocols for bulk fetching all changes (to a "table") is where it's at. https://electric-sql.com/docs/api/http
It's so rare for teams to do data loading well, rarer still we get effective caching, and often a products footing here only degrades with time. The various sync ideas out there offer such an alluring potential, of having a consistent way to get the client the updated live data they need, in a consistent fashion.
Side note, I'm also hoping the js / TC39 source phase imports proposal aka import source can help let large apps like NextCloud defer loading more of it's JS until needed too. But the waterfall you call out here seems like the real bad side (of NextCloud's architecture)! https://github.com/tc39/proposal-source-phase-imports
The issue remains that the core itself feels like layers upon layers of encrusted code that instead of being fixed have just had another layer added ... "something fundamental wrong? Just add Redis as a dependency. Does it help? Unsure. Let's add something else. Don't like having the config in a db? Let's move some of it to ini files (or vice versa)..etc..etc." it feels like that's the cycle and it ain't pretty and I don't trust the result at all. Eventually abandoned the project.
Edit: at some point I reckon some part of the ecosystem recognised some of these issues and hence Owncloud remade a large part of the fundamentals in Golang. It remains unknown to me whether this sorted things or not. All of these projects feel like they suffer badly from "overbuild".
Edit-edit: another layer to add to the mix is that the "overbuild" situation is probably largely what allows the hosting economy around these open source solutions to thrive since Nextcloud and co. are so over-engineered and badly documented that they -require- a dedicated sys-admin team to run well.
For example the reason there's no cohesiveness with a common websocket bus for all those ajax calls is because they all started out as a separate plugin.
NC has gone full modularity and lost performance for it. What we need is a more focused and cohesive tool for document sharing.
Honestly I think today with IaC and containers, a better approach for selfhosting is to use many tools connected by SSO instead of one monstrosity. The old Unix philosophy, do one thing but do it well.
1. Did you open back port request with these basic patches? If you have orders of magnitude speed improvements it would be aswesome to share!
2. You definitively don't need an entire sysadmin team to run nextcloud, in my work (large organisation) there's three instances running (for different parts/purposes of which only one is run by more than one person, and I run myself both my personal instance and for a nonprofit with ~100 persons, it's really not much work after setup (and other systems are plenty of a lot more complicated systems to set up, trust me)
2. Guess that's debatable, or maybe even skill dependent (mea culpa), and also largely a question of how comfortable one is with systems that cannot be reasoned about cleanly (similar to TFA I just could not stand the bloat, it made me feel more than mildly unwell working with it). Eventually it was GDPR reqs that drove us towards the big G across multiple domains.
On another note it strikes me how the attempts at re-gen'ing folder listings online really is Sisyphus work, there should be a clean way to enfold multiuser/access-tokens into the filesystems of phones/PCs/etc. The closest pseudo example at the moment I guess is classic Google Drive but of course it would need gating and security on the OS side of things that works to a standard across multiple ecosystems (Apple, MS, Android, iPhone, Linux etc.) ... yeeeeah, better keep polishing that HTML ball of spaghetti I guess ;)
From my experience, this doesn't meaningfully impact performance. Performance problems come from "accidentally quadratic" logic in the frontend, poorly optimised UI updates, and too many API calls.
Overeager warming/precomputation of resources on page load (rather than on use) can be a culprit as well.
About 50-100 people saying that they know exactly why NC is slow, bloated, bad, but fail to a) point out a valid alternative, b) to act and do something about it.
I'm going to say that I love NC despite its slow performance. I own my storage, I can do Google Drive stuff without selling my soul (aka data) to the devil and I can go patch up stuff, since the code is open.
Is downloading lots of JS and waiting a few seconds bad? Yes. But did I pay for any of it? No. Am I the product as a result of choosing NC? Also no.
Having a basic file system with a dropbox alternative and being able to go and "shop" for extensions and extra tools feels so COOL and fun. Do I want to own my password manager? Bam, covered. Do I want to centralise calendar, mail and kanban into one? Bam, covered.
Codebase is AGPL, installs easily and you don't need to do surgery every new update.
I've been running it without hiccups for over 6 years now.
Would I love it to be as fast and smooth as a platform developed by an evil tech behemoth which wants to swallow everyone's data? Of course, am I happy NC exists? Yes!
And if you got this far, dear reader, give it a try. It's free and you can delete it in a second but if you find something to improve and know how, go help, it helps us all :)
Eventually I ran into FileRun and loved it, even though it wasn't completely open source. FileRun is fast, worked on both desktop and mobile via browser nicely, and I never had an issue with it. It was free for personal use a few years ago, and unfortunately is not anymore. But it's worth the license if you have the money for it.
I tried setting up SeaFile but I had issues getting it working via a reverse proxy and gave up on it.
I like copyparty (https://github.com/9001/copyparty) - really dead simple to use and quick like FIleRun - but the web interface is not geared towards casual users. I also miss Filerun's "Request a file" feature which worked very nicely if you just wanted someone to upload a file to you and then be done.
With the disclaimer that I've never used Filerun, I think this can be replicated with copyparty by means of the "shares" feature (--shr). That way, you can create a temporary link for other people to upload to, without granting access to browse or download existing files. It works like this: https://a.ocv.me/pub/demo/#gf-bb96d8ba&t=13:44
The only precaution I can think of is that copyparty's .hist folder should probably not be synced between devices. So if you intend to share an entire copyparty volume, or a folder which contains a copyparty volume, then you could use the `--hist` global-option or `hist` volflag to put it somewhere else.
As for high CPU usage, this would arise from copyparty deciding to reindex a file when it detects that the file has been modified. This shouldn't be a concern unless you point it at a folder which has continuously modifying files, such as a file that is currently being downloaded or otherwise slowly written to.
On the other hand, Nextcloud is so far from being something like Google Docs, and I would never recommend it as a general replacement to someone who can't tolerate "jank", for lack of a better word. There are so many small papercuts you'll notice when using it as a power user. Right off the top of my head, uploading large files is finicky, and no amount of web server config tinkering gets it to always work; thumbnail loading is always spotty, and it's significantly slower than it needs to be (I'm talking orders of magnitude).
With all that said, I'm so grateful for Nextcloud since I don't have a replacement, and I would prefer not having all our baby and vacation pictures feeding some big corporation's AI. We really ought to have a safe, private place to store files in 2025 that the average person can wrap their head around. I only wish my family took better advantage of it, since I'm essentially providing them with unlimited storage.
they claim they can do it all when it comes to pictures and videos etc
I have heard of Immich though, perhaps I owe it an honest try someday.
Unlike Nextcloud, I feel I can rely on it and feel I can upgrade without issues
I will say though, Nextcloud is almost painless when it comes to management. I’ve had one or two issues in the past, but their “all in one” docker setup is pretty solid, I think. It’s what I’ve been using for the last year or so.
Why does Nextcloud, or even just parts of it, not have dozens of alternatives?
But people rarely use the web apps. Instead, it's used more like a NAS with the desktop sync client being the primary interface. Nobody likes the web apps because they're slow. The Windows desktop sync client has a really annoying update process, but other than that is excellent.
I could replace it with a traditional NAS, but the main feature keeping me there is an IMAP authentication plugin. This allows users to sign in with their business email/password. It works so well and makes it so much easier to manage user accounts, revoke access, do password resets, etc.
Web apps don't have to be slow. I prefer web apps over system apps, as I don't have to install extra programs into my system and I have more control over those apps:
- a service decides it's a good idea to load some tracking stuff from 3rd-party? I just uMatrix block it;
- a page has an unwanted element? I just uBlock block it;
- a page could have a better look? I just userstyle style it;
- a page is missing something that could be added on client side? I just userscript script it
Here is a blog post I wrote at the time about the vulnerability (CVE-2020-8155): https://tripplyons.com/blog/nextcloud-bug-bounty
I could not find a way to do this without pdf.js.
So I guess it is possible
What is the problem with that exactly in your case?