it's a way for them to name a plant so that it has obvious technological associations
It actually has obvious mythological associations, but feel free to limit yourself to physical units. In common speech, "megas" meant nothing more than simply "big", while "gigas" meant "a Giant". I guess the obvious English adjective would be "effing huge".
Yes, but is it 1000 times bigger or 1024 times bigger? That's the important part!
I'm not sure we're familiar with the size of the Ancient Greek Gigantes with such precision.
And yet Israel insists on controlling the territory. They may not get a vote but they ARE Israeli citizens until such time as Israel actually stops trying to control their political processes and truly leaves.
And Afghani are US citizens until the US actually stops trying to control their political processes and truly leaves. You logic is impeccable!
The reason that most extensions exist is that there is (or was) no way of implementing things that people want with standard C. Inline assembly is one example. All modern C compilers support it, but GCC and Microsoft's compilers use different syntax (most other compilers implement one or the other, sometimes both). Without it, you require that every time you want to use even a single instruction of platform-specific assembly code, you must write an entire function and call it.
Atomics were another big reason for extensions. Prior to C11, if you wanted atomic operations, you needed either assembly or non-standard compiler intrinsics. Efficient vector support is another one.
Please correct me if I'm wrong because I may not have imagined this system properly. I was thinking the idea was that you encrypt each file with a single unique key, and then to use a public-key encryption scheme to encrypt that key. You can then send the encrypted file and the encrypted key to another user, knowing that it will need that users private key to decrypt.
Every time you upload a file, you generate a random symmetric key. You encrypt the file with this key and the key with your public key. If you want to download the file, you get the file and the encrypted key and then you decrypt the key with your private key and then decrypt the file. When you create the account, you upload your public key.
When you want to share a file with everyone, with no access control, you download the encrypted key, decrypt it, and provide it to the server. The server can then decrypt the file.
When you want to share a file with a limited set of users, you download each of their public keys (which you can cache in the client) and the encrypted symmetric key, decrypt the key, and then encrypt it once for each user. They will then only be able to access it with their client.
I'm not sure who you're 'we' as in 'internet community' is. We do have standards and off-the-shelf libraries for everything required to implement this and others have done so in the past (one of my colleagues during her PhD did back around 2006, to give one example, others have implemented more complex and flexible schemes more recently). Note that this is the simple textbook scheme for doing this kind of system. It's been implemented before and doubtless will be again. If you check the research literature then you'll find more interesting schemes.
The only problem is if you want to be able to access it from the browser, without some kind of plugin (Google actually does compile OpenSSL with Emscripten to do ASN.1 parsing, but I wouldn't recommend using it for encryption).