How sarveshhrathod/file-to-link works
1. This repository is a single Python service that combines a Telegram bot with a small HTTP server. The bot is the primary entrypoint for users, while the web server hosts the generated download and streaming pages/URLs.
2. The Telegram-facing side lives under Adarsh/bot/. clients.py likely creates the Pyrogram/Telegram client(s), and plugins/ contains the handler groups: start_help.py for onboarding and help, stream.py for file-link generation and streaming actions, admin.py for owner/admin commands, and extra.py for miscellaneous commands and callbacks.
3. The main user flow is: a user sends or forwards a Telegram media file to the bot, the bot captures the file metadata and Telegram file reference, and then produces a “Get Download Link”/stream link instead of waiting for a full re-upload. The bot can also operate on channel posts, so the channel acts as an ingestion/source boundary as well as a publishing surface.
4. The BIN_CHANNEL is an important architectural boundary. Files are expected to be present in a Telegram channel the bot can access as admin; from there the bot can create links and update channel messages with buttons or link text. This keeps the actual file hosting external to the app and lets Telegram serve as the storage backend.
5. The HTTP layer is under Adarsh/server/. stream_routes.py exposes the web endpoints that likely back the direct download and streaming links, while exceptions.py holds server-side error handling. The HTML templates in Adarsh/template/ define the user-facing pages for requesting a link and downloading/streaming a file.
6. Utilities in Adarsh/utils/ provide most of the non-bot business logic. custom_dl.py appears to encapsulate the file-link/download behavior, file_properties.py, file_size.py, human_readable.py, and time_format.py format file and status metadata, render_template.py connects Python data to the HTML templates, and config_parser.py/database.py handle configuration and persistence concerns.
7. Persistence is narrow but important: MongoDB is used to store user IDs and support broadcasting. That means the bot has a lightweight state store for membership/recipients, separate from Telegram’s own file storage and separate from the web server’s stateless request handling.
8. Access control and operational checks are built into the bot flow. The README mentions password protection (MY_PASS), an optional updates channel gate, banned channels, and a “login” command, so requests can be filtered before a link is issued. This makes authorization a first-class part of the request pipeline.
9. Runtime and deployment are tuned for a hosted bot/web hybrid. __main__.py starts the application, keepalive.py suggests a ping/heartbeat mechanism for uptime hosts, and Procfile, app.json, and runtime.txt indicate Heroku-friendly deployment. The app is configured via environment variables in vars.py and the README’s config.env example.
10. From an architecture-diagram perspective, the key external systems are Telegram, MongoDB, and the hosting platform. The app itself sits in the middle, transforming Telegram media messages into HTTP-accessible stream/download links, storing only minimal user state, and serving lightweight HTML pages for the link experience.
Main entry points: stream_routes.py Routes · __main__.py Entry · clients.py Clients · stream.py Stream flow
Components 18
App core
Main Python service that coordinates bot, web server, and startup.
Telegram bot
Telegram-facing entrypoints, handlers, and file-link flow.
- Clients · Creates and configures Telegram/Pyrogram clients.
Adarsh/bot/clients.py - Start/help · Greeting, help, and basic user entry flow.
Adarsh/bot/plugins/start_help.py - Stream flow · Handles media intake and produces download/stream links.
Adarsh/bot/plugins/stream.py - Admin · Owner/admin controls and operational commands.
Adarsh/bot/plugins/admin.py - Extra · Additional commands, callbacks, and support actions.
Adarsh/bot/plugins/extra.py
HTTP server
Web endpoints and templates used for download/stream pages.
- Routes · Web endpoints that serve link pages and file access paths.
Adarsh/server/stream_routes.py - Errors · HTTP/server-side exception handling.
Adarsh/server/exceptions.py - Request page · Page for requesting or initiating a file link.
Adarsh/template/req.html - Download page · Page for downloading or streaming a file.
Adarsh/template/dl.html
Shared utils
Business logic, formatting, persistence, and support helpers.
- Link engine · Encapsulates file-link and download behavior.
Adarsh/utils/custom_dl.py - File props · Extracts file properties and identifiers.
Adarsh/utils/file_properties.py - Formatting · File size, human-readable, and time formatting helpers.
Adarsh/utils/file_size.py - Render · Renders Python data into HTML templates.
Adarsh/utils/render_template.py - Database · Stores user IDs and broadcast-related state.
Adarsh/utils/database.py - Broadcast · Supports broadcast messaging to stored recipients.
Adarsh/utils/broadcast_helper.py
Connections 25
- Entry → Clients: boot · Initializes Telegram clients and handlers.
- Entry → Routes: serve · Starts the HTTP layer for download/stream pages.
- Entry → Config: load config · Reads runtime configuration from environment and parser state.
- Entry → Keepalive: ping · Enables uptime/heartbeat behavior for hosted deployments.
- Clients → Start/help: register · Attaches onboarding handlers.
- Clients → Stream flow: register · Attaches media-to-link handlers.
- Clients → Admin: register · Attaches owner/admin commands.
- Clients → Extra: register · Attaches miscellaneous commands and callbacks.
- Stream flow → Link engine: generate · Uses link/download logic to create streamable URLs.
- Stream flow → File props: inspect · Reads media metadata and file reference details.
- Stream flow → Formatting: format · Formats size and status text for users.
- Stream flow → Database: store · Persists user or request state when needed.
- Admin → Broadcast: fanout · Uses broadcast support for owner messaging.
- Broadcast → Database: read recipients · Pulls recipient identifiers from persistence.
- Routes → Render: render pages · Builds HTML responses from template data.
- Routes → Request page: uses · Serves the request page template.
- Routes → Download page: uses · Serves the download/stream page template.
- Routes → Link engine: resolve links · Connects HTTP requests to file-link behavior.
- Routes → Errors: handle errors · Routes server failures through centralized handling.
- Render → Request page: fill · Renders request page context.
- Render → Download page: fill · Renders download page context.
- Link engine → File props: uses · Depends on file metadata to build responses.
- Link engine → Formatting: uses · Formats sizes, durations, and human-readable text.
- Keepalive → Config: config · Uses deployment settings for ping behavior.
- Entry → Database: init state · Ensures persistence is available at startup.