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.

6

Lots of people have been asking for this for a long time. Looks beautiful too. Well done.

8

Looks neat! I am testing it out. As of now, however, the link to the youtube video seems broken. For marketing, you should fix it.

Best of the luck!

9

I can understand that, but most users would expect at least a minimum guaranteed amount for the price being paid. Also, how can users fund their wallet with ckUSDC/ckUSDT when there’s no principal id exposed in the wallet UI?

image
image795×475 22.3 KB

10

Well, that’s a pretty good question.

11

I’m testing it and it looks very good. The UI is clear and intuitive, and it runs really smoothly, but I don’t know whether average Joes would be willing to pay $9 for a feature that’s available for free in Google Drive, such as file sharing. I’m not criticizing the solution, but these subscription models are being pushed everywhere these days.
The beauty of IC software is that you can set it and almost forget it that’s the freedom that the Internet Computer offers ( or more or less used to offer). Paying with ICP to create storage is nice, except that outside this community ICP is not really used as a payment method (for now).
I hope this project succeeds nice work, and I wish you to burn a lot of cycles :smiley:

12

Thanks everyone for testing and for the feedback.

@jmrosal thanks for mentioning the YouTube link. I could not reproduce the issue on my side, and I also saw your comment under the video, so it looks like the video was reachable at least in some cases. I will keep an eye on it.

@vavram you are right about the wallet UX. This is a real issue, and I have already switched to fixing it.

The original design used ICRC accounts controlled by the backend canister, with user-specific subaccounts. That works well in tests, but it is not practical enough in the real world because many wallets do not expose subaccount-based transfers clearly.

So I need to add a more user-friendly deposit flow: users will be able to send supported tokens to their own principal first, and then deposit them into the internal Rabbithole wallet. It adds one extra step, but it is more understandable and works better with existing wallets.

I also noticed that some users have already funded their internal wallets generously, while the frontend does not yet expose withdrawals. The backend methods exist and work, but the UI is missing. I am fixing this in the next update.

@KryL your point is fair. If someone only needs free file sharing, Google Drive is hard to beat.

Rabbithole is not meant to compete with Google Drive on price or free convenience. I am moving the positioning more toward people and teams that need private, encrypted, user-owned storage and are willing to pay for that tradeoff.

This is personal for me too. I live in Russia, and at some point I started losing access to foreign services simply because of where I lived. I could not pay for services, accounts became unreliable, and data could disappear or become unreachable. That changed how I think about storage.

So yes, traditional services are fine for many people. But Rabbithole is for users who care about control, privacy, encryption, and not having their storage depend entirely on one company account.

13

Nice work, love the interface!

16

@dominicwilliams thank you, this means a lot.

I also published a storage canister update based on the first feedback from the thread. It is now available for installation from the app.

The main changes:

  • improved IC token funding UX for internal wallets;
  • added withdrawals from internal wallets, so user funds are not stuck in the app;
  • fixed certified route handling for the storage frontend.

The new certification fix required patching fallback route candidate handling in the Motoko certified-assets library. In practice, this makes direct frontend routes in the storage canister behave correctly with certified assets.

I also recorded a short silent video showing the update flow:

For me this flow is an important part of the product: a user-owned storage canister should have an understandable update path, and updates should be visible and explicit.