Hub Mod

Hub Mod is a persistent Direct Connect administration client for an assigned hub. It connects with a dedicated account, discovers commands from bounded runtime evidence, combines that evidence with reviewed provider catalogues, and gives authorized owners a typed form for each command. It does not invent commands, accept raw command text, or replace the permissions enforced by the hub.

Overview And Availability

Hub Mod is available only when the global feature is enabled and the current website user owns the selected hub or has an allowed administrator role. The Hub Mod page combines the persistent connection, live Hub Chat workspace, discovery state, command catalogue, plugin inventory, command builder, and outgoing activity. Use a dedicated hub account so its identity, class, and audit trail remain separate from a person's normal DC++ client.

The saved profile normally runs in Background Low CPU mode. Opening the live workspace can switch it to Interactive mode so the current guest list, public chat, join and leave activity, and private conversations are available. Disabling Hub Mod stops its worker and prevents automatic startup; disconnecting closes the current socket without changing the enabled setting.

Connection And Permissions

Configure Nickname, Password, client tag fields, Description, Email, Share Size, hub counts, Slots, TCP Port, UDP Port, TLS Port, Identity Aliases, and NMDC support flags to match the account registered on the hub. Passwords remain protected secrets. Identity aliases help the shared workspace recognize the client, but they do not change its login nickname or permissions.

New configurations use HubMOD as the default nickname and HubMOD - hublist.pwiam.com as the default description. Replace either value when the hub requires a different registered identity, but keep the website setting, hub account, and selected Hub Class aligned before connecting.

Hub Class must match the class assigned by the hub. The minimum class reported for a command is checked before the builder opens, but the hub remains the final authority. Class 10 does not bypass missing availability, an incomplete parameter schema, an unknown risk classification, or injection validation. Automatic Reconnection handles transient failures; incorrect credentials and other permanent login failures must be corrected before reconnecting.

Discovery Status

Discover Commands Again creates a new discovery run with its own generation and progress record. The status moves through queued, running, and validating before reaching completed or failed. The status area also shows the last successful run, accepted and rejected evidence totals, added and removed command counts, detected provider versions, and a bounded error message when a run fails.

Hub Mod reads the confirmed software name stored on the hub record. A Verlihub hub receives the reviewed Verlihub Core catalogue from the pinned local source. Discovery never sends !help, +help, !lstplug, !ledohelp, !lualist, or another probe to main chat, #_PH_SECURITY, or another bot. NMDC $UserCommand frames already advertised by the connected hub add reviewed plugin commands such as Ledokol or Lua.

Discover Commands Again creates one bounded catalogue from the confirmed provider and hub-advertised records. Remove Commands only removes the active catalogue. A generation becomes active only with a current reviewed catalogue revision, an executable reviewed command, and provider or hub-advertised evidence. An interrupted, empty, stale, or invalid run leaves the previous active catalogue intact.

Each advertised menu item is treated as structured evidence, never as permission to execute its contents. Unrelated public chat, private messages, oversized records, malformed frames, duplicate entries, and syntax that does not match one unique reviewed definition are rejected. A routine empty, interrupted, stale, or timed-out run leaves the last usable catalogue active. Select Remove Commands only when you intentionally want to discard that catalogue before waiting for fresh advertised menu evidence.

Remove Commands is a separate action. It removes the active catalogue without starting discovery in the current connection. Use Discover Commands Again to start a replacement run immediately. If a live worker handles removal, automatic discovery can run only after the next socket reconnection and only when Automatic Discovery is enabled. A duplicate nickname or rejected credentials are terminal login failures. Other connection failures stop after the configured retry limit and remain Failed until an owner reconnects after correcting the cause.

Open User Panel and select Hub Mod for the assigned hub to remove the current catalogue, start a replacement discovery, or inspect its connection and retry state.

Supported Providers

A verified definition comes from a reviewed pinned source. A runtime_verified entry is a complete structured command advertised by the connected hub; it can run only when it matches the reviewed catalogue. unverified entries remain readable but cannot run. A token such as -a or -b is a parameter of its parent command, never an independent command.

Hub Mod combines two reviewed sources. The confirmed Software value on the hub record activates the matching core catalogue, so a Verlihub hub receives the pinned Verlihub Core definitions without waiting for a chat reply. The connected hub can separately advertise NMDC $UserCommand records for Ledokol, Lua, and other plugins. A nickname, service notice, or private reply is never provider evidence.

A verified definition has pinned official provenance. Hub Software selects Verlihub Core, while hub-advertised $UserCommand records can identify Ledokol or Lua. The strings !help, +help, !lstplug, !ledohelp, and !lualist are documentation examples only; #_PH_SECURITY is never a provider source. A hub-advertised command must match exactly one reviewed definition before it becomes available. Unreviewed, malformed, ambiguous, or oversized data remains diagnostic evidence and cannot run. Hub Mod never treats a chat message or a response to a help command as command-provider evidence.

Verlihub Commands

For a Verlihub hub, the confirmed Software value activates the pinned Verlihub Core catalogue. !help and +help are documentation examples, not discovery traffic. Hub Mod never sends an automated command to #_PH_SECURITY or another account, so a security notice cannot be mistaken for a command provider or pollute the main chat.

Lines such as -a, -b, and -c are option parameters belonging to a parent command, not standalone commands. Inline comments and explanatory text are stored as descriptions and never included in executable bytes. A disabled or unavailable Verlihub command can remain visible with its reason, but its Command button stays disabled.

Ledokol Commands

Ledokol commands become available only when the connected hub advertises matching $UserCommand menu records. The active record supplies the provider or plugin context and exact invocation; the reviewed local catalogue supplies the parameter schema and risk. Hub Mod does not send !ledohelp or another automated help probe to complete discovery.

Reviewed Ledokol definitions supply known parameter types and risk classifications. Runtime text must match the reviewed invocation and syntax; a parameter fragment or prose line cannot become an executable command. When official knowledge and hub-advertised evidence disagree, the command remains unavailable until the definition can be reviewed safely.

Lua And Plugin Commands

Lua and other plugin commands follow the same rule: the connected hub must advertise a structured $UserCommand record that matches a reviewed definition. A plugin name, a help string, or ordinary chat text never causes an automated query or command activation.

Lua scripts may expose commands that are unique to one hub. Such a command becomes executable only when its hub-advertised record matches a complete trusted schema with an explicit risk. If a plugin exposes a name but no usable record, its inventory row remains useful for diagnosis while its commands stay unverified. Rediscover after adding, removing, upgrading, or reconfiguring scripts.

Available Commands And Plugins

The command table shows Command, What It Does, Usage, Minimum Class, Source, Available, and a Command action. Provider and plugin provenance appear together when both apply. Aliases remain attached to their canonical definition. An unavailable row explains that its definition, risk, runtime availability, or configured class is not sufficient for execution.

The plugin table separately shows Plugin, Version, Help Command, Discovered Commands, and Last Seen. The active table always belongs to the last completed generation. Data staged by an unfinished run never replaces it, so an owner can continue inspecting the known catalogue while rediscovery is running or after a failed attempt.

Use Search Commands to filter the active table by command, alias, description, usage, source, or plugin without changing the catalogue. Use Sort By to switch between Purpose Groups and Command Name. Purpose Groups keeps read-only, moderation, configuration, service-control, destructive, and unknown-risk definitions together; the group explains the command's purpose but never grants permission. Command Name gives one alphabetical list. If rediscovery completes after this page was opened, an older action never targets the removed definition: Hub Mod asks you to reload the command catalogue. After reloading, open the current row and review its refreshed availability and form before sending anything.

Command Review And Availability Reasons

A command is executable only when the current generation activates it through the confirmed provider catalogue or a matching hub-advertised record, and it exactly matches a reviewed provider, plugin, normalized invocation, and syntax signature. A high hub class never bypasses review, risk classification, destination rules, or parameter validation.

not_observed

The command was not activated by the confirmed provider catalogue or a matching hub-advertised record.

unknown_command

The runtime command has no matching reviewed catalogue definition.

unreviewed

The definition has not completed the required catalogue review.

unknown_risk

The definition has no reviewed risk classification.

insufficient_class

The Hub Mod account does not meet the command's minimum class.

provider_unavailable

The confirmed provider or matching hub advertisement did not activate the command.

syntax_mismatch

The observed syntax differs from the reviewed definition.

Command

Select Command on an available row to load that exact definition into a Bootstrap modal. The modal displays its description, usage, source, plugin, minimum class, and risk before any value is accepted. There is no raw-command input or general-purpose command entry. Public or private Hub Chat remains available for ordinary conversation, but command-like messages are directed to the verified builder.

The form can offer Main Chat, Private Message, or a provider-fixed destination. A private command requires a recipient. Submitting the form sends the definition key, structured values, delivery choice, recipient, and a server-issued confirmation token when required. The server reloads the active definition and rejects stale, unavailable, unauthorized, or cross-hub submissions.

The information block above the fields repeats the command description and syntax, then identifies the provider or plugin, minimum class, risk, review status, source revision, and evidence hash. Official Wiki opens the provider documentation in the Verlihub Wiki or Ledokol Wiki. Reviewed Source opens the exact catalogue evidence used for the definition. Treat those references as part of the review: if the installed version or runtime syntax differs, rerun discovery and do not submit the command until the discrepancy is resolved.

Parameters And Command Preview

Every command parameter has a separate field in schema order. Required fields must contain a value; Optional fields may be left blank. Supported types include text, nickname, integer, port, choice, Boolean switch, duration, host, hub address, path, and message. The form shows the provider's label, placeholder, description, required state, and allowed choices rather than asking the owner to parse a syntax comment.

The preview updates as values change, but it is informational. The server alone assembles the final command, applies deterministic quoting and escaping, preserves option order, enforces length and type limits, and rejects carriage returns, line feeds, NUL bytes, pipe separators, or a second command prefix. The browser preview never becomes the authoritative payload.

Risk And Confirmation

Every executable definition has one explicit risk: read_only for inspection, moderation for actions affecting users, configuration_change for persistent hub settings, destructive for removal or irreversible changes, or service_control for reload, restart, and stop operations. A definition with unknown risk cannot run.

Read-only commands submit directly. Risks that require another review display a concrete warning naming the selected command and action class, then change the submit action to Confirm And Run. The signed confirmation token binds the active definition, structured values, destination, recipient, and final server-built command. Editing any bound value invalidates that confirmation.

Outgoing Activity

Outgoing Activity records the website user, definition key, provider, plugin, risk, destination, recipient, confirmation state, and timestamps. Structured parameter values and the final command are encrypted at rest. Presentation code shows only data authorized for the assigned owner or administrator, and log context excludes raw payloads, passwords, tokens, and private-message content.

An activity moves from queued to sent when the worker completes the socket write. If delivery cannot be observed safely it becomes delivery_uncertain and is not replayed automatically. Queue or validation failures become failed with a bounded, sanitized diagnostic. The existing application error logger and email notification path remain active.

Rediscovery And Atomic Replacement

Use Discover Commands Again after changing Verlihub, Ledokol, Lua scripts, plugins, command permissions, or the Hub Mod account class. The new run writes commands and plugins to a staging generation while the previous completed generation remains active. Counts show accepted, rejected, added, and removed entries so the change can be reviewed.

Only a fully validated run activates its generation in one pointer swap. Activation removes the previous generation after the new one is durable. A malformed response, timeout, worker shutdown, socket disconnect, or provider failure discards staging and preserves the old catalogue. This prevents a partial discovery from erasing commands that were previously known to work.

Errors And Troubleshooting

Use Hub Chat for the shared live-client controls, Hub for hub ownership guidance, and Hub to return to the assigned hub. Report persistent failures with the run generation and activity ID, never with a password, protected token, raw private message, or secret command argument.

When this page loads for an already connected client, Hub Connection and Connection Status start collapsed. Both card headers remain visible; expanding or collapsing either panel does not disconnect or reconnect the client.

When a Hub Chat, Hub GPT, or Hub Mod worker restarts, the open product page keeps monitoring the saved session and reconnects its event stream automatically; a browser refresh is not required. If a release changes the browser/server protocol incompatibly, the page stops retrying and explicitly asks you to reload before reconnecting.

A restart notice appears as a System message inside the open Hub Chat transcript, so the chat layout remains stable. When the browser and worker versions are incompatible, that System message includes the same-page reload action.

Login Identity

Upload Speed

Optional upload capacity advertised in ADC and ADCS identity data. Enter an amount and unit; the protocol receives bytes per second.

Download Speed

Optional download capacity advertised in ADC and ADCS identity data. Enter an amount and unit; the protocol receives bytes per second.

Available Commands And Plugins

Hub Mod reads the confirmed software name stored on the hub record. A Verlihub hub receives the reviewed Verlihub Core catalog from the pinned local source. It does not send !help, +help, or another discovery request to main chat, #_PH_SECURITY, or another bot. $UserCommand frames advertised by the connected hub add reviewed plugin commands such as Ledokol or Lua.

Discover Commands Again creates a new bounded catalog from the confirmed provider and $UserCommand frames already advertised by the hub. Remove Commands only removes the active catalog. A generation becomes active only when it has a current catalog revision, an executable reviewed command, and reviewed-provider or hub-advertised command evidence. An interrupted, empty, stale, or invalid run leaves the previous active catalog intact.

The table separates Reviewed Core Commands from Hub-Advertised Commands. Command opens typed parameter fields and shows exact syntax, minimum class, risk, Official Wiki, Reviewed Source Evidence, and the command channel. The server builds and validates the payload. Class 3 can use reviewed commands with minimum class 3 or lower; higher-class commands stay Not Available with their reason.

If Verlihub core commands are missing, check the hub Software field, reconnect, then choose Discover Commands Again. If a plugin command is missing, confirm that the hub advertised its $UserCommand record. A security notice or bot nickname is not command-provider evidence. Do not paste an unreviewed raw command into main chat.

Search by command, alias, description, usage, source, or plugin.

Available commands changed after this page was opened. Reload the catalog before opening or sending a command.

Verified ADC And ADCS Attachment Downloads

A valid TTH magnet remains an ordinary link that can be opened or copied. When the stored message identifies an online ADC or ADCS source, a separate download icon appears immediately before that link. Nothing is fetched while the message renders.

Activating the icon asks the existing signed-in Hub Chat session to request that exact stored attachment from its current sender. The browser sends only the session, message channel, stored message ID, and attachment position; it never supplies a host, filename, size, or magnet URI for the server to trust.

The receiver negotiates a Direct Connect peer transfer for the advertised TTH, writes it to a private temporary file, and compares both the exact byte count and Tiger Tree Hash before returning download headers. A mismatch is discarded without exposing a partial file to the browser.

Downloads are user initiated, rate limited, limited per session and across the application, and capped at 64 MiB by default. The source guest must still be online and reachable. Verified and failed temporary files are removed after completion or expiry.

For active reception, the transfer worker binds the selected TCP or TLS port before advertising it to the source. Open the configured active port range in the host firewall and upstream NAT; ADCS also needs the configured certificate and private key. If binding or acceptance times out, the same job automatically tries passive reverse negotiation. If it still fails, confirm that the same guest is online and reachable. A missing icon means the link is not a complete supported TTH magnet or its stored source cannot be identified; the original magnet remains available for a desktop Direct Connect client.

When the receiver is busy, the same transfer remains in the list and is retried automatically after five minutes. It does not create a second record. You can dismiss the in-page notice or remove the transfer when it is no longer needed.

If a peer does not open its transfer endpoint in time, the application retries that verified download once. If it still fails, Transfers shows the reason and lets the requester retry manually after checking that the peer is still sharing the file.

Hub Chat

Read-Only Transfer Cache

Generated hublist files shared only after hub-mediated peer authorization.

The transfer cache is disabled by default for Hub Chat, Hub GPT, and Hub Mod. Each product has an independent global switch, host, ports, connection cap, and bandwidth cap; a hub owner cannot enable it from a per-hub page.

This feature fails closed. Enabling the switch does not advertise a share until the immutable manifest, listener, advertised host, port, and any TLS files are healthy.

Settings And Defaults

Enable Transfer Cache

Allow this product to advertise its read-only generated-file cache after every health check passes. Disabled is the default.

Advertised Public Host

Public hostname or unicast IP sent to authorized Direct Connect peers. Private, loopback, local, and reserved addresses are rejected.

Plain Transfer Port

Optional NMDC or ADC peer port from 1024 to 65535. It must be unique across enabled Hub products.

TLS Transfer Port

Optional NMDCS or ADCS peer port from 1024 to 65535. TLS certificate and key paths remain environment-owned.

Maximum Concurrent Transfers

Maximum active peer connections for this product, from 1 to 32.

Bandwidth Limit In Bytes Per Second

Per-product transfer limit from 65,536 to 104,857,600 bytes per second.

Global Transfer Monitoring

The Hub Transfers administration page totals completed verified uploads and downloads for a selected date range. It starts with the current month, shows daily totals, and never exposes peer names, addresses, filenames, or raw transfer secrets.

Use the first and last dynamic port to reserve a bounded private range. An active transfer receives only a currently free port in that range. The inventory separates assigned, stale, operating-system occupied, and available ports, and calculates allocation from the configured range rather than a guessed capacity.

Transfer Status stops new work before a peer connection is opened. Allowed Roles limits workspace access; existing Hub Chat, Hub GPT, and Hub Mod product rules still apply, so global permission never grants product access by itself.

Check Transfer Health queues a bounded async_transfer check of the saved range and local listener reports. A healthy result confirms application-side facts it can observe; it cannot prove that a router, NAT, or external firewall permits inbound Internet traffic.

Keep the async_transfer worker supervised with the documented deployment command. If status is stale or no snapshot appears, confirm that worker first, then review the local listener report and port allocation before changing firewall or public endpoint settings.

Health And Advertisement

An enabled product advertises transfers only while the shared gateway has bound every configured listener and reports a current healthy state. A missing host, occupied port, unavailable TLS file, failed listener, or stale worker keeps the advertised endpoint and share disabled.

Save the transfer settings, then use Check Public Ports. It requires one running shared gateway, a fresh listener report that exactly matches the saved host and ports, stable public DNS with no private or reserved address, and a successful TCP connection to every resolved address and configured plain or TLS port. The probe sends no protocol payload. Because it originates on the application server, also verify the endpoint from an authorized external Direct Connect client when NAT or firewall hairpin behavior differs.

The gateway reads one immutable manifest generation built from approved public hublist artifacts. A generation records each published name, byte size, and TTH. A missing file, changed hash, symlink, malformed file list, or incomplete atomic publication makes the manifest unhealthy.

When both the product listener and manifest are healthy, the client profile advertises the manifest byte total, active transfer port, slots, and supported NMDC or ADC transfer capabilities. When either dependency is unhealthy, it advertises no cache share or transfer endpoint.

Discovery And Authorization

A bounded NMDC or ADC search is matched only against the current manifest. Results identify an exact published file and TTH; broad, malformed, oversized, or unrelated searches do not enumerate the server filesystem.

The hub coordinates discovery and CTM/RCM negotiation but does not proxy file bytes. The product observes the peer nickname, direction, and public endpoint through its authenticated hub session, registers a short-lived authorization, then the peer opens the separate transfer connection.

Every inbound or outbound transfer requires a recent, one-time authorization tied to the product, hub session, peer nickname, public address, direction, and expiry. Direct scanners, expired records, replay, wrong products, wrong peers, wrong addresses, and private or reserved outbound destinations are rejected.

Files And Read-Only Limits

The share contains only generated hublist downloads copied into the dedicated cache plus its generated Direct Connect file list. It never exposes arbitrary application files, source paths, uploads, remote URLs, or files outside the approved generation.

Each immutable manifest also contains HUBLIST.PWIAM.COM.md, a project-owned read-only information file. It identifies PWiAM as the host of Public DC Hublist, summarizes hub search and generated hublist files, and introduces the Hub Chat, Hub GPT, and Hub Mod products. Peers can read it with the other approved manifest entries; the application generates it and a peer cannot upload, replace, or modify it.

The gateway is download-only. It accepts only file-list and ranged download requests for exact manifest entries, rejects traversal and invalid ranges, and does not implement uploads, deletion, rename, directory creation, or arbitrary path access.

Maximum Concurrent Transfers limits active peers per product. Bandwidth Limit In Bytes Per Second applies a shared per-product rate cap. Frame size, handshake time, idle time, requested range, and authorization lifetime are also bounded so slow or oversized peers cannot hold unlimited resources.

TLS And Peer Security

The plain and TLS listeners are separate. A TLS port is advertised only when its environment-owned certificate and private-key paths are usable. Encryption does not replace hub-mediated authorization; current Direct Connect CTM messages do not carry a verifiable certificate hostname or keyprint, so peer TLS encrypts transport without asserting a public Web PKI identity.

Troubleshooting

If the share is absent, keep the product disabled and check the current manifest, advertised public host, unique public port, listener health, TLS paths, worker state, and firewall forwarding in that order. Rebuild and verify the manifest, restart the shared gateway, then test one authorized file-list request and one artifact request. Never weaken endpoint validation or accept a direct unauthenticated socket to make a test pass.

Icon Reference