Suggestion: Telegram-backed E2EE vault instead of Saved Messages storage

[imissapixel]

Hello!

I found this project very interesting, as this reminds me of a project that used YouTube videos as a data storage solution. However, I’m concerned that relying on Telegram Saved Messages as the storage layer may not be the best long-term approach. Building a desktop friendly storage system on top of Saved Messages goes beyond the original intent of that feature, and it may not provide the safeguards this use case deserves.

I’ve been exploring a different direction and wanted to ask whether you would be open to a PR draft for it:

The approach treats Telegram as an untrusted storage backend rather than as the source of security. It does not rely on Telegram-native E2EE or Secret Chats. Instead, the app encrypts files, folder metadata, and vault metadata locally before uploading ciphertext blobs to Telegram.

The idea includes:

• Using one private Telegram channel as the ciphertext bucket instead of Saved Messages
• Representing folders as logical app records inside an encrypted vault manifest
• Unlocking the vault locally with a password-derived key that unwraps the vault master key
• Encrypting file chunks with per-file keys
• Supporting upload, download, delete, move, folder creation, search, previews, thumbnails, PDF viewing, and audio/video streaming through the vault layer
• Decrypting to a local cache only when needed for previews, streaming, or downloads
• Preserving Telegram sessions when the user opts to stay logged in

In other words, the product direction would shift toward an encrypted Telegram-backed vault/drive, rather than a plain file manager built on top of Saved Messages. The design is loosely inspired by tools like Cryptomator and Ente Photos: the storage provider is treated as untrusted, and user data is encrypted locally before it is uploaded. The implementation here is different, since Telegram acts as the storage backend and the app manages its own encrypted vault manifest, file keys, and ciphertext blobs.

Would you be open to reviewing a PR draft in this direction, or would you prefer to keep the project scoped closer to the current Saved Messages-based model?

[caamer20]

Hi @imissapixel !

This sounds promising, and I really like the encryption-first approach. However, I’d be hesitant to replace the current Saved Messages model entirely—it works well for simpler use cases and existing users. What if we structure this as an optional Vault Mode that sits alongside the plain file manager? Users could choose between the two, and we could introduce the new architecture incrementally without breaking anything.

Before we dive into code, could you share a brief design document first? I’d love to understand a few key points: the vault manifest structure, the key hierarchy (password-derived key, master key, per-file keys), how folder operations translate to encrypted records, and how streaming and thumbnail generation would work through that encryption layer. Once we’ve hashed out the architecture, I’d be very open to reviewing a PR draft. Thanks for bringing this up!

[imissapixel]

Thanks, that makes sense. I agree that replacing the current Saved Messages model entirely would be too disruptive, especially for existing users. I think the better direction is to keep the existing Saved Messages-based file manager intact, and introduce an optional Vault Mode alongside it.

The implementation I’ve been exploring already follows that model conceptually. In Vault Mode, Telegram is treated as an untrusted storage backend, while the app owns the encryption, metadata, and logical filesystem layer.

At a high level, the flow would be:

1. The user logs into Telegram as usual.
2. If they choose Vault Mode, they create or unlock an encrypted vault with a local password.
3. The password is used locally to derive an unlock key.
4. That unlock key unwraps a randomly generated vault master key.
5. The vault master key encrypts the vault manifest and wraps per-file keys.
6. Each file gets its own random file key.
7. Files are encrypted locally into ciphertext chunks before upload.
8. Folder structure, file metadata, blob references, and wrapped file keys are stored inside an encrypted vault manifest.
9. Upload, download, delete, move, folder creation, search, previews, thumbnails, PDF viewing, and media playback all go through this vault layer.
10. Plaintext is only written to local cache when needed for previewing, streaming, or downloading.

One design choice in the prototype is that Vault Mode uses a private Telegram channel as the ciphertext bucket rather than Saved Messages: Originally, I chose a private channel mainly to keep Saved Messages uncluttered. Vault Mode creates opaque ciphertext blobs and encrypted manifest snapshots, and putting those directly into Saved Messages would make the user’s personal Saved Messages history noisy and easier to accidentally damage.

But I think there is a more important reason to consider moving Vault Mode away from Saved Messages: private channels open the door to shared vaults.

If the encrypted vault is backed by a private Telegram channel, the owner could invite other Telegram users to that channel and separately provide them with the vault decryption material. Those users would then be able to access the encrypted files through the app, assuming they have both:

• Access to the Telegram channel containing the ciphertext blobs
• Access to the vault key or an authorized wrapped key

That would make Vault Mode more than just a personal encrypted backup system. It could become a Telegram-backed shared cloud drive, closer conceptually to sharing a folder in Google Drive, but with client-side encryption controlled by the app rather than by the storage provider.

The separation would look like this:

• Saved Messages: existing user-facing plain file manager / personal saved content
• Private Telegram channel: app-owned encrypted blob bucket for Vault Mode
• Shared private Telegram channel: optional future basis for shared encrypted folders or shared vaults

This seems like a stronger product direction because Saved Messages is inherently personal, while private channels naturally support multiple Telegram users. Using channels as the storage primitive gives the project room to support collaboration later without redesigning the storage model from scratch.

That said, the crypto and permission model should be designed carefully. Sharing a vault key is not the same as a full Google Drive permission system. Proper sharing would eventually need to account for things like: read-only vs write access, key rotation, revoking access after a user is removed, protecting against deleted or corrupted blobs, manifest conflict handling if multiple users modify the vault, whether shared users receive the same vault master key or individually wrapped access keys.

This is just an idea for the future, but I'm using it to explain my thinking around the usage of private channels for the storage. I would not suggest overcomplicating the first PR with full multi-user collaboration immediately. The first step could simply be:

1. Keep the current Saved Messages behavior unchanged.
2. Add optional Vault Mode.
3. Use a private Telegram channel as the default ciphertext bucket.
4. Keep the vault storage backend abstract enough that Saved Messages could still be supported if desired.
5. Design the channel-backed storage model in a way that does not block future shared-vault support.

In other words, the immediate proposal is not to replace the current project model. It is to add an encrypted Vault Mode beside it, with private channels as the preferred backend because they keep Saved Messages clean and create a path toward shared encrypted folders in the future. What are your thoughts?

[caamer20]

Hi again @imissapixel ,

That sounds like a solid plan—I'm on board with the direction in principle. As long as the code is sound, the existing features stay intact, and nothing breaks for current users, let's go for it. I'm looking forward to seeing the PR whenever you're ready.

[imissapixel]

Alright! I'll find some time to put some work in and update you soon.

[imissapixel]

Hi @caamer20, quick follow-up here.

I opened a draft PR for the optional Vault Mode we discussed: PR

The implementation keeps the current Saved Messages / [TD] channel flow intact as Normal Drive, and adds
Encrypted Vault as a separate optional mode after Telegram login.

The first PR version includes:

• Post-login storage mode selection.
• Separate cmd_vault_* command path, leaving the existing plain-drive commands in place.
• Client-side encrypted vault backend using:
  • Argon2id password-derived unlock key
  • wrapped vault master key
  • per-file random keys
  • XChaCha20-Poly1305 authenticated chunk encryption
  • encrypted manifest snapshots
• A private TelegramVault channel used as the ciphertext bucket.
• Mode-aware dashboard routing for list/upload/download/delete/move/search/preview/thumbnail/PDF/media streaming.
• Local decrypted cache for previews/streaming, cleared on vault lock/logout.
• README update with a short Vault Mode section and screenshots.

I kept fresh-device restore/import, shared vaults, key rotation, and multi-user collaboration out of scope for this
first PR. The goal here is the minimal optional encrypted storage mode without disrupting existing users.

I left the PR as a draft so you can review the architecture and direction before I mark it ready.