I'm an independent developer who builds the plumbing behind Telegram-native products: MTProto automation, media streaming that never touches the disk, and the real-time web apps that sit on top of them.
I spend most of my time on what happens off the happy path: memory ceilings, concurrency limits, failure recovery, and where the trust boundaries sit.
|
Building Ace Hub, a watch-party platform with synchronized playback on Next.js, Socket.IO and Prisma. |
Shipping Tagged releases of CineVault, TeleVault and AceUnzipBot. |
Exploring Queues, retries and observability for long-running jobs, and leaner byte-range streaming. |
Ask me about: Telethon and MTProto, HTTP range requests, async Python concurrency, and running services safely with Docker and systemd.
|
Netflix-inspired movie discovery and streaming built on Telegram. Search for a title, press play, and the bytes flow from Telegram to the player over HTTP range requests, with no persistent media storage on the server.
|
Archive extraction for Telegram, powered by 7-Zip. Bulk jobs run through a FIFO queue with live progress and thumbnails, plus a dedicated CLI and deployment tooling.
|
|
A private Telegram media library with a custom browser player. Playback runs on byte-range streaming, thumbnails are WebP, and access is protected with security-focused controls, including Argon2id hashing.
|
🍿 Ace HubVideo discovery and synchronized watch parties. Real-time playback sync keeps multiple viewers in lockstep, on a responsive interface backed by a Prisma-managed database.
|
CineVault and TeleVault share one idea: the server is a pipe, not a warehouse.
flowchart LR
A["Player<br/>browser or VLC"] -->|"GET + Range header"| B["FastAPI<br/>auth and range parsing"]
B -->|"chunk requests"| C["Telethon<br/>MTProto client"]
C <-->|"MTProto"| D[("Telegram")]
B -.->|"206 Partial Content<br/>streamed chunk by chunk"| A
- Range-first. Each
Range: bytes=a-brequest is mapped to the smallest set of MTProto chunk fetches that covers it, so seeking and scrubbing stay cheap. - Flat memory. Chunks are handed to the HTTP response as the client consumes them. Nothing is buffered to disk, and memory use doesn't grow with file size.
- Stop when the viewer stops. When a player seeks away or disconnects, the in-flight download is cancelled instead of burning bandwidth.
Rules I build by: stream, don't store. Bound memory and concurrency. Automate the repetitive. Design for failure. Keep trust boundaries explicit.
| Languages |
|
| Backend |
|
| Frontend |
|
| Data |
|
| Ops |
|
Got something involving Telegram automation, streaming infrastructure, or a real-time web app? Message me on Telegram or send an email. I'm happy to talk it through.