Why Did I Build This?
"Designed to solve a specific UX friction point: logging media consumption while watching on a Smart TV. Standard web interfaces and TV remotes are highly inefficient for text entry. By exposing the state management interface via a Telegram bot, the user can instantly query, log, and receive randomized media suggestions directly from their mobile device with zero context switching. The architecture was kept intentionally lightweight (statically compiled Rust, flat-file storage) to eliminate the operational overhead of maintaining a relational database."
Architecture & Decisions
Built on the `tokio` asynchronous runtime utilizing the `teloxide` framework for Telegram API bindings. State persistence is handled via a localized flat-file system. To optimize I/O and deduplication, file contents are loaded into memory as `std::collections::HashSet` structures, providing O(1) insertion checks. Following state mutation, data is lexicographically sorted and flushed to disk. The bot also implements a custom string buffering algorithm (`send_long_message`) to dynamically chunk payloads exceeding Telegram's strict 4096-byte message limits.
Key Features
- 01.Asynchronous command routing and dispatch via the `teloxide` REPL architecture
- 02.Flat-file state persistence with `HashSet`-driven deduplication and automatic lexicographical sorting
- 03.Dynamic message chunking algorithm to strictly adhere to Telegram API payload constraints
- 04.Sub-string resolution matching to provide graceful fallback suggestions for inexact user input