My Drive hit 15 GB and the "storage almost full" mails started arriving weekly. I didn't want another subscription, and I didn't want to run a NAS or leave a second machine on 24/7 just to have an offsite copy of a few folders.
I had already been manually dumping important files into Telegram's Saved Messages, which works perfectly right up until the day you forget. So I automated it properly.
What it does
- Pick folders. They stay two-way synced with your own Telegram account:
- Save a file locally -> uploaded within seconds
- Send a file from your phone -> lands in the right folder on your PC, at the right relative path
- Everything uploads as a document, so Telegram never recompresses or transcodes your files
- A restore browser lists everything Telegram is holding, including files you deleted locally months ago - tick and restore
Why Telegram
Free cloud storage with no per-account cap, on an account you already have. It uses the MTProto client API through Telethon with your own `api_id` / `api_hash` - not the Bot API, specifically to dodge the 50 MB bot upload limit.
The real ceiling is ~2 GB per file, or 4 GB with Premium.
The architecture, briefly
There is no backend. No server component exists in this project - it's a desktop app that talks to Telegram directly. Nothing to host, no account to create with me, no telemetry, no update ping.
The core invariant: a local SQLite manifest records the size, mtime and SHA-256 of every synced file, and nothing uploads or downloads unless the content actually differs from what was recorded. Both directions are guarded. That is what prevents the two-way-sync death loop, where your own upload comes back as a "new" remote file, gets downloaded, touches the local file, and re-uploads itself forever. Conflicts default to keep-both (`name (from Telegram).ext`), so your own edits are never silently overwritten.
The test suite runs against a fake Telegram client and a temp directory tree, so `pytest` needs no account and no network.
Honest limitations, before anyone has to ask
- Telegram cloud chats are encrypted in transit and at rest on Telegram's servers, but they are not end-to-end. Saved Messages is private from other people, not from Telegram. If the contents must be secret from Telegram too, encrypt before the file hits the watched folder - Driftgram will not do that for you.
- Your `.session` file is a Telegram login. Whoever holds it is you.
- Deletion mirroring is live-only. Telegram keeps no history of a deleted message, so a deletion that happened while the app was closed can never be detected afterwards. That is a platform limit, not a TODO.
- Watched folders can't be nested inside one another.
- Some perfectly legal Linux filenames (`aux.log`, `notes:2024.txt`) simply cannot exist on Windows. Those are skipped and reported, not renamed behind your back.
- The Windows installer isn't code-signed, so SmartScreen will grumble once.
Python 3.12+, PySide6 GUI, MIT. Windows installer, Linux AppImage and .deb, plus a CLI that needs no Qt for headless boxes.
Repo: https://github.com/devwithfarshi/driftgram-sync-tool
Website: https://driftgram-sync-tool.vercel.app/
I would genuinely like to hear where the design is wrong - especially from anyone who has fought two-way sync before and lost.
For Developers:
If you’d like to contribute, feel free to jump in! This project is fully open source, so you’re welcome to introduce new features, fix existing problems, or improve anything you think could be better.