Your data. Every cloud.
Provably stored.
DCTL moves and backs up data across cloud providers the way rclone does — with every byte encrypted client-side in a frozen, self-describing format, and no transfer ever reported complete until its bytes are verified at the destination.
Rust · Linux, macOS · KONG GROUP LLC
- Rust crates
- 8Rust cratesLayered so the crypto core carries zero unsafe code
- Memory per file
- O(chunk)Memory per fileA 50 GB video never has to fit in RAM
- Restorability target
- 20 yrRestorability targetDecodable from the format spec alone, with no Rust and no network
- Hybrid PQ sharing
- ML-KEM-768Hybrid PQ sharingX25519 + ML-KEM-768 recipient wrap, shipped
The durability contract
Every transfer is verified at the destination
before it is called done.
Most tools report success when the last byte leaves the machine. DCTL reports success when the bytes have been read back and matched at the destination, and the local index has durably committed the fact.
- readbounded chunks
- hashBLAKE3
- encryptXChaCha20-Poly1305
- checksumciphertext digest
- uploadconstant-memory multipart
- verifycompare at destination
- commitindex says it exists
A mismatch aborts the run
The staged object is deleted and nothing is committed. There is no partial state to clean up later.
The index is the source of truth
A path exists once its commit is durable. Crash the process mid-transfer and the index still tells the truth.
Plain remotes get it too
The contract is not a feature of encryption. Unencrypted copies are verified on exactly the same terms.
What you get
Built for data you cannot afford to lose
Large media, long horizons and providers that come and go. Every design decision follows from those three facts.
Verified writes, or no write at all
Nothing is reported stored until its bytes are checksum-verified at the destination and durably committed to the local index.
Constant memory, any file size
Chunked AEAD plus constant-memory multipart means a 50 GB video uploads in bounded memory.
Cross-device restore from a password
The backend is authoritative. A fresh machine with only the password rebuilds the entire path map.
A format frozen for twenty years
A dependency-free C99 reference decoder proves the format outlives the tool that wrote it.
Post-quantum where it counts
The at-rest path is entirely symmetric. Sharing uses an X25519 + ML-KEM-768 hybrid.
Mount a vault, read it like a disk
Read-only FUSE mount with chunk-ranged reads and writes refused at the kernel boundary.
Metadata-private encrypted index
Filenames and directory structure never reach the provider in the clear.
Encryption is optional, never accidental
A remote is plain or vault-wrapped, and what a command encrypts depends only on the remote name you typed.
Standing on good work
If you know rclone, you already know DCTL
DCTL is written from scratch in Rust, but its addressing rules, filter syntax and command vocabulary were heavily inspired by the excellent work of the Rclone project. If you know rclone, you already know how to drive DCTL.
| Capability | Rclone | DCTL | Notes |
|---|---|---|---|
| copy / sync / move / ls / cat | Yes | Yes | Same mental model, same filter and addressing rules |
| Breadth of backends | 70+ | Focused set | Local and B2 today; R2, S3, Drive and SFTP on the roadmap |
| Client-side encryption | crypt overlay | Vault with identity | A vault has a vault_id, revocable key slots and an encrypted index — two remotes sharing a password are not interchangeable |
| Verified write before success | Optional checks | Yes | Non-negotiable, on both plain and encrypted remotes |
| Post-quantum sharing | No | Yes | X25519 + ML-KEM-768 hybrid recipient wrap |
| Metadata-private index | No | Yes | Encrypted SQLCipher index; filenames never leave in the clear |
| Format decodable without the tool | No | Yes | Dependency-free C99 reference decoder plus Known-Answer Tests |
| Tamper-evident audit log | No | Yes | Hash-chained, order- and integrity-preserving |
| Licence | MIT, free | Free for personal use | Commercial and corporate use requires a licence |
Where DCTL actually is
An honest completion status
DCTL is pre-1.0 and we would rather tell you that here than have you discover it during an evaluation. This table tracks the real state of the code.
| Area | Detail | Status |
|---|---|---|
| Crypto core & frozen v1 formatComplete and committed, no unsafe code | Complete and committed, no unsafe code | Shipped |
| Encrypted index (SQLCipher)Complete and committed | Complete and committed | Shipped |
| Local filesystem backendVerified writes, fully exercised | Verified writes, fully exercised | Shipped |
| Hybrid PQ sharing & grantsX25519 + ML-KEM-768, complete | X25519 + ML-KEM-768, complete | Shipped |
| C99 reference decoder + KATsComplete, byte-exact cross-validation | Complete, byte-exact cross-validation | Shipped |
| B2 / S3 / R2 backendsImplemented; live end-to-end verification pending | Implemented; live end-to-end verification pending | Partial |
| CLI surfaceHappy path smoke-tested; some verbs still partial | Happy path smoke-tested; some verbs still partial | Partial |
| Read-only mount (FUSE)Linux and macOS attached against a live kernel | Linux and macOS attached against a live kernel | Partial |
| Google Drive & SFTP backendsSpecified, not yet built | Specified, not yet built | Planned |
| serve (HTTP / WebDAV)Specified, not yet built | Specified, not yet built | Planned |
| Windows mount (WinFSP)Refused by name until implemented | Refused by name until implemented | Planned |
Verified against the project’s own status document. Read the source of truth.
Start with your own data. Licence it when it becomes work.
DCTL is free forever for personal use, with nothing held back. When it starts moving data for a business, a commercial licence keeps you covered.