Future Technical Checks — Native Rust Telegram Client

Источник: dev/fera/project-design/context/FUTURE-CHECKS.md (read-only; сгенерировано scripts/sync-docs.mjs)

Future Technical Checks — Native Rust Telegram Client

Companion docs: ADR.md, RFC.md, TECHSPEC.md, QA.md, OQ.md (architecture), NAMING-UX.md (naming/branding — kept separate from this file).

Non-blocking curiosities and potential future swaps/investigations. None of these are committed decisions — they’re flagged so future-self/agents don’t have to rediscover them from scratch. Contrast with OQ.md: OQ entries block or shape a specific in-progress decision; this file is for things that are explicitly not being decided now, just parked.

1. Query/indexing gap in the current storage design — SQL layer may be needed

Context: StorageEngine (ADR-012) is sanakirja, a KV store. A raw KV store gives no secondary indexes, no query planner, no join-like access for free — anything beyond “get by key / range scan” has to be hand-built on top (the way milli builds its own inverted index for full-text search). This is fine for the current known access patterns (messages by chat_id+message_id, outbox, activity log) but will not scale to arbitrary future query needs without either (a) hand-rolling more custom index structures per new access pattern as they come up, or (b) introducing an actual SQL/relational layer somewhere in the stack.

Decision so far: None. Flagged as a real, anticipated future need, not a hypothetical — the expectation is that a SQL-capable layer will be needed eventually, not “might be.” Turso Database (§2 below) is the leading candidate to investigate for that layer when the need becomes concrete.

What would trigger picking this up for real: A specific feature request that’s awkward/expensive to express against the current KV+hand-built-index model (e.g. an arbitrary multi-field filter/sort the predictor or search UI wants, that isn’t just “by chat_id, ordered by message_id”). Don’t preemptively build a SQL layer before a concrete query need justifies it — but don’t be surprised when one shows up, either.

2. Turso Database (formerly “Limbo”) as a future SQL layer

Update (2026-10-01): PROMOTED to live stack member (OQ-021). Turso is now slated for three concrete roles: derived signed indexes of the module manifests (RON source of truth → Turso queryable copies), config copies (same quadruplet scheme), and cache metadata indexes (sticker/ media LRU/TTL queries). See OQ.md OQ-021 “Resolved details”. The notes below (maturity caveats, what to check) still apply — re-verify production-readiness before the first release that ships Turso files.

What it is: A from-scratch, pure-Rust reimplementation of SQLite — not a fork (that’s libSQL, a separate, already-production C-based Turso project). Full file-format and SQL-dialect compatibility with SQLite is a stated goal. Notable properties: async-first I/O built into the core (SQLite itself is fundamentally synchronous), native vector search, MVCC concurrent writes, first-class WASM compilation target. Tested via Deterministic Simulation Testing (DST, the FoundationDB-style methodology, done in partnership with Antithesis) rather than SQLite’s traditional (closed-source) test suite approach.

Status as of this writing (late Sept 2026): Beta, explicitly not production-ready per the Turso team themselves, though evolving quickly. Project is expected to eventually just be called “Turso” once it reaches production maturity and formally supersedes libSQL as the team’s primary direction. Search for tursodatabase/turso (GitHub), not limbo — the rename already happened.

Why it’s relevant here: Directly answers the gap in §1 — this is the candidate SQL-capable engine to evaluate once a concrete indexing/query need justifies adding a relational layer alongside (or instead of part of) sanakirja. Not a direct swap for sanakirja itself; more likely a second engine used where relational access patterns are actually needed, with sanakirja/milli retained where KV+FTS already fits well.

What to check when revisiting:

Has it reached production-readiness / been renamed to plain “Turso”?
Real-world benchmarks vs. sanakirja and vs. C SQLite for whatever the actual candidate workload is at the time (not benchmarks from this writeup — those will be stale).
Whether its async-first design integrates cleanly with the existing ractor/tokio actor architecture (ADR-006/007), or introduces a second, incompatible async story.
License and embeddability — confirm it’s still suitable for the same “ship inside a hot-swappable native module” pattern as everything else (ADR-001), not just usable as a standalone server process.
Whether it actually solves §1’s indexing gap better than hand-rolling more index structures on sanakirja would — i.e. don’t adopt it just because it exists, confirm it’s actually the cheaper path for the specific query need that triggered looking at it.

Effort estimate (rough, to be revised on actual investigation): Given the existing StorageEngine trait abstraction (ADR-001/005/012), adding a second engine behind its own trait (or an extended one) is architecturally tractable — that’s the point of the trait boundary. The real cost is elsewhere: (a) whether Turso DB’s data model (SQL/relational) maps cleanly onto what’s currently a KV-shaped trait, which may require a new/extended trait rather than just a new implementation of the existing one, and (b) whether milli’s fork (ADR-012, currently retargeted at sanakirja) would need a second retargeting if search ever wanted to sit on top of Turso DB instead. Not a weekend project; scope it properly when picked up.

3. Benchmark pass across the whole stack

Status: Not started — flagged as a standing to-do, not yet scheduled.

Once there’s enough of the system running to be worth measuring, run a structured benchmark pass covering (cross-reference the fixed benchmark scene once OQ-006 is resolved, so these aren’t measured against a moving target):

Storage engine (sanakirja) read/write throughput and latency under the fixed benchmark scene — and again if/when Turso DB (§2) is ever seriously evaluated, on the same scene for a fair comparison.
Search (milli-fork-on-sanakirja) query latency, including the two-phase regex path (OQ-011) at varying corpus sizes.
Module-boundary overhead (nylon-ring) for the storage/search hot paths, with and without the host-side cache (ADR-005), to confirm the cache is actually earning its complexity.
Sticker decode/cache paths — tlottie vs velato (OQ-004), raw vs compressed mmap frames (OQ-003).
UI Engine module frame timing under the fixed scene, before vs after any future Engine swap.

4. Free/cheap low-latency infrastructure options

Status: Not started — needs scoping first.

Flagged as “test and figure out variants for,” but the actual need isn’t pinned down yet — likely candidates for what this would even be for:

Low-latency delivery for update-manifest / module distribution (ADR-013) — CDN or edge options that are free/cheap at the expected scale.
Anything call/stream-related (ADR-018) that might benefit from low-latency relay infrastructure, once real reimplementation work there starts.

Before investing time here: pin down which specific part of the system actually has a latency-sensitive distribution problem worth solving with dedicated infra, rather than researching options in the abstract. Revisit this section once that’s clearer.