Their contribution agreement forces you to give up copyright to them.

The license just looks like the standard Apache license though, which doesn't require this. With the Apache license, contributors still own the copyright to their code, but they license it to the project. Did you see a document in the repo that says something different?

For posterity because I didn’t explain why/how it’s sketchy:

• they just found a hardcoded key that skips all security that was in the wild for like two years
• significant vibe coding means nobody actually understands the codebase. Hence not finding the backdoor key
• some of the documentation is only in Chinese, which isn’t sketchy in itself, but given the backdoor key does seem fucking sketchy.
• they have an X link you cannot remove from the admin console
• the admin console has minor but stupid bugs: you can’t go from a bucket to the list of buckets, auth is janky, etc.

Just because it’s good a good name doesn’t make it good pedigree (which is a bone I have with rustXYZ named projects). The fact nobody caught serious backdoors for years is damning.

If you’re running this offline, it might be fine for you. I still run it inside my vpn behind auth but I’m looking to move off.

object_store does indeed also support WebDAV among a variety of other protocols, Apache Druid or Apache Pinot probably would be better examples. My only experience with WebDAV is with Nextcloud and hasn't been that great because it has been very slow, probably should look into it sometime.

EDIT: Apparently it supports CAS, and even has a locking mechanism

No, it's made for entities managing data for thousands/millions of people. “overengineering" implies a specific scope, it's not the one you think about

Exoscale

i'll give you the second case, but nobody should plan for putting stuff on aws with the world as it looks right now...

ok, to start with, if you need a POSIX interface to the filesystem, you already have an SSH connection to that server, and don't need much stability across multiple clients, SSHFS may do just fine. For a homelab, that is likely the case.

now, if you're hosting a web server that needs data distributed across drives/nodes, data redundancy, and the usage is primarily programmatic, closer to a CDN's or machine learning pipeline than a single user browsing files; then you want an S3-compatible solution. The S3 API makes it easier to plug it into your application, while allowing you to migrate to a different one - which I'm actually currently doing for a MinIO deployment at work.

S3 is designed for being used by applications via API, for example you can easily save and retrieve files from it even with a JavaScript application. It is much more difficult to do the same with sshfs

If instead you use it mounted on a computer, S3 is worse because each time you need to list its contents that's an API request, if you have hundreds of thousands of files then it's thousands of API reuqests