A Telegram client that softens hostile messages while keeping every fact, suggests complete replies, and turns group chats into briefings linked to the original messages.
翻訳待ち
ソーシャルPython · TypeScriptGitHub @sergkhlオンライン所有者未確認
Have you tried it? One tap is enough. No sign-in needed.
No updates detected yet. GitHub releases will appear here.
A Telegram client that helps people read busy conversations and write clearer replies
翻訳待ち
Loading the full README.
Read the full README ↗A Telegram client that helps people read busy conversations and write clearer replies.
Enloq combines incoming messages into readable blocks, turns voice notes and images into clear text, softens hostile messages without losing their content, suggests complete replies that can build on your draft, and turns group conversations into daily briefings with links back to their sources. The original messages remain available, and sending is always a separate, deliberate action.
The product has a React web client and an Expo / React Native app, backed by a Python service. Enloq comes from en (縁, human connection) and loqui (Latin, “to speak”).
Open any screenshot at full size. These are high-resolution captures of the real phone-width web interface, using authored synthetic conversations and prepared outputs. They demonstrate presentation, not model quality, live Telegram delivery or native-device acceptance.
| Layer | Implementation | Responsibility |
|---|---|---|
| Service | Python 3.13, FastAPI, Pydantic, Telethon, SQLite | Telegram session ownership, sync, durable work, sending, access checks and spend accounting |
| Web | TypeScript, React, Vite | Reading, composing, streamed updates, pairing and settings |
| Mobile | TypeScript, React Native, Expo | iPhone and Android clients, device trust, media and notifications |
| Shared client rules | Framework-independent TypeScript in shared/ | Routes, times, reply presentation and reading rules |
| AI and speech | A model proxy, bounded inference roles and Whisper transcription | Rewriting, suggestions, classification, briefings and speech, with explicit routes and budgets |
The deployed architecture places the service on an owner-managed VPS behind HTTPS. Telegram authorizations, message caches and durable work stay with that service; browsers and phones are clients, not independent Telegram session owners. The former Mac service is a separate fallback, not the home of all current accounts or trust. Operations describes hosting, pairing and recovery; the mobile runbook describes builds and platform-specific delivery limits.
Member access is scoped in the application. The operator of the shared host can access its stored data, as disclosed in the member agreement. This is not an end-to-end encrypted AI processing boundary. Provider handling and current model routes are documented in Inference and ADR 39.
Generating and sending have different lifecycles. Incoming generation waits for a quiet window. Streamed text is provisional until final validation, and suggestions appear only as complete sets. A chosen suggestion only changes the editable draft; it cannot send a message. Account processing controls are independent of the reading view.
A decision model decides before a writer is called. Perplexity's Decider answers named questions with probabilities and writes no text. Its answers decide whether a text block is softened, the only rewrite of incoming text, whether automatic suggestions are prepared, and which group messages briefings leave out as ads or bots. Measurements gives its per-call latency and cost from small checks, with their limits.
An uncertain send is not safe to repeat. Sends are ordered per chat and retain their operation identity, intended account, peer and media. Failed and uncertain outcomes remain visible with explicit recovery actions. Checking delivery observes the original operation rather than sending another copy. See media delivery.
This is the beginning of the README. Read the rest at the original. Read the full README ↗