Media Pocket

Media Pocket accepts a request through Telegram, obtains media from an external source, normalizes the result, and returns it to the user. It is not one long handler: the interactive bot and background worker are separate, and work moves through an asynchronous path.

State and execution

PostgreSQL holds canonical state. Redis Streams participates in moving jobs between processes, separating request intake from network retrieval and file processing. This boundary makes retries, errors, state transitions, and the point at which a result is genuinely ready for delivery explicit concerns.

Media sources sit behind a provider abstraction. Provider-specific behavior stays at the external-service boundary instead of spreading through the Telegram layer and worker. FFmpeg is part of normalization and processing when an obtained file cannot simply be passed through unchanged.

Engineering boundary

The system has distinct concerns around deployment, security boundaries, and acceptance checks. The browser-authentication boundary is especially important: for sources that require browser credentials, Media Pocket can work through Media Cookie Broker without turning its own worker into the holder of a complete human session.

The project is useful as a compact example of a user-facing interface combined with long-running background work, unstable external sources, and verifiable state—without pretending those differences are one synchronous call.