mdc-lite is a key-value store built for the places a server can't reach — a watch face, a phone app, a background service — with every value and every key name sealed under XChaCha20-Poly1305 before it ever touches disk. No runtime. No dependencies to speak of. Nothing readable outside the app that wrote it.
This page is about mdc-lite. It has a sibling, the MDC Platform — a separate, Python server-side product in the same repo. They solve different problems and don't share code.
| mdc-lite — this page | MDC Platform | |
|---|---|---|
| What it is | An embeddable library, linked into your app's binary | A server you run and talk to |
| Where it runs | Inside the app itself — no network, no server | On a machine with Python, reachable over the network |
| What it stores | Small generic objects — settings, credentials, cached blobs. No AI models. | AI models, images, documents, database tables |
| CLI / desktop app | None — mobile/wearable embedding only | Yes — conversational CLI + REST API |
| How you talk to it | 5 functions: put / get / exists / delete / list_keys | Plain sentences — no SQL, nothing to train support staff on |
| Encryption | Mandatory — every value and every key name | Mandatory on the DNA archive tier (AES-256-GCM) |
| DNA-inspired encoding | Yes — every entry is stored as an encrypted ACGT sequence | Yes — the archive tier, same encrypt-then-encode model |
| External API access | N/A — no network surface | Bearer-token REST API for custom apps/NLU integrations |
Key names are hashed with a keyed BLAKE3 hash before they ever become a filename — a directory listing of the raw store reveals nothing, not even how your data is organized.
This library takes a 32-byte key and never generates, stores, or touches it beyond that. Real custody belongs to the platform's own secure hardware — iOS Secure Enclave / Keychain, Android Keystore / StrongBox — which is exactly where it should live.
Built in Rust with opt-level = "z", LTO, and symbols stripped. No garbage collector, no interpreter, no background thread — a handful of file reads and writes, nothing more.
get() on a specific key fails loud if it's been tampered with. list_keys() quietly skips anything it can't decrypt, so one bad or foreign file never hides every other valid key in the store.
Every operation is exposed through a five-function C header — bind it from Swift, Kotlin, or anything else that speaks C calling conventions. No wrapper generation, no FFI framework.
Every encrypted entry is DNA-encoded (2 bits per base — 00→A 01→C 10→G 11→T) before it's written, the same encoding MDC Platform's archive tier uses. It's ciphertext under the base letters, never plaintext — the mapping is public, encryption is what actually protects it.
| Platform | Artifact | Size | Status | |
|---|---|---|---|---|
| macOSApple Silicon | libmdc_lite.dylib | 348 KB | tests passing | Download → |
| Windowsx86_64, mingw-w64 ABI | mdc_lite.dll | 992 KB | compiled, unrun | Download → |
| Androidarm64-v8a — real devices | libmdc_lite.so | 376 KB | linked, unrun | Download → |
| Androidarmeabi-v7a — older devices | libmdc_lite.so | 252 KB | linked, unrun | Download → |
| Androidx86_64 — emulator | libmdc_lite.so | 484 KB | linked, unrun | Download → |
| iOS / watchOSrequires full Xcode to build | — | — | build from source | Instructions → |
| Wear OS | — (uses Android .so) | — | same as Android | Instructions → |
Sourceany platform, cargo build |
mdc-lite-v1.2.0-source.tar.gz | 19 KB | build it yourself | Download → |
Every build above ships from a single tagged GitHub Release (checksums included) - not loose files browsed out of the repo tree. "Compiled, unrun" means the build succeeds and produces a correctly formatted binary, but couldn't be executed in the environment that built it — there was no Wine, Android emulator, or physical device on hand to run it against. Not a hedge: the full verification story, artifact by artifact, is in BUILD_INFO.md.
use mdc_lite::LiteStore; let key: [u8; 32] = /* from platform secure storage */; let store = LiteStore::open("/path/to/store", key)?; store.put("diary/2026-08-24", b"...")?; let value = store.get("diary/2026-08-24")?; store.exists("diary/2026-08-24"); // bool store.delete("diary/2026-08-24")?; let all_keys = store.list_keys()?; // Vec<String>
#include "mdc_lite.h" MdcLiteStore *store = mdc_lite_open("/path/to/store", key); mdc_lite_put(store, "diary/2026-08-24", data, data_len); uint8_t *out; size_t out_len; mdc_lite_get(store, "diary/2026-08-24", &out, &out_len); // ... use out[0..out_len) ... mdc_lite_free_buffer(out, out_len); mdc_lite_close(store);
// via the C header, bridged into Swift let store = mdc_lite_open("/path/to/store", keyPtr) mdc_lite_put(store, "diary/2026-08-24", valuePtr, valueLen) var outPtr: UnsafeMutablePointer<UInt8>? var outLen = 0 mdc_lite_get(store, "diary/2026-08-24", &outPtr, &outLen) // ... Data(bytes: outPtr!, count: outLen) ... mdc_lite_free_buffer(outPtr, outLen) mdc_lite_close(store)
Quantum key distribution transmits photons between two fixed physical endpoints over dedicated hardware. It's a network-link technology — there's no version of it that runs inside an app on a phone or a watch.
Grover's algorithm only halves a symmetric key's effective strength — 256 bits stays enormous. Quantum computers threaten asymmetric crypto (RSA/ECC) instead, which this library doesn't use at all.
No — verified, not assumed. A qubit's superposition decoheres to a fixed, data-independent state in a handful of T2 lifetimes even with nobody reading it, confirmed by solving the Lindblad master equation in QuTiP against its exact analytic solution. There's no hardware today that holds a quantum state at rest the way a disk holds bits. Full derivation →