OpeniLink Hub: a self-hosted WeChat bot platform built on the iLink protocol

The gap between the iLink protocol and a working bot

The README frames the problem in one line: iLink is a raw channel that can receive messages and send replies, and nothing more. Everything around that channel is left to the developer. The listed chores are context_token management, CDN encryption for media, the 24 hour session window, and running more than one bot. The project's own comparison table describes iLink as having no official documentation and being understood largely through community reverse engineering. That is the gap OpeniLink Hub claims to close. It is not a protocol implementation with a thin CLI wrapper. It ships a web console, a message scheduler, an app marketplace, and SDKs in seven languages, with the stated goal that you receive messages and send replies while the platform handles the rest. The audience is therefore specific: developers who have a WeChat bot idea and do not want to spend the first weeks of the project on token lifecycle and media upload. It is less useful to someone who only needs to send one message a day from a script, because the platform is a bigger surface than the task.

How messages move through the hub

The architecture in the README is a fan-out. A WeChat ClawBot plugin talks to the OpeniLink SDK over iLink, and the SDK feeds a message scheduler inside the hub. From there the scheduler dispatches to five kinds of destinations in parallel: installed apps, WebSocket clients, HTTP webhooks, an AI auto-reply path that calls an OpenAI-compatible API, and custom apps. The app layer is itself split by category, with platform bridging apps for Lark, Slack, Discord, DingTalk and WeCom, productivity apps for GitHub, Google Workspace, Notion and Linear, and lighter utilities for weather, currency, expense tracking, reminders, cron, RSS and QR codes. Each app is described as an independent service that talks to the hub over a standard protocol, which is why the marketplace can list third-party apps alongside official ones. Installation goes through PKCE OAuth. The README also describes message tracing: a per-message view of the path from receipt to delivery with the time spent at each step. That is the part of the design that matters most in production, because when a reply does not arrive, the question is almost always which hop dropped it, and a scheduler with five output channels has five places to look.

Installing it, and the one config key that matters

The README gives two paths. The one-liner is `curl -fsSL https://raw.githubusercontent.com/openilink/openilink-hub/main/install.sh | sh`, followed by running `oih` to start the service. The Docker alternative is `docker run -d -p 9800:9800 openilink/openilink-hub:latest` from Docker Hub, or the same image from `ghcr.io/openilink/openilink-hub:latest`. After that you open `http://localhost:9800`, register an account, and the README states that the first account registered automatically becomes the administrator. Then you scan a QR code to bind a WeChat account. The default storage is SQLite, and the README is explicit that no database installation or configuration is required. The single documented configuration key is `DATABASE_URL`, which switches the backend to PostgreSQL when set. Windows is called out as unsupported natively, with Docker recommended and WSL2 offered as the alternative. Two things are worth noticing here. First, the first-registrant-becomes-admin rule is convenient for a single-operator deployment and a liability if the service is reachable before you register, so bind it to localhost or a private network until the admin account exists. Second, the port is fixed at 9800 in every example; the README does not document an environment variable for changing it, so plan the reverse proxy around that.

The 24 hour window is a reminder, not an automation

The most important limitation is stated plainly in the README rather than buried. WeChat's 24 hour session window cannot currently be silently renewed by the hub in the background. What the platform supports is an expiry reminder: when the window is close to closing, it prompts you to send a message, and once a reply arrives the window restarts. This means the hub reduces the cost of an expiring session but does not remove the human from the loop. Any workflow that assumes unattended, continuous operation across days will break at the window boundary regardless of how the hub is configured. The README also notes that messages are persisted, which limits the damage when a window lapses, but persistence is not delivery. Treat the reminder as a notification that requires an action, not as a keepalive. If your bot's value depends on answering messages at 3am without anyone watching, this design does not deliver that, and no amount of app installation changes it.

The app marketplace is the real surface area

The marketplace is where the project's scope becomes visible. The listed official apps carry tool counts that are large enough to matter for planning: Lark with 34 AI tools across eleven business domains, GitHub with 36, Slack with 23, DingTalk with 20, Discord with 19, WeCom with 18, Google Workspace with 18, Notion with 15, Linear with 13, and Amap with 10. Those tools are natural language operations, so a WeChat message becomes an API call against the third-party platform. That is a substantial amount of integration code that you would otherwise write and maintain yourself, and it is the strongest argument for the platform over a bare SDK. It is also the strongest argument for caution. Every installed app is an OAuth grant to a third party, each one holds credentials, and each one is a service the hub must reach. The README says apps communicate with the hub over a standard protocol, but it does not describe that protocol in the material available, so if you intend to write a custom app you will be reading the source rather than the README. The same applies to the seven SDKs: the languages are listed, the API surface is not.

Where a plain SDK or an agent bridge fits better

The README draws its own distinction against the alternatives on GitHub, which it characterizes as mostly low-level SDKs or agent bridging tools. The difference in approach is real. An SDK gives you functions and leaves process management, storage, multi-account handling and delivery routing to you. An agent bridge assumes an AI agent is the consumer of every message and wires the protocol directly into that agent's loop. OpeniLink Hub sits between them: it is a stateful service with a database, a web console and a plugin registry, and it treats the AI reply path as one of five output channels rather than as the point of the system. The README is also careful about its relationship to OpenClaw, stating that OpenClaw is an AI agent framework while the hub is a message management platform, and that OpenClaw is available inside the hub as a built-in app you can enable or ignore. If your project is a single bot whose only job is to forward messages into one agent, a bridge tool is less machinery for the same result. If you need several bots, an admin console, and non-AI consumers such as webhooks and dashboards, the hub's extra layers are doing work a bridge will not do for you.

Maintenance, licensing and what the disclaimer means

The repository is MIT licensed, which permits commercial use and modification, but the licence covers the code and not the protocol. The README opens with a disclaimer in both Chinese and English stating that the project is independently developed based on the publicly available iLink protocol, for learning and research purposes only, is not affiliated with or endorsed by the official iLink team, and will be taken down upon a rights holder's request confirmed through an Issue. That is an unusual thing to find at the top of a README, and it should shape how you plan. A project that commits to takedown on request is telling you its continued existence depends on a third party's tolerance, so the practical hedge is to keep your own integration code thin enough that the hub is replaceable. On maintenance, the release history shows v0.1.36 on 2026-06-18, v0.1.35 on 2026-04-24 and v0.1.34 on 2026-04-14, with the last push to the default branch on the same day as the newest release. The gaps between those three releases are roughly two months, then three weeks. The version numbers are still in the 0.1.x range, so treat the API as pre-1.0 and pin your image tag rather than tracking `latest`, since the Docker examples use `latest` and that will move under you. Upgrading means re-pulling the image or re-running the install script; the README does not document a migration path for the SQLite database or for `DATABASE_URL` schema changes, so back up the database file before each upgrade and read the release notes for the version you are moving to.

Editorial conclusion

Adopt OpeniLink Hub if you need a self-hosted control plane for multiple WeChat bots and want the iLink details such as context_token handling, CDN upload and encryption handled by the SDK rather than by your own code. Do not adopt it if you need Windows without Docker or WSL2, or if you cannot accept a platform whose core protocol is reverse engineered, because the project's own disclaimer states it is independently developed for learning and research and is not affiliated with or endorsed by the official iLink team. Before committing, verify how the 24 hour session window behaves in your deployment, since the README states it cannot be silently renewed in the background and only supports expiry reminders.

Official sources

1. License: MIT
2. openilink/openilink-hub on GitHub
3. Project website
4. README
5. Releases