Why Seafile is unique among file sync solutions

As a user of Nextcloud (self-hosted), the most important feature for me is in direct conflict with OP's. I want my files stored verbatim as files on the server and accessible as normal files on a normal FS. No chunks, not encrypted, with the same directory structure as my cloud space. My main issue with availability and durability, not security. Of course I care about security, but losing my large collection of personal and family photos would be a much bigger disaster than some hacker having a copy.

When I tried Seafile, they had some FUSE implementation that allows access to the chunked files as a virtual FS, but I couldn't get it to work, so I dumped the whole thing. Nextcloud was so much easier to set up.

Having it this way makes it much easier to verify everything is readable properly and easier to replicate it to external drives and backups, also ensure things are accessible there.

Having different open source implementations with different tradeoffs is great, isn't it. That being said, I don't love Nextcloud's performance and some of its other design decisions, but it's the best I've found so far.

Even leaving aside that the password is sent to the server when using the web ui, seafile's security leaves a lot to be desired.

For example file names, modification dates, sizes, and other meta data is NOT encrypted. This is a big deal if you sync something like your home folder (things like your browser cache or even Downloads folder may leak a LOT of info).

The defaults on the (self-hosted) server are also very insecure and there's no mention of anything in the installation guide.

It's a shame because Seafile is so much better than things like nextcloud in my experience and there truly is nothing else like it; It really is just as convenient as using google drive!

An interesting take from the post is that nobody other than Seafile is even attempting to cater to the author's requirement. Perhaps it is a very niche requirement? Alternatively, that implementing the requirement in a clean-and-perfect manner is either not possible with the current state of the tech OR it is complicated enough that nobody else bothers to do it given the lack of demand?

It seems that although Seafile's implementation leaves something wanting (I think Option #1 of never sending the key to the server may be a superior option), the sheer fact of the feature's availability trumps the sub-optimality of its implementation. The author also implies that the implementation is "good enough" for his (and presumably most others') use cases.

I like the point here a lot. The exploration. Even if I disagree a bit about option #2 (giving keys short-term to servers) being a good way to do things.

Being able to browse on the web & also have encrypted files is an interesting challenge.

The option #2 here, of sending the key to the server but making it short lived, is hopeful. Ideally though, I guess I'd hope that the server would just send me a bunch of encrypted metadata, let my client decode it & browse the file tree, then requested encrypted chunks as it wanted. The Option #1, making the server oblivious, feels much better. Rather than trusting that the server will delete my key eventually.

And #1 should allow #2 like systems... we should be able to make separate apps, apart from the storage system, that can intermediate, if we need to.