Not this ol' chestnut again

Where's sftp? s3? smb?

I would highly suspect this is because they don't want to handle encryption and decryption on their servers where ever they can. Yes they need encryption for emails they receive but for every thing else they want to have as end to end protected as they can. Which means client side encryption and decryption for almost every thing. That is the big feature that a lot of people are buying into from them.

All these protocols don't feal with encryption on the client at all. Which means if they supported them they would need to handle encryption and decryption on the server side. Which I doubt they want to do and likely work hard to avoid at all.

So if something does not have full feature set at launch, it’s vibe coded?

Hmm. I think not using standard protocols but an ad-hoc API may result in vendor lock-in, which yes, is a bad thing (though it doesn't mean it's generated). For example, one of my clients has backups in AWS, and he initially asked me to upload them using standard sftp, but then we saw the bill for using the sftp add-on and had to immediately rewrite the uploads using the free but vendor-specific CLI.

Regarding the docs, I see they put them in help texts, which tbh isn't that bad, but indeed duplicating them online for convenient search would be obviously better. For my library, I put the docs all in the readme like many libs did in early years of Node.js (and I liked the docs that way), without an extra documentation website, though I have a landing page showing quick start examples.