AIOZ Storage Glossary: Bucket, Passphrase, Macaroon

AIOZ Storage's documentation uses at least a dozen specific terms, bucket, passphrase, root secret, macaroon, caveat, eKey, zKey, access grant, sub-user, across its concepts and tutorial pages. Its own glossary page formally defines exactly two of them. This aioz storage glossary fills that gap: what each term means, where it shows up in the docs, and the handful of places AIOZ's own vocabulary contradicts itself from one page to the next.

TL;DR:

• AIOZ's official glossary page defines only "S3-Compatible" and "AIOZ DePIN", every other term used across the docs (bucket, passphrase, macaroon, access grant, eKey, zKey, sub-user) has no formal entry anywhere.
• "Root Secret" and "passphrase" refer to the same thing, described with different words on different pages, and AIOZ's docs never state the equivalence directly.
• Access grants bundle two keys, an eKey for encryption and a zKey for authorization built as a macaroon, and macaroons can only get more restricted over time, never less.

Why Doesn't AIOZ Storage Have a Real Glossary?

Because its documentation site's own /docs/concepts/definitions page only defines two terms: "S3-Compatible", described as a service that follows "the same application programming interface (API) specifications and functionality as Amazon Simple Storage Service (S3)", and "AIOZ DePIN", defined as the network that "rewards DePIN computational resources for computing, storing, transcoding, and streaming digital media content." Every other term this article covers gets used freely across encryption, access-management, and payment pages without ever appearing on that definitions page at all.

That's the actual gap this glossary is filling. Six terms below, starting with the one everyone gets confused about first: whether "passphrase" and "root secret" are the same thing.

Bucket and Object: The Basic Units of Storage

A bucket is the top-level container you create in AIOZ Storage, the same role a bucket plays in Amazon S3 itself, which is exactly the point of AIOZ Storage's S3 compatibility: existing S3 tools and SDKs already understand what a bucket is without any AIOZ-specific translation layer. An object is any individual file stored inside a bucket, again matching S3's own terminology directly. Each bucket gets its own passphrase (covered next), meaning encryption is scoped per bucket, not per account or per object.

Passphrase and Root Secret: Same Thing, Two Different Names

AIOZ Storage's encryption-implementation page never uses the word "passphrase" at all. It defines something it calls the Root Secret: "a confidential string generated by the user. It is employed to generate keys for encrypting and decrypting the data stored on AIOZ Storage", labeled S0 in that page's technical notation. Every other page describing the same feature, dashboard flows, FAQ answers, security overviews, calls this secret a "bucket passphrase" instead, generated from the BIP39 wordlist, the same word-list standard used for crypto wallet recovery phrases, with options to accept the auto-generated one, refresh it, write your own, or download it as a backup file.

Nowhere does AIOZ's documentation write a sentence that says "the Root Secret is your bucket passphrase." But every description of what the Root Secret does, user-generated, used to derive encryption keys, never stored by AIOZ, matches how the passphrase is described everywhere else, word for word in function if not in name. Treat them as the same secret described in two different corners of the docs, not two different mechanisms.

The Key Derivation Chain: S0, K0, S1, K1, and E1

Once you have the Root Secret (S0, the passphrase from the section above), AIOZ Storage's docs describe a specific one-directional chain built from it. A component key K0 is derived from S0. A new secret S1 gets generated by hashing S0 together with a component identifier called C1. A key K1 is derived from S1. And the encryption of C1 itself, called E1, is produced by encrypting C1 under K0. The data itself is encrypted with AES-GCM, the cipher AIOZ's docs name directly, though the docs never disclose a specific key length, so don't assume AES-256 just because it's the industry default elsewhere.

The property that matters here is direction: a key further down this chain can decrypt what came before it, but that capability doesn't run in reverse. That's what lets AIOZ hand out narrower decryption capability for specific components without exposing S0 itself, the Root Secret at the top of the chain.

Macaroon and Caveat: A Permission You Can Narrow But Never Widen

A macaroon, per AIOZ's own docs, is "bearer tokens that enable applications to ascertain whether their holders' actions are authorized," the same bearer-credential design first published by Google researchers in 2014. A caveat is a restriction layered onto a macaroon, like an expiration time or a scope limit, and the docs describe exactly how that layering works: "Their caveats are constructed using chained HMAC functions, allowing easy addition of caveats while preventing their removal." That one-directional property, easy to add restrictions, cryptographically hard to strip them back off, is the entire reason AIOZ Storage uses macaroons instead of a plain API key. A static API key authorizes whatever it originally authorized, full stop. A macaroon can only get narrower over time.

AIOZ's docs also state the underlying design goal directly: "Macaroons separate the policy (who can access what) from the mechanism (how the policy is enforced). The verifier certifies the correctness of embedded proofs, while the policy is defined during macaroon creation, attenuation, and sharing." Every access grant and every permission rule covered in the sections below is built on this same macaroon foundation.

Access Grant, eKey, and zKey: The Credential You Actually Share

An access grant is the credential you actually hand out, and it bundles two separate keys. AIOZ's docs describe it directly: "Both of these keys are created on the client-side and combined into what's called an access grant", one key handles encryption (the eKey), the other handles authorization and is built as a macaroon (the zKey). That finished grant then gets encrypted using your S3 Access Key ID (the docs use this exact phrase on the access-grant page, though other pages in the same docs site shorten it to "Access Key ID" or "S3 Access ID", a naming inconsistency worth knowing about if you're grepping the docs for a specific term) and stored server-side, decryptable only by a client holding the matching key.

Access grants come in two flavors the docs distinguish elsewhere: a primary access grant, created through the Admin Console with a server-generated ID, and child access grants derived from a primary one entirely client-side. Revoking a primary currently revokes every child derived from it at once, there's no way yet to revoke one child individually, something AIOZ's own docs list as a planned future release rather than a shipped capability.

Sub-User (Member): The Account-Based Alternative to an Access Grant

A sub-user, called a "member" in the dashboard UI, is a persistent account: a name (at least 8 characters), a password (at least 8 characters with at least one uppercase letter and one digit), and a per-bucket permission assignment drawn from AIOZ Storage's four-action model, List, Write, Read, Delete. A member exists until someone deletes it, which is a permanent, non-undoable action.

An access grant, by contrast, isn't an account at all. It's a scoped, time-boxed credential, expiring on a schedule you choose (24 hours up to 1 year) rather than persisting indefinitely. A recurring team member should get a sub-user. A contractor, a script, or a one-off integration should get an access grant instead, scoped narrow and set to expire on its own.

Frequently Asked Questions

Is "Root Secret" the same thing as a bucket passphrase on AIOZ Storage?
Functionally yes, though AIOZ's docs never state this equivalence directly. The encryption-implementation page calls it the Root Secret (S0); every other page describing the same user-generated, never-stored secret calls it a passphrase.

What is a macaroon in AIOZ Storage's access control system?
A bearer token whose caveats (restrictions) are built with chained HMAC functions, per AIOZ's own docs, letting you narrow what it authorizes over time but making it cryptographically infeasible to strip a restriction back off.

What's the difference between an eKey and a zKey?
The eKey handles encryption. The zKey handles authorization and is built as a macaroon. AIOZ Storage's access grant bundles both into one credential, encrypted using your S3 Access Key ID.

Is a sub-user the same as an access grant?
No. A sub-user (called a "member" in the dashboard) is a persistent account with its own login and permissions. An access grant is a scoped, time-limited credential that expires automatically and isn't tied to a login at all.

Why does the AIOZ Storage documentation use different names for the same S3 credential ID?
Inconsistency, not a technical distinction. The access-grant page calls it "S3 Access Key ID"; other pages in the same docs shorten it to "Access Key ID" or "S3 Access ID." All three refer to the same credential.

What are the only two terms AIOZ Storage's own docs formally define?
"S3-Compatible" and "AIOZ DePIN." Every other term this glossary covers, bucket, passphrase, macaroon, access grant, eKey, zKey, sub-user, is used throughout the docs without a formal definition anywhere.

Related Reading

• How AIOZ Storage Encryption Actually Works - the full key derivation chain and encryption modes this glossary summarizes.
• AIOZ Storage Access Control: Macaroons and Access Grants - the complete permissions model, revocation limits, and member vs access grant tradeoffs.
• AIOZ Storage Explained: S3-Compatible Decentralized Storage - what AIOZ Storage is overall, including its S3 compatibility and official pricing.
• Migrate from Backblaze B2 to AIOZ Storage with rclone - the access grant and bucket terms from this glossary, put to use in an actual migration.
• File Management API with FastAPI, Boto3, and AIOZ Storage - the access grant and endpoint terms from this glossary, put to use in a working Python API.

References

• AIOZ Storage Documentation: Definitions
• AIOZ Storage Documentation: Macaroons
• AIOZ Storage Documentation: Access Grant
• Macaroons: Cookies with Contextual Caveats for Decentralized Authorization in the Cloud (Google Research, NDSS 2014)
• BIP39: Mnemonic Code for Generating Deterministic Keys