iovxw/rssbot: A lightweight Telegram RSS notification bot

Why iovxw/rssbot fits Telegram feed monitoring

iovxw/rssbot addresses a narrow notification problem: turning subscribed web feeds into messages inside Telegram. It is for people who want feed updates without opening a separate reader whenever an article or release note appears. The supported formats include RSS 0.9, 0.91, 0.92, 0.93, 0.94, RSS 1.0, RSS 2.0, Atom 0.3, Atom 1.0, and JSON Feed 1. That coverage makes it relevant to sites that use different feed syntaxes, although the README does not claim that every malformed or extension-heavy feed will parse correctly.

The interaction model is appropriately small. A user can list current subscriptions with `/rss`, add one with `/sub`, remove one with `/unsub`, and export the collection as OPML. Group administrators can restrict bot commands through the `--restricted` option, while operators can limit use to explicit user IDs through repeated `--admin` arguments. These controls matter because a Telegram bot token and public bot endpoint can turn an unrestricted feed bot into a shared resource.

The project is not positioned as a full feed library, archiving system, or analytics service. The documentation contains no article filtering, folder organization, read-state synchronization, full-text search, or recommendation features. Its useful boundary is simpler: subscribe to feed URLs and receive notifications through Telegram.

How rssbot handles Telegram, feeds, and persistence

The repository identifies rssbot as a Rust application built around asynchronous I/O. `Cargo.toml` includes `tokio` with its `full` feature set, while feed requests use `reqwest`, XML parsing uses `quick-xml`, and JSON serialization uses `serde_json`. Telegram handling is implemented through the repository's local `tbot` package, shown by a path dependency rather than only an external crate reference.

The operational model is feed polling with bounded timing controls. The default minimum interval is 300 seconds, the default maximum is 43,200 seconds, and the default maximum feed size is 2,097,152 bytes. A value of `0` disables the feed-size limit. These settings create explicit boundaries for feed retrieval, but the README does not describe the exact scheduler implementation, retry policy, duplicate-suppression algorithm, or behavior after repeated fetch failures. Engineers should not infer those details merely from the command-line names.

Subscriptions are stored by default in `./rssbot.json`. The migration script demonstrates the expected record fields: `link`, `title`, `error_count`, `hash_list`, and `subscribers`. This reveals that the project associates each feed with subscriber identities and per-feed error information. It also shows why JSON persistence is suitable for a lightweight deployment but requires scrutiny for multi-writer or transactional workloads.

Building and starting the Rust Telegram bot

The README asks users to try a precompiled release first. Linux builds marked as `musl` are described as statically linked and requiring no additional dependencies, while builds with `zh` in the name are identified as Chinese versions. If a precompiled program does not meet the deployment requirement, the documented build path uses Rust Nightly and Cargo. The README recommends `rustup` for installing the Rust toolchain.

Build the release binary from the repository root:

cargo build --release

The resulting executable is documented at `./target/release/rssbot`. Start it by supplying the Telegram bot token as the positional argument. The token can instead be provided through `RSSBOT_TOKEN`:

The token must first be obtained through Telegram's bot creation process. Once the process starts and Telegram accepts the bot connection, use `/sub` in a Telegram conversation with the feed URL. The README gives this exact command shape:

/sub http://example.com/feed.xml

The success response is not specified in the README, so operators should expect the newly subscribed feed to appear when listing subscriptions with `/rss`. This first-use sequence depends on a reachable feed URL, valid Telegram credentials, and network access to both Telegram and the subscribed host.

Proxy, TLS, and fetch-limit trade-offs in rssbot

The proxy configuration is asymmetric by design. `HTTP_PROXY` and `HTTPS_PROXY` configure HTTP proxying, while `RSSBOT_DONT_PROXY_FEEDS=1` keeps all subscribed RSS requests outside the proxy and routes only Telegram traffic through it. This is useful where direct feed access is required but Telegram connectivity depends on a proxy. The README explicitly says that `NO_PROXY` is unsupported and links the underlying reqwest issue.

TLS selection is controlled through Cargo features. The default feature is `rustls`, while `native-tls` is available as an alternative. A separate `hosted-by-iovxw` feature enables a subscription limit, but the README does not document the limit's value or intended hosting policy. Selecting a feature therefore requires reviewing `Cargo.toml` and the resulting behavior rather than assuming every feature is a documented end-user option.

The `--insecure` flag accepts invalid TLS certificates. The CLI labels it as dangerous, and it should be treated as an exceptional deployment choice. It weakens certificate validation for affected requests, but the README does not specify whether the setting applies to Telegram requests, feed requests, or the full HTTP client configuration. Operators who cannot trace that scope from the source should leave the flag unset. By contrast, the documented feed-size and interval limits make unexpected feed traffic easier to constrain.

Database export and migration limits in the 2.x bot

The `/export` command produces OPML, which provides a path away from the bot's native database when users need feed lists in another subscription format. This is an export capability, not documented import support. The README does not show a corresponding OPML import command, so restoring that file through rssbot is not a confirmed workflow.

Migration from the earlier Clojure Telegram RSS bot is handled by a shell script that queries the old SQLite database and emits JSON records in rssbot's current shape. The script accepts the old database path and target JSON path as its first and second arguments. The README describes the conversion procedure but does not name a file or executable for the script, so an invocation should not be invented.

The migration script reads feed URLs and titles from the old `rss` table, then reads subscriber records associated with each feed. It writes the current `link`, `title`, `error_count`, `hash_list`, and `subscribers` fields. This is a data transformation rather than a complete history transfer.

Migration has a direct operational consequence: already delivered RSS records are not preserved. Starting with the converted database can therefore resend old entries. The script resets each feed's `hash_list` and `error_count`, so migration should be planned around duplicate notifications rather than treated as a transparent database conversion.

rssbot compared with a conventional feed reader

The clearest alternative is a conventional feed reader with its own subscription database and user interface. That approach separates feed collection from Telegram. Readers commonly provide a place to browse retained articles, organize subscriptions, mark items as read, and revisit feed history. The iovxw/rssbot documentation does not claim those capabilities, so choosing it means choosing Telegram as the primary surface for feed interaction.

Another approach is a generic scheduled fetcher connected to a Telegram webhook or another notification channel. Such a design can separate ingestion from delivery and may fit environments that already have a database, job scheduler, retry system, and observability stack. rssbot instead presents subscription commands, polling controls, Telegram access controls, feed parsing, and notification delivery as one small executable with a JSON persistence file.

That compact boundary reduces deployment components, but it also concentrates responsibilities in one process. The repository includes `src/`, `tests/`, locales, and a local `tbot` package, yet the README does not document horizontal scaling, leader election, backup coordination, or safe concurrent writes. A separate ingestion and delivery architecture offers more control over those concerns, while rssbot offers a shorter path from a feed URL to a Telegram chat.

Release status, upgrades, and the Unlicense obligations

The repository is not archived, and the last push was on 2026-08-17. However, the listed release history remains on the 2.x alpha line. The newest documented release is `v2.0.0-alpha.13` from 2024-12-22, while the earlier listed releases are `v2.0.0-alpha.12` from 2023-07-23 and `v2.0.0-alpha.11` from 2021-09-26. Recent repository activity and the maturity implied by release naming are separate facts, so this version label remains an adoption concern.

An upgrade from the old Clojure implementation carries the highest documented cost because the data must be converted and prior delivery hashes are lost. Upgrades between future Rust releases are not documented, and the README provides no compatibility policy or database migration command for rssbot 2.x. Operators should preserve the JSON file before replacing a binary, but the documentation does not specify whether every future version can read an older file.

The project uses the Unlicense and describes the software as released into the public domain. The README says anyone may copy, modify, publish, use, compile, sell, or distribute it, in source or binary form, for commercial or non-commercial purposes. That permission is broad and should be checked against the complete `UNLICENSE` text for a deployment requiring formal license provenance.

Editorial conclusion

iovxw/rssbot fits individual Telegram users and small groups that need direct feed notifications without a separate feed dashboard. It is a poor fit for organizations requiring documented clustering, database transactions, mature release guarantees, or a stable non-alpha upgrade path. Before adoption, verify feed scheduling against the documented minimum and maximum intervals, confirm that the default JSON database matches the deployment's persistence needs, and account for the 2.x migration boundary.

Frequently asked questions

Official sources

1. iovxw/rssbot on GitHub
2. License: Unlicense
3. Project website
4. README
5. Releases