Rabbithole: Sovereign encrypted vault on the Internet Computer

Developers Showcase
1

Hi everyone,

I want to share Rabbithole, a sovereign encrypted vault for files that I have been rebuilding over the last year.

The basic idea is simple: a user gets a personal vault backed by a storage canister. That canister serves its own frontend, and after setup Rabbithole removes itself from the storage canister controllers.

For me, the important part is sovereignty: Rabbithole is not meant to be a hosted drive where the user only owns an account. The vault is a canister the user can open directly, inspect, fund, and control.

App: https://rabbithole.app/

Documentation: https://docs.rabbithole.app/

Demo: https://www.youtube.com/watch?v=A0ZLQGm2Au0

X: Rabbithole.app ∞ (@rabbithole_ic) / X

I also created a public test vault:

If you want to try the vault flow before creating your own vault, send me a request. In the request message, add something that lets me identify you, or fill in your profile. I can give one month of Pro to anyone from DFINITY. I can also give it to a small number of active forum users, but those slots are limited because Pro includes 2 TC per period.

With Pro enabled, you can test shared access to a whole vault, a folder, or a file, with View/Edit/Manage permissions and invites by verified email.

What works today

Rabbithole is already usable as a personal sovereign encrypted vault. The current version includes a direct frontend served from the vault’s storage canister:

https://<canister-id>.icp.net

It also includes:

  • personal user-owned vaults backed by storage canisters;
  • On-chain Storage for encrypted file bytes;
  • Blob Storage under the same access and encryption model;
  • shared access to a whole vault, a folder, or a file with View/Edit/Manage permissions;
  • incoming access request management;
  • storage canister management for controllers, snapshots, and other operations;
  • multichain payments through IC, Base, and Solana;
  • managed cycles top-ups for Pro vaults;
  • storage update delivery through GitHub-based releases.

Current vault UI:

Rabbithole vault UI
Rabbithole vault UI3090×1806 267 KB

How Rabbithole uses the Internet Computer

The implementation is built around these IC pieces:

  • Application canister + per-user storage canisters
  • Controller handoff after vault creation
  • Frontend assets served by the storage canister
  • Stable Memory for file records, grants, metadata, and release state
  • vetKeys-backed file-key derivation
  • Internet Identity + target-scoped delegation for the direct storage UI
  • Identity Attributes for resolving shared access by verified email
  • Cycles accounting, treasury flows, internal wallets, and managed cycles top-ups
  • Chain Fusion payments across:
    • Internet Computer: ICP, ckUSDC, ckUSDT, ckETH
    • Base: ETH, USDC, USDT
    • Solana: SOL, USDC, USDT
  • Threshold ECDSA / Schnorr for Base and Solana deposit addresses
  • EVM RPC and SOL RPC for balances and transaction flows
  • GitHub-based storage releases with the storage module, frontend assets,
    and release metadata

Sovereignty and trust model

I am not claiming that Rabbithole removes every trust assumption. The browser, IC protocol, code correctness, cycles, and Blob Storage availability still matter.

The product direction is narrower and more practical: move vault ownership closer to the user and keep Rabbithole out of the critical path wherever possible. After setup, the user controls the storage canister. The canister serves its own frontend. Updates are explicit. GitHub repo will be public soon. File access is built around browser-side encryption, vetKeys, and controller state that users can inspect.

Monetization

This sovereignty model has an awkward business side. From a business point of view, I probably gave users too much freedom: they do not need the main frontend after setup, and I still want to keep reducing my own influence over user vaults.

I do not want to launch a token and sell it to users with promises that it will be worth something later. I looked at competing Web2 storage products and decided that the Starter Vault should have a storage limit. For personal use, Starter Vault should be enough.

Features that depend on the application canister will be part of Pro: managed cycles top-ups, shared access directory, user directory, and storage canister updates.

Why I kept building it

This is the third serious version of the same idea for me.

The first version started in 2019 on Blockstack: frontend client, wallet-based auth, file APIs, and client-side encryption helpers. I received two months of developer grant rewards, then the program stopped. Later the wallet and APIs changed, my app broke, and I had to recover my own files back to my device. That was the point where the trust problem became very personal to me: I had built an encrypted storage app that I still could not fully trust.

After IC mainnet launched in May 2021, I kept thinking that this was the right place for the idea. I was only a frontend developer at the time, and Rust or Motoko felt like a wall. Nobody around me wanted to build it, so I learned Motoko myself.

In 2023 I had a private IC version. Eight people saw it, including me. It scaled by creating multiple canisters with 2 GB heap memory each, used an index canister for orchestration, and still served a shared frontend from the main domain. It worked as a prototype, but it still did not solve the trust model well enough. The criticism from friends was fair, so I left that version behind.

Last year I decided to try again. The IC ecosystem felt mature enough: better Stable Memory support in Motoko, the Mops libraries I needed, vetKeys, Chain Fusion pieces, and a clearer path to user-owned canisters.

Acknowledgements

A small thank you to @domwoe and @cryptoschindler for guiding me toward the grant process, and to @timo @Gekctek @tomijaga, and others for the Motoko libraries that made parts of this implementation much easier.

Documentation status and roadmap

I wrote down most of the architectural decisions in the docs. Some parts are still missing or behind the implementation: image thumbnail storage, GitHub-based update delivery, treasury and internal user wallets.

This is not a fixed roadmap, but these are the directions I am exploring next. Some of them already have early backend groundwork, and the exact product shape can still change:

  • WebSocket support;
  • Blob Storage management page;
  • granular access rights;
  • direct Internet Identity authentication for recovery access;
  • in-app email verification;
  • ambassador program flows;
  • email and Telegram notifications;
  • and more.

I would appreciate ideas from the community: what you would like to see next, what feels unclear, what should be changed, and what would make Rabbithole more useful for people who need private, user-owned file storage. I will also post a short announcement on X; if Rabbithole feels useful, sharing that announcement would help it reach more of those people.

2

Looks good, I think you really need to work on clarifying roughly how much the user can store using the Pro option in order to compare plan with other Web3 and Web2 alternatives.

3

I like it, great work on this project.

I know this is probably an unpopular opinion, but I would want Plug wallet support so you can use pem file or seed phrase identities for your principal. But I get it, that feature was probably left out intentionally.

4

Very cool. Is it open-source? Curious what mops packages it is using.

5

Thanks everyone for taking a look.

@vavram you are right. I need to explain the limits much better, but this is a tricky part of the product copy.

With Blob Storage, file bytes are stored outside the storage canister. The canister mainly stores the file tree, file/folder metadata, blob references, sizes, hashes/status, access grants, and encryption/key-related metadata. Because of that, it is hard to describe the limit as a simple “you get X GB” number.

Also, I do not want to imply that Pro includes a fixed amount of storage in the Web2 sense. Users still pay for storage and operations from the cycles balance of their own storage canister. Pro is more about managed cycles top-ups and app-canister-backed features, not a bundled GB quota.

For On-chain Storage the wording is even more sensitive because cycles can burn quickly, especially on writes. Even saying something like “5 GB Starter Vault” can be misleading if the initial cycles balance is not enough for that usage pattern.

So yes, I need to work on this. I want the pricing/docs to be understandable without promising capacity in a way that creates the wrong expectations.

@brady Plug support is not planned right now. That was intentional.

For Rabbithole, Internet Identity fits the product direction better. II gives users stable app-specific identities that are not tied to a single device, supports passkeys and recovery methods, and the current spec also includes OpenID Connect credentials.

That direction matters because I want Rabbithole to be usable not only by IC-native users, but also by people who simply care about privacy and security. For that audience, a wallet-specific auth flow feels like an extra IC-specific concept to explain.

So the goal is not to force users into Rabbithole’s own identity infrastructure, or into a specific IC wallet. The goal is to keep sign-in simple, familiar, and actively supported, while building recovery and access-control flows around Internet Identity.

@timo the repo is still private while I clean up CI and project presentation, but I added you to it. I do plan to open it.

On the mops side, I use at least `sha2` and `vector` directly, and I generally follow your packages because they have been very useful while building this.