What do you primarily use a cloud drive for?

[axpnet]

Spinning this off from the AeroCloud design thread (#405). The way you sync depends heavily on what you use a cloud drive for, and those uses are not interchangeable. Vote above for your single primary use, then let's go deeper in the comments.

A first cut at the use cases

1. Backup (one-way, archival). The cloud copy is a safety net. Local is the source of truth, the remote only receives. Efficiency matters more than latency: once per hour is fine, real-time is wasteful. This is where transformative overlays (client-side encryption, compression) shine, because the remote is dumb storage you never browse directly.

2. Bidirectional sync between your own devices. Keeping a laptop and a desktop in step. Over a shared LAN this is arguably better served by a direct peer tool (Syncthing) than by round-tripping through a cloud drive. Over WAN, where the devices are not on the same network, a cloud drive becomes a reasonable middle point.

3. Access / roaming. Not full sync, just "reach my files from anywhere." A mount or on-demand fetch often beats copying everything down.

4. Sharing with others. Handing a folder to another person. Encryption changes shape here, because the key has to travel too.

5. Publishing / distribution. One-to-many, mostly read. Different again.

The questions

• Where do you draw the line between "use Syncthing over LAN" and "use a cloud drive"? Is it strictly LAN vs WAN, or something else (trust, number of devices, always-on vs occasional)?
• When you use a cloud drive purely as backup, do you want it one-way and encrypted by default, or do you still expect to browse and restore individual files from the provider side?
• Should the transformative overlays (encryption, compression) apply to every use case, or only to backup?
• Any use I have not listed that matters to you?

My working assumption, which I want to pressure-test: the highest-value default for a cloud drive is one-way, encrypted backup to a dumb store, and bidirectional device sync is a secondary mode best kept local where possible. Tell me where that is wrong.

[EhudKirsh]

Uses of cloud drives, ranked from the simplest to the most complicated:

1) Backups

This is "easily" achievable with the overlays being utilised.
You should mention the terms Restic and Kopia here, because this is their main purpose.

2) Bisyncing devices

Although this use is possible, it's not advised when devices share the same LAN, as they can and should use Syncthing instead.
Syncthing is fast, it saves many sync conflicts that tend to happen when bisyncing devices using two-way cloud syncing, it saves download bandwidth, it doesn't rely on WAN access, and it lets rclone sync be stateless and not waste byte size on having a cache folder like
rclone bisync creates. So I only address this possible use here for the sake of completion and not as something I use.

Note that Syncthing was designed to be able to bisync devices and servers directly, but this requires the devices to be on at the same time.
If you have 3 devices that are never all On at the same time, but there is overlap such that either 1 & 2 and 2 & 3 are On together some of the time, or 1 & 2, 2 & 3 and 1 & 3, then they can all sync nicely over LAN or WAN without needing cloud drives. Cloud drives are inefficient even when we exclude LAN because now you need to manage and possibly pay for an extra service, which can have connection problems and other issues, and needs encryption at rest for privacy, just for the privilege of having a middleman to park files with so they can stay somewhere during syncing. The overlays, like Crypt, slow down bisyncing. At that point, it makes sense to keep the files there for backups.

3) Accessing and Mounting

Another word for it can be browsing, previewing, and even making light edits, such as renaming and deleting.
A major aspect here is the use of photo galleries for yearly memories, which some cloud drives, like pCloud Drive have.
This is also an important reason for the existence of Media Services like Immich.

4) Sharing with specific people

This is what some cloud drives feature, like OpenDrive, Biggly by Blomp, pCloud Transfer (not Drive - https://transfer.pcloud.com), etc. Honestly, I prefer to use messenger apps to send files, but I suppose these are also decent ways to share large files.

5) Publishing - sharing with the general public

I realised last year that if you want to back up information that isn't a secret, you can publish it on various websites, and that is a form of cloud backup. E.g. videos on YouTube, images on social media, academic publications, blogs, and most notably here, the ideas, code and scripts we share on GitHub. There are websites like the Internet Archive essentially dedicated exactly to this.
YouTube can be used as a cloud backup both for publishing and for keeping in playlists videos and music that someone downloaded.

I also realised recently that much like various game launchers save game progress, achievements and total time played to their cloud, if a gamer downloads DRM-free games and backs up those executables, having an account on which these games are registered is also a form of cloud backup. This is especially applicable to GOG, which is designed for DRM-free games.
This is relevant here because much like GOG can publish game achievements and time played on websites like https://www.exophase.com, and much like it saves game progress to its cloud, it essentially backs up DRM-free executables in the accounts of gamers.

So this mindset has a place in a diagram that I wish to publish of an ideal holistic backup setup, which includes what I write in the next point.

---

Answers to your questions:

1) LAN, WAN and Syncthing

For my personal usage currently, I bisync my PC and phone using Syncthing (📱<-SyncthingSend&Receive->💻) and one-way sync both to cloud drives using Rclone (📱-rclone sync->☁ and 💻-rclone sync->☁). 📱<->💻, 📱->☁ and 💻->☁ for short if you like.
A major assumption here is that my phone is always On and is always reachable by my PC via LAN whenever my PC is On.

I plan to simplify this by replacing rclone sync with AeroSync soon. I use Termux, RSAF and a few other apps to schedule rclone sync on Android. I published how to schedule and automate scripts in Termux at https://github.com/EhudKirsh/Termux-Plugins-and-Automation before paying attention to AeroFTP. I was going to expand that repo and also publish an ideal guide on syncing with Syncthing, FreeFileSync, Rclone and Kopia. Those were going to be the 4 apps that I planned to publish a repo about. This gets to #321, where I noticed that there aren't good user guides on this topic, so I decided to publish repos on this. When I discovered that AeroFTP supports kDrive and a few other cloud drives that Rclone doesn't, I thought that I would just add AeroFTP to that guide as just another app. But once I realised how fast you work, and your open-mindedness in #272, this changed everything, and so my plan to publish that repo is put on hold.
I now see that AeroFTP isn't here to only take part, but to take over. So it seems that AeroFTP will be the main app of that guide.
These 📱<->💻, 📱->☁ and 💻->☁ were part of a Syncing.svg flowchart that I sketched, where each arrow is either one-way or two-way and is labelled with the name of an app. I think to replace it with members of the AeroFamily, namely AeroSync and AeroShare. We'll see. Then again, I might still use Rclone to sync to remotes which the Rclone community reverse-engineered well, which AeroFTP doesn't support because reverse-engineering goes against your philosophy/ethos and you want to keep AeroFTP clean.

Notice that when the arrows between the personal devices and the cloud are one-way (rclone sync), as opposed to
two-way (rclone bisync), the --update Rclone flag should be used, which I already mentioned before. It's weird to me that it's not the default behaviour, but mirroring is. This is because if you edit a note on your phone when you're going out, sync to the cloud, and then lose the phone, it will be a shame if you end up losing the note too when opening the PC, and it overrides the note with an older version because you set syncing to mirror instead of to update. So in such a scenario, it's important to pause the syncing schedule on the PC, sync and update manually from the cloud to the local PC, and then resume the regular syncing schedule.

Recall point 4 on deduplication that I wrote in #272 (comment). A setup such as 📱<->☁<->💻 wastes download bandwidth compared to the ideal: 📱<->💻, 📱->☁ and 💻->☁. This is all stuff that I rationalised by myself without any input from others, even AI.
I have another big idea here, but I'll keep it to myself for now.

2) One-way backups, encryption and browsing/mounting

I encrypt my cloud backups because I don't see a reason not to encrypt them. Some users may fear that they'll lose their backup key, which is a topic for another thread, or the decryption instructions/salt, which I responded to in #276. Another overlay that should pretty much always be On, though that's not to say that it should be On by default, is chunking. You can argue that a compression wrapper should also always be On, and it'll skip certain file formats, which is key. Otherwise, it makes no sense to always leave compression on.
Error Correction makes less sense for cloud backups because cloud drives likely already implement it or equivalents of it, and cloud storage is scarcer and more expensive per byte than external hard drives. For external hard drives, there is no one but the user to implement error correction, so that's the main place to implement it. Having said that, if a user happens to have a very large storage quota in a cloud drive and they don't see themselves realistically using all of it, it won't hurt much to apply error correction there as well, just in case.

The question is: where will you want to preview files from? If you have files encrypted on a cloud drive and you decrypt and preview them on a public library computer, doesn't that compromise the privacy? If not, there are two cloud drives with exactly this feature: S3Drive and Koofr Vault. Both have apps, websites and even a PWA in the case of S3Drive that can decrypt Rclone's encryption, which is a unique feature.
Then again, this is something that AeroFTP can solve for all cloud drives. Imagine having a portable version of AeroFTP, or otherwise, stored in the Persistent Storage on a TailsOS USB stick or installed on RAM when booting from TailsOS, in a public library PC, or in a university's computer lab or on the computer of a friend or family member when visiting them. This can be a private way to browse, preview and edit files from a computer that doesn't belong to the user. This can be yet another example where AeroFTP can implement a feature that only some cloud drives currently have, for all the cloud drives that AeroFTP supports. Who knows? Maybe if AeroFTP becomes that good,
it can come preinstalled in TailsOS, though not likely soon. It will need to be perfected first and grow its user base.
Also, a prerequisite for an app to be pre-installed in TailsOS is to be available upstream in the Debian repo
(the search box in https://www.debian.org/distrib/packages), like I see Rclone there, but not AeroFTP.

Basically, the paragraph above considers the most complicated environments for mounting and browsing encrypted cloud drives.
Perhaps a TailsOS or a similar booting option can be the solution to privately use a possibly hostile computer for private real-time collaboration, including over LAN, using E2EE. That can be a new front for pushing the technologies that we have today, which I just envisioned during this brainstorming. AeroFTP already allows decrypting and privately browsing cloud drives on devices that users own.
I currently use RSAF on Android to mount and browse Rclone remotes via the SAF.

3) Should the 4 overlays only be used for backups or also for anything else?

I think the 4 overlays only make sense to use when storing or backing up files somewhere, even briefly, where you don't want the middleman to be able to view these files, because all 4 overlays affect what the files are like at rest.
During P2P transfer, E2EE is sufficient. For publishing files, they need to be in plaintext for others to view.

4) Team Collaboration - a major use for cloud drives that you didn't mention

Working on a joint project and editing office suite files at the same time, together with other team members, is a very frustrating use case currently. I speak from experience of having completed two Chemical Engineering Design projects in my Bachelor's degree.
In the first, my team used Google Docs and Google Drive. In the second, my team used Office 365 and OneDrive.

Besides the fact that we didn't have time or need to bother using client-side encryption like Rclone had, we've also never heard about it because it was so new. The timeline was as follows: Rclone was released in 2014, Rclone Crypt was introduced in 2016, and my Design projects were between 2018 and 2020. I realise that I’m ageing myself now. Rclone didn't have as user-friendly GUI apps back then as it has today, and they're still far from perfect. The projects we had were just to graduate, so they weren't ground-breaking in Chemical Engineering, but we can imagine that some projects are classified and are very important to keep private.
In that case, normal use of library computers is out of the question, and using personal laptops is really the only way to keep collaborative work private when working on it while going out.

So what are the solutions here? There needs to first and foremost be a way to collaborate in real time over LAN rather than over WAN.
When we started these projects, we used to go to the same computer labs on campus to speak with each other in person while working,
but that changed, and we finished the last project over long-distance using Zoom when COVID-19 hit.
It makes me wonder what it would be like if we were to use LAN because we sat in the same room.
Real-time collaboration should use LAN where possible for the same benefits as any LAN app: no online reliance, faster syncing, etc.
LAN can allow each team member to use cloud drives for backups independently of any other member.
But what if a project starts as LAN and then finishes over WAN due to circumstances like COVID-19?
Now, cloud backups of completely different natures might need to be united in a hurry, so it might make sense to start with a unified cloud backup to begin with, as I did with my two team projects. There might need to be a cloud drive that allows private real-time collaboration, starting with editing simple files like text, which IDEs can edit, and then moving to office suites.

This begs the question of what's the best way to design collaboration over LAN and over WAN, and what's within the domain of AeroFTP? You can argue that it's all in the domain of AeroFTP because it all involves file management. I think AeroFTP should try to concentrate on the overlays specifically, because it seems to specialise in cloud backups and essentially be able to replace Rclone, Restic and Kopia.

Part of what frustrated me in these projects, besides the non-ideal aspects of cloud syncing, was that the office suite apps are far from perfect, unlike simple text editing in IDEs.
So this leads to a topic that's bigger than us, which is: how to improve office suite apps and their integration of real-time collaboration.

Another use of cloud drives

There is yet another massive use for cloud drives that I’ve hinted at at various points, and you will likely guess it if I share even slightly more clues here, so I’ll keep it mysterious for now…

[axpnet]

Thanks Ehud, this deserves a point by point answer.

One honest premise up front, because it colors everything else: AeroFTP today is a desktop app (Linux, Windows, macOS). In your diagram the arrows have a phone side that we do not cover, so that side stays on your current stack (Termux, RSAF, Syncthing). Wherever I mention AeroSync or AeroShare below, I mean the desktop side, not a replacement for your Android. I am saying it now so I do not sell you things we do not do.

On the uses, from simplest to most complex.

1. Backups. Agreed, this is the core case and it is exactly where the overlays pay off. Happy to add Restic and Kopia as references: AeroFTP aims at the same ground while staying a multi provider file manager, not only a backup engine. To be precise about what runs today: encryption and compression run in the overlay stack; error correction already exists but in the sync and CLI path, not yet as a stack layer; chunking as an overlay layer is deferred for now.

2. Bisyncing devices. Agreed on the principle: on LAN Syncthing is the right choice and using the cloud as a middleman is waste. On the desktop side AeroShare moves in that direction (LAN first): it is always on with a hub and a receiver indicator, it uses mDNS discovery on LAN and an E2EE transport over iroh. But it is desktop to desktop, so it does not replace the role Syncthing plays toward your phone. Your point that overlays like Crypt slow bisyncing is correct, and it is another reason it makes more sense to keep the files there for backups in that scenario.

3. Accessing and mounting, browsing, previewing, light edits. AeroFTP already does the important part here: you can navigate, preview and make light edits (rename, delete, edit and save) on an encrypted remote via the Crypt overlay, with on the fly decryption (plaintext paths into the app, ciphertext on the wire). The yearly memories photo gallery in the pCloud style and the Immich territory are a great suggestion: I am noting it as an idea, not a promise.

4. Sharing with specific people. OpenDrive, Biggly by Blomp, pCloud Transfer are good references. We already have direct user to user P2P sending with E2EE inside AeroShare (right click a file, Send via AeroShare): a per transfer key sealed to the recipient, and the ACK only after decrypt and integrity verification. It is marked Beta preview (v4.1.0) and it is desktop to desktop, but it is built and works end to end, not a mockup. I also share your instinct that a messenger app is often enough.

5. Publishing, sharing with the general public. I really like this category and the way you frame it: YouTube, the Internet Archive, GitHub, and the idea that a GOG account with registered DRM free executables is effectively a form of backup. It is a viewpoint that usually does not make it into backup diagrams but should. I am looking forward to your ideal holistic backup setup diagram.

Answers to your questions.

1. LAN, WAN and Syncthing. Your setup (phone and PC with Syncthing, phone to cloud and PC to cloud with Rclone) is clean, and the assumption that the phone is always on and reachable over LAN is the key that makes it work. One real limit on my side though: AeroSync runs on desktop, so it can replace rclone sync on the PC to cloud arrow, but not on the phone. The phone to PC and phone to cloud arrows stay on your stack for now (Syncthing, Termux, RSAF). I will not promise a mobile replacement I do not have. On the update flag: I understand why it feels odd that the default is mirror and not update. Mirror as default has its own logic (it faithfully reflects the source), but in your scenario of editing a note on the phone and then losing it the risk is real, and the discipline of pausing the schedule on the PC, updating manually from the cloud, then resuming, is the right way to handle it. I also refer back to your deduplication point 4 in [ROADMAP] Wrappers/Overlays #272: phone to cloud to PC wastes download bandwidth compared to phone to PC plus phone to cloud plus PC to cloud, an analysis I share. AeroFTP going from just another app in the guide to the main app is an honor, and I will hold on to the fact that you decided it looking at [ROADMAP] Wrappers/Overlays #272 and the pace of work. On the possible residual use of Rclone for the well reverse engineered remotes: that is consistent, we keep that line clean on purpose for philosophy reasons.

2. One way backups, encryption, browsing and mounting. I agree that encrypting backups should be on almost always. On chunking I agree in principle, but I will be transparent: today it is not a standalone overlay layer (it is deferred); the compression overlay already uses block wise zstd internally. On the compression wrapper you hit a practical point, and here is how we actually solve it: instead of a list of formats to skip, the overlay tries to compress and keeps the result only if the file gets smaller; if zstd does not help (already compressed media, archives) it stores the raw bytes, so an already compressed file never grows. Same goal as your skip certain formats, but decided on the real outcome rather than a static list that ages. On error correction your distinction is right: it makes more sense on external drives, where nobody else does it, than on the cloud where space is scarcer and redundancy often already exists; and if someone has a large quota they will never fully use, applying it just in case does no harm. On our side error correction already exists as a feature (sync, CLI, MCP), so the case where you still want a safety net is covered. The question where will you preview from is the right one: decrypting on a public library PC compromises privacy. S3Drive and Koofr Vault decrypting Rclone crypt are great examples, and your scenario of a portable AeroFTP on TailsOS (Persistent Storage or in RAM) is fascinating: it is exactly the kind of feature that only some clouds have today which we could bring to every supported provider. The desktop premise applies here too. The Debian upstream prerequisite for being preinstalled in TailsOS is a concrete and useful data point, thank you: a distant target, but I am not dismissing it.

3. Should the 4 overlays be used only for backups or also for anything else. I agree with you: the overlays only make sense when you deposit or store files somewhere, even briefly, where you do not want the middleman to see them, because they act on the at rest state. For P2P transfer E2EE is enough. For publishing the files must be in plaintext. Clean and correct framing.

4. Team collaboration. This is the case I did not actually put on the list, and you are right to call it out. Your experience with the two Chemical Engineering design projects (Google Docs and Drive, then Office 365 and OneDrive, and the remote finish over Zoom during COVID) frames the problem well: real time collaboration should live on LAN where possible, with each member free to run their own cloud backups independently, and the knot becomes uniting backups of different natures in a hurry when a project moves from LAN to WAN. I also agree on the scope boundary: AeroFTP should focus on the overlays and the file layer (LAN first, E2EE), not become an office suite editor. How to improve office suites and their real time collaboration is honestly bigger than us, as you say.

On the other mysterious use, you left the bait and I am happily taking it: I will not try to guess in public, I will wait for you to reveal it.

Thank you for the depth of this comment, this is the kind of brainstorming that makes me work better.