sinavm: a hub for open-source tooling aimed at users on restricted networks

What the hub is and what it is not

The project description sets out the constraint plainly: where the internet is national and restricted, the content of channels and the configurations of circumvention tools can be reached without needing a VPN of your own.

The hub's own author explains the scope in the README. He builds open-source tools so that people in conditions of disruption or restriction can reach information, documentation and tools. And he is explicit that this profile is not only a configuration distribution centre. Part of the work is collecting and converting subscriptions, and the larger part is documentation, mirrors, network status and GitHub automation.

That distinction matters, because it explains why the project is a set of repositories rather than an application. The repository tree is a website: index.html, new-config.html, xray_sub.html, wireguard.html, amnezia.html and a google-prefixed page at the root, plus a legal_pages/ directory, a logo/ directory, a media/ directory, a tutorials/ directory and a scripts/ directory. There is a sitemap.xml, a post-channels directory with a trailing space in its name, and an overlay script called post-overlay.js.

The data side is equally visible. There is a posts_formatted.json holding the content that appears as channel posts, a telegram-posts.html page and a telegram-posts.yml file, and telegram_script.py, which is what fetches and formats that content.

So the architecture is a static site generated or updated from a handful of data files, hosted on GitHub Pages, with the automation in the scripts/ directory and the content in the JSON and YAML files. Updates go out through Telegram and through GitHub, according to the README, which is a sensible pair of channels for an audience whose network access is unreliable.

The eleven sibling projects and their status

The README lists the related projects in a table with a description and a status column, and the status column is the most useful thing in it.

SVM is the subscription collection and conversion project, marked active. The sinavm hub itself, GitHub Pages plus the hub, is also marked active. The remaining entries are marked new or in maintenance.

The new ones are net-status-ir, which reports the availability status of public services, fa-devtools, a mirror and useful tools for the restricted network, channel-mirror, which archives channel content on Pages, php-actions-kit, a template of GitHub Actions for PHP, fa-readme, a template for a Persian README, sing-box-docs-fa, Persian documentation for the sing-box client, and ir-oss-list, a list of Iranian open-source projects.

Two are in maintenance rather than new: melishekan, a client backup, and the sing-box page, described as an old client page.

The stack badges below the table are PHP, HTML5, JavaScript, Python and GitHub Pages, which matches the file listing: PHP for the Actions template, Python for the collection script, JavaScript for the overlay, and HTML for the pages.

Two of these deserve a second look. net-status-ir and ir-oss-list are the kind of project that is more useful to someone arriving cold than the configuration distribution itself, because they answer the question a new user actually has, which is what is reachable right now and what else exists. And the documentation translations, sing-box-docs-fa and fa-readme, are infrastructure in a broader sense: they make the existing tools usable by the people who need them, which is a different contribution from extending the tools themselves.

The configuration pipeline and the file formats

The pages at the root of the repository map onto the configuration formats the ecosystem uses.

There is xray_sub.html for Xray subscriptions, wireguard.html for WireGuard, and amnezia.html for Amnezia, with the repository topics naming sing-box, v2ray, v2box, streisand and amnezia-vpn alongside the configuration and subscription tags. So the hub is format-aware: it collects and converts subscription material for several clients rather than publishing one canonical configuration.

new-config.html is the page for adding a configuration, and it is presumably the front end to the collection pipeline that SVM implements.

The Telegram content has its own pipeline. telegram-posts.html renders the channel posts, telegram-posts.yml holds them in a YAML form, posts_formatted.json holds the formatted version, and telegram_script.py is the script that fetches and formats them. That is a sensible arrangement, because the YAML and the JSON are what the site reads, and the script is what regenerates them, so the site can be rebuilt without running Python.

post-channels/ with the trailing space in its name is the directory holding the per-channel material, and post-overlay.js is a client-side script that overlays something on the page. legal_pages/ is there for the notices a public site hosting configuration material needs, which is a detail that says the author is thinking about the legal exposure of what the site distributes.

The GitHub Pages hosting is itself a design decision with consequences. It means the content is distributed by a CDN that is reachable in ways the origin might not be, and it means the repository is the source of truth for the published material, with every update visible in the commit history.

Limits: personal infrastructure, an unclear licence, and the trust problem

Several limits are worth being concrete about.

The first is that this is one person's infrastructure. The README is written in the first person, the author names himself, and the project list is organised around what he happens to be maintaining. The projects in maintenance are in maintenance because there is one maintainer. That is a reasonable arrangement for the audience, who need tools that work now rather than a project with a governance model, and it means the work stops if the person stops.

The second is the licence. The repository records the licence as unknown and there is no LICENSE file in the top-level listing, though there is a SECURITY.md and a CONTRIBUTING.md. For a hub whose output is configuration files that other people's clients will consume, an unclear licence is a genuine problem for anyone who wants to reuse the tooling.

The third is the trust problem, and it is inherent rather than a failing. A configuration file distributed to a user is a file that will route their traffic, and the user has to decide whether the person who produced it is trustworthy. The answers available are the visible commit history, the personal identity of the author, the Telegram channel and the security policy. That is a weaker trust chain than a signed release from a company, and a user who weighs those things differently should use a different source.

The fourth is that the collected subscriptions are, by nature, moving targets. A subscription that works today may not work next week, and the site is a snapshot of a changing network. The README's own framing of the work as status reporting and mirrors recognises this.

And the fifth is the scope of the format support. The pages cover a specific set of clients. A configuration for a client the hub does not cover is not here, and the conversion step in SVM is what makes one collected form usable by several clients, which means a format the converter does not handle is a format that does not work.

This hub against a self-run client and against the clients' own documentation

Two comparisons make the choice clearer.

The first is against running the client yourself with a configuration you obtained elsewhere. The difference in approach is that a hub does the collecting and the converting so you do not have to. If you already have a working configuration and a working client, the hub adds nothing to your setup, and it adds a dependency on someone else's collection staying current.

Where it earns its place is the second case, which is the one the README describes. A person on a restricted network may not be able to reach a subscription URL that works for someone else, may not know which of several formats their client expects, and may need the configuration in a converted form. The hub's value is the conversion and the availability reporting, and for the users the author describes, that is a real saving.

The second comparison is against the client projects' own documentation. The hub's documentation translations, sing-box-docs-fa and fa-readme, are the Persian versions of the upstream material. The difference in approach is that the translation is maintained alongside the tools rather than upstream, so it can be updated when a new client version lands, and it is aimed at readers who are reading documentation for the first time in a language the upstream project does not publish in.

That is worth separating from the configuration distribution, because it is the part with no trust problem attached. A translation of documentation is verifiable against the original by anyone who reads both, and it does not route anybody's traffic. The configuration distribution is the part where trust matters, and the hub is honest that the two are different kinds of work.

Editorial conclusion

Adopt sinavm if you are developing for users on a restricted network and need a distribution point for configuration subscriptions, mirrors or documentation that survives the network being unreliable. Do not treat it as a substitute for the underlying client software, since the hub distributes rather than implements the protocol side. Verify first which of the sibling projects is maintained and which are archived, that the configuration format you consume matches the client you use, and that the source of a configuration is one you trust before you put it into a working setup.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. sinavm/sinavm on GitHub