uhub ADC And ADCS Hub Software

uhub, pronounced "you hub", is an open-source Direct Connect hub server created by Jan Vidar Krey. Development dates back to 2007, and the project is released under the GNU General Public License version 3. It is written in C and is designed specifically for communities that use ADC-compatible clients such as DC++, AirDC++, and other modern Direct Connect applications.

A hub is the meeting point for a Direct Connect community. uhub keeps track of connected users, relays public and private chat, distributes searches and search results, applies access rules, and helps clients establish direct connections with one another. The actual files do not pass through uhub. Once two users decide to exchange a file, the transfer normally takes place directly between their clients. This distinction allows a relatively small server to coordinate a much larger amount of file-sharing activity than it could relay by itself.

This also matters for browser-based or server-hosted clients. Connecting a web client to uhub can provide chat, user lists, and search functionality, but it does not automatically turn peer-to-peer transfers into ordinary web downloads. The web client or its supporting service must still implement the client-to-client transfer process. uhub coordinates the users and their connection requests; it is not a file-storage service, download proxy, or web server.

uhub was built around a small, event-driven core with low memory use. A private hub can run on modest hardware, including small Linux systems and embedded devices, while larger installations can serve thousands of connected users on more capable servers. It supports IPv4 and IPv6, encrypted connections, registered accounts, operator permissions, bans, flood protection, optional plugins, monitoring, and several ways to expand a hub as its community grows.

The project has developed in stages. Version 0.5.0 was released in 2014 as portable source for Linux, macOS, BSD, and Solaris. Development accelerated again in 2026. Version 0.6.0 modernized the project’s TLS requirements and plugin interface. Version 0.7.0 added monitoring, multi-process operation, and the ability to link several uhub installations into one logical hub. Version 0.7.1 improved user commands, authentication, connection limits, and security checks. Version 0.8.0 added sandboxed JavaScript plugins, richer chat formatting, expanded moderation, self-service account tools, faster detection of dead connections, and restored Windows builds.

The official project still describes uhub as alpha-quality software rather than a mission-critical service platform. That does not mean it is only a demonstration, but it does mean an operator should test the selected release, plugins, clients, backup process, and upgrade procedure before depending on it for an important public community.

ADC And ADCS Operation

uhub serves communities that use ADC, the modern Direct Connect protocol. Users connect with an ADC-compatible client and enter an address beginning with adc:// or adcs://. ADC provides the normal hub connection, while ADCS adds TLS encryption between the client and the hub.

An encrypted ADCS connection protects account authentication, chat, searches, user information, and other traffic exchanged with the hub. It does not encrypt a file by routing it through uhub. Direct file transfers remain separate connections between clients and depend on the capabilities and settings of those clients.

Operators can allow both encrypted and unencrypted connections or require ADCS. Current uhub versions support TLS 1.2 and TLS 1.3 through OpenSSL or LibreSSL. The published hub address, hostname, certificate, and listening port must refer to the same service. A server can accept a basic network connection while still rejecting the later TLS handshake, login, account authentication, or ADC negotiation.

uhub supports both IPv4 and IPv6 and can prefer IPv6 where it is available. This allows one community to serve users on either network type, although direct transfers still depend on whether the two clients can establish a compatible route. uhub also contains support for NAT-related connection coordination, but it cannot override a user’s firewall, router, provider restrictions, or incorrectly configured client.

A public operator can provide a hub name, description, owner, website, network name, and published address. uhub can also announce itself to a compatible hublist registration service. Private hubs can leave registration disabled and accept only invited or registered users.

Operations And Extensions

• Small And Large Communities: The default installation runs as one event-driven process and is suitable for many private and public hubs. Operators can choose the maximum number of users, decide whether guests are allowed, require registered accounts, limit connections from one address, and set rules for minimum share, upload slots, search terms, or the number of other hubs a user may be connected to.
• Accounts And Moderation: Authentication plugins can provide registered accounts for members, operators, and administrators. Depending on the enabled plugins, users may be registered by an operator or allowed to register themselves. Moderation features include nickname, CID, and IP restrictions; temporary or permanent bans; ban reasons; chat restrictions; flood controls; recent-user information; topic management; and operator commands. Version 0.8.0 moved registered accounts out of the older access-control file and into authentication plugins, so existing installations must migrate those records during an upgrade.
• Chat And Community Features: uhub can retain a configurable amount of recent main-chat history, display welcome messages, publish hub rules, expose commands in compatible clients, and restrict chat or private messages according to account level. Version 0.8.0 added support for the RTF0 rich-text extension. Clients that support it can display formatted chat, messages, and remote images, while older clients continue to receive plain text. Operators who do not want clients loading images from external URLs can disable that feature.
• Using More Than One CPU Core: uhub runs in single-process mode by default. A larger installation can set workers to a value greater than one so several worker processes share the same listening port and appear to users as one hub. Setting workers=0 selects one worker for each available CPU core. This is useful when encryption or a large number of connections makes one process the limiting factor. Users do not need separate addresses for the individual workers.
• Linking Hubs Across Machines: Federation connects separate uhub installations and makes them appear as one larger community. Users connected to different nodes can share one visible user list, chat with one another, exchange private messages, search, receive search results, and establish direct transfers across node boundaries. Topics and live bans can also be propagated. Federation is still documented as experimental and is intended for trusted systems. An operator should understand its limitations, test reconnection and split-network behavior, and protect the shared credentials used by linked servers.
• Plugins: uhub keeps many optional features outside its core and loads them through plugins. Bundled plugins can provide SQLite or file-based authentication, logging, chat history, welcome messages, topic commands, self-registration, flood responses, command menus, and restricted chat. Native C plugins have broad access to the running hub and must match the plugin API of the installed release. Version 0.8.0 also added JavaScript plugins through QuickJS. JavaScript extensions run in a restricted environment without ordinary filesystem or network access, making them suitable for many custom commands and event-based features without compiling C code.
• Monitoring: Version 0.7.0 added an optional Prometheus-compatible metrics endpoint. It can report connected users, connections, transferred hub traffic, message counts, and event-loop timing. The endpoint is disabled by default and requires a bearer token. Operators should access it over HTTPS, loopback, or a trusted management network because sending the token through plain HTTP can expose it.
• Connection Recovery: Current releases periodically check idle connections so users whose network session disappeared without a clean disconnect can be removed promptly. This reduces situations in which a reconnecting client is refused because the hub still believes its old session is active. This feature improves recovery from interrupted Wi-Fi, NAT, firewall, and client connections without changing how ordinary active users are handled.
• Installation And Platforms: The official repository provides source code and release packages. Current project documentation covers Linux, macOS, BSD, and Windows, with packages for common x86-64 and ARM64 systems. Debian and Ubuntu users may also use the community-maintained package repository linked by the project. Operators building from source need a current C compiler, CMake, SQLite development files, and a supported OpenSSL or LibreSSL version.
• Configuration And Backups: The main settings are stored in uhub.conf, while account data, access rules, plugins, certificates, and related files may be stored separately. A complete backup should include all of them, along with the installed release, service definition, and plugin versions. Before upgrading, test the new version on another port or system and confirm login, accounts, moderation, chat, searches, plugins, TLS, monitoring, restart behavior, and client compatibility.

Official uhub Resources

The official uhub website, documentation, news archive, repository, releases, and issue tracker provide the most reliable information about the project. Use documentation that matches the installed version because configuration, authentication, plugins, moderation, and scaling behavior changed substantially in the 0.6, 0.7, and 0.8 release lines.

The GitHub repository contains the source, example configuration, plugin examples, build instructions, tests, and complete change history. The documentation site is more suitable for readers who want to install or operate a hub without reading the source code. Reproducible software defects and feature requests should be submitted through the issue tracker with the exact release, operating system, configuration details, relevant plugins, logs, and steps required to reproduce the problem.