Admin Hub Chat Help 🇬🇧 🇨🇳 🇮🇳 🇪🇸 🇨🇿 🇩🇪 🇳🇱 🇫🇷 🇮🇹 🇵🇱 🇷🇴 🇷🇺

Purpose Of The Hub Chat Tool

The Hub Chat tool is an admin-only live Direct Connect diagnostic client. It connects to public NMDC, NMDCS, ADC, and ADCS hubs with a controlled identity, keeps the hub socket in a background session worker, streams incoming hub events to the browser, lists online users, records raw protocol requests and responses, and lets an administrator send public chat messages when the hub allows the current user class to speak.

Use it when you need to confirm what a hub actually sends during login, verify whether a hub accepts guest or registered chat, inspect MOTD and hub bot notices, test username/password access, compare hub requirements against the public profile, or troubleshoot why a hub appears online but still blocks real users.

Session Persistence And Live Updates

When you connect, the application creates a session id and keeps it in the page URL. Refreshing the page should resume the same chat session instead of starting over. Live updates use a streamed connection where possible, with state polling as a fallback, so chat lines, user-list changes, raw frames, and status changes can appear without a full page refresh.

Closing a session asks the worker to disconnect from the hub and keeps the transcript available for review. Reconnect uses the saved target, protocol, nickname, password setting, and advanced profile values to start a fresh socket while preserving the same browser-side diagnostic session.

Connection Fields

• Host Or Address: Enter a public hostname, IP address, or full hub URL such as dchub://example.com:411 or nmdcs://hub.example.com:4111. When a hub URL includes a protocol and port, the form should use those values for the protocol and TCP port fields.
• Protocol: Choose the Direct Connect protocol to test. Secure protocols such as NMDCS and ADCS perform a TLS handshake before hub login.
• TCP Port: Optional override. Leave it empty when the protocol default is correct, or enter the exact advertised hub port when the hub uses a custom port.
• Username / Nickname: Use a registered hub nickname when testing account access, or leave it empty to generate a temporary identity such as user-123456.
• Hub Password: Used only when the hub requests a password for the selected nickname. Passwords are redacted from raw outgoing transcripts and should not appear in streamed events.

Advanced Client Profile

The advanced profile controls the identity values a DC++ client normally exposes to a hub: fake share size, upload slots, connected hub counts, registered hub counts, operator hub counts, optional open ports, description, email, client tag, and NMDC support flags.

These values matter because many hubs restrict guests by minimum share, slot count, hub count, client tag, IP visibility, registration class, or TLS support. The chat client should not send BotINFO by default, because this is a normal diagnostic chat client, not a bot. Enable BotINFO only when intentionally testing bot-style behavior.

Advanced Profile Field Reference

Use the advanced profile to reproduce what a real DC++ client would report during login. These values are advertised to the hub only for the current diagnostic session; they do not publish files, open firewall ports, or change the public hub record.

NMDC Support Flags

The NMDC Support Flags field chooses the $Supports capabilities sent during NMDC or NMDCS login. These flags tell the hub what optional NMDC features the client understands. They can affect login order, user-list behavior, bot lists, IP visibility, and whether the hub treats the connection like a normal user or a bot.

Practical Presets

• Normal Chat Test: Use a realistic fake share, at least one open slot, normal hub counts, your registered nickname/password when available, and keep BotINFO disabled.
• Restriction Test: Use fake share 0, low slots, and low hub counts when you intentionally want the hub to explain minimum-share, slot, or class restrictions.
• Registered Hub Admin Test: Use the hub nickname and password configured for the hub or pinger, realistic client stats, and the normal support flags. This is the best way to confirm whether guest restrictions are hiding MOTD, chat history, or user lists.
• Bot Behavior Test: Enable BotINFO only when testing bot-specific rules. If chat becomes restricted or the user appears as a bot, disable BotINFO and reconnect.

Live Chat, Raw Logs, And Users

The chat panel shows connection status, MOTD blocks, hub bot notices, history blocks, restriction messages, main chat, and messages accepted from the hub. A message appearing locally is not enough by itself; public chat is only considered meaningful when the worker writes the protocol frame and the hub responds or broadcasts it.

The raw response panel shows incoming protocol frames from the hub, including lock strings, supports, hub name, force-move commands, password requests, user-list frames, bot messages, MOTD text, and restriction notices. The raw request panel shows outgoing protocol frames with secrets redacted, so you can confirm exactly what the diagnostic client sent.

The Online Users panel shows parsed hub users in a dense searchable table. Operators sort before normal users, then nicknames sort naturally. Search filters by nickname in the browser. Description and client tag are separate fields, share is displayed as B/KB/MB/GB/TB while sorting by bytes, and IPv4/IPv6 fields may show a country flag when the hub provides enough information.

Blue, Silver, And Gold Role Icons

The live chat user list uses the same role language as hub profile pages. A silver robot marks a bot or service user, such as a feed bot, security bot, hublist bot, clock bot, or automated announcement account. A gold key marks an operator or privileged account. A blue user icon is used on hub profile snapshots for registered or recognized user entries when the hub exposes that role. Keeping bot users silver avoids confusing automated service accounts with normal recognized users.

Common Errors And Restrictions

• Main Chat Disabled: The hub accepted the connection, but the temporary class cannot write to public chat. Use a registered nickname and password if you expect chat access.
• Invalid Login Sequence: The hub rejected commands sent before nickname validation completed. Reconnect and wait for logged-in status before sending chat.
• Force Move: The hub redirected the client to another host or port. Use the destination returned by the hub if the redirect is intentional.
• Password Requested: Enter the registered hub password for that nickname and reconnect.
• No MOTD: Some hubs send MOTD only to registered users, only after password validation, or only after the expected client profile is accepted.
• No User List: Some hubs hide user lists from guests, send user data slowly, or require specific support flags.
• Protocol Mismatch: Plain NMDC against a TLS port, or NMDCS against a plaintext port, can look like a timeout or filtered connection.
• Closed Or Filtered: The socket closed before login completed, usually because of firewall filtering, bans, bad requirements, or a hub-side restriction.

Operational Safety

Close sessions when done so the hub does not keep a ghost user online. Do not repeatedly test the same public hub; rotate low-requirement hubs from the live hublist when debugging. The tool blocks private and reserved networks, caps transcripts, bounds sessions, redacts passwords, and ties browser activity to worker cleanup.

Icon Reference