#Rabbithole — encrypted, decentralized file storage you control

Rabbithole is file storage for people who want a familiar cloud drive without a central owner that must be trusted with files, access rules, and encryption keys.

In a traditional cloud product, your files, backend logic, interface, and access rules live inside the operator's infrastructure. Rabbithole works differently: it creates separate storage for your account on the Internet Computer, with its own web interface, code, state, and access rules.

The Internet Computer matters here because it is not just a blockchain label. It is a network where the application can run as a whole: frontend, backend, state, and user storage do not need to be moved into a traditional cloud account. That lets Rabbithole create more than a row in a company database: it creates a separate storage canister and hands control of it to you.

You can think of a canister as a smart-contract application: it has code, state, and its own resource balance. In Rabbithole, that canister keeps file records, permissions, and, depending on the storage mode, the file bytes themselves.

The file is encrypted directly in your browser before upload. Plaintext data is not sent to the storage backend, and keys are not derived from a password or stored by Rabbithole as a master key. The technical pages explain vetKeys and storage modes later; the starting point is simpler: storage control and cryptography are built into the architecture instead of depending only on a service promise.

New to Internet Computer terms? Read Core concepts first.

#How it works in 30 seconds

1. You sign in with Internet Identity, without creating a Rabbithole password.
2. Rabbithole creates an independent storage canister for your account.
3. You upload files through the app.
4. Your browser encrypts the file before upload.
5. When you download it, the browser verifies and decrypts the file locally.

#The core idea

Most cloud storage products ask you to trust an operator's promise: that it will protect the backend, enforce permissions correctly, keep the service alive, and not expose your files or keys. Rabbithole tries to move more of that trust into architecture.

Storage ownership is expressed through canister control. Access rules live with the storage canister. Files are encrypted in your browser, and key derivation is handled by the network instead of a password-derived master key stored by Rabbithole.

The result is not magic, and it does not remove every assumption. Your browser, the Internet Computer protocol, and Rabbithole's code still matter. But the center of gravity changes: the product relies less on "trust us" and more on protocol boundaries, canister ownership, and cryptography.

#How vetKeys fit in

Imagine a safe with no single master key. For each file, Rabbithole asks the network to derive a file key through vetKeys: each vetKD node returns only its own piece, and the full key is assembled in your browser. One node can't open the safe by itself and never sees the full key.

Standard and High Replication are Rabbithole's product names for two VetKey levels. The node counts belong to the key service, not to file copies. Read Keys and vetKeys when you want that detail.

#How it compares

How Rabbithole differs:

• No passwords for key derivation — your key comes from your Internet Identity, computed by the network itself
• Per-user canister — you own the smart contract where your data lives. After a successful handoff, Rabbithole removes itself as controller
• Reviewable implementation — the code is open source, encryption runs in your browser, and key derivation is enforced by IC consensus

Plaintext is not uploaded to the canister or Blob Storage. Rabbithole still relies on your browser, IC consensus, and correct code. The Trust Model page lists those assumptions.