Hub sharing

A hub normally belongs to one server. Sharing lets it serve more than one: the same machine — and the same folders on it — can feed the libraries of several servers, with the files walked, read and given previews once rather than once per server.

The hub keeps a home server: the one it was registered under. The home server keeps everything machine-level — the hub's token, updates, settings, and tunnel details. What a share grants the other server is strictly less: streaming from the hub, pointing its own libraries at folders on it, pairing its own grabbers so its requests can be delivered there, and reading the machine's logs.

Three methods carry the surface, on HubService under xmb.api.v1, all requiring the xmb:admin scope:

Sharing

ShareHub is called against the hub's home server, and the caller must be an administrator of both servers:

{
  "serverSlug": "lounge",
  "uuid": "eb32c10b-8882-40b5-9479-12145a726547",
  "targetServerSlug": "cabin"
}

That double-admin rule is the whole authorization model. Sharing grants the target nothing its admin could not have set up by registering a hub there directly, so there is no invitation or acceptance flow: if you administer both sides, the grant is yours to make.

Once shared, the hub appears in the home server's Hub views with the target's slug in sharedWithServerSlugs. Both servers may register the same folder on the hub — overlapping library paths across servers are the point, and the platform coalesces them so the folder is still only scanned once.

What the sharing server sees

ListSharedHubs returns SharedHub rows — deliberately less than Hub:

{
  "hubs": [
    {
      "uuid": "eb32c10b-8882-40b5-9479-12145a726547",
      "name": "Living room",
      "status": "HUB_STATUS_ACTIVE",
      "homeServerName": "Lounge",
      "canIngest": true,
      "canTranscode": true,
      "acceptedGrabberUuids": ["…"]
    }
  ]
}

The reduced shape is the contract, not a UI convention: a sharing server never sees the hub's token, resources, tunnel facts or the other tenants' grabber pairings. acceptedGrabberUuids lists only your server's pairings on it.

The machine's logs are the one diagnostic surface a share does carry, and they are scoped: NodeLogService accepts a shared hub's uuid from any server it serves, and a tenant reads its own lines plus the machine-level remainder. Attribution rides with the work — the platform's calls, media tokens and delivery grants all carry the requesting server, the hub echoes it into each line, and lines nothing claimed (boot, tunnel, updates, the watcher) are visible to every tenant. The home server always reads the whole log. Lines shipped by hubs from before attribution existed count as machine-level, so an out-of-date fleet degrades to showing more, never nothing.

A shared hub works with the existing library and pairing surfaces exactly as your own hubs do: BrowseHub and AddLibraryPath accept its uuid, and SetHubGrabbers — called with your own serverSlug — replaces your server's set of accepted grabbers on it without touching anyone else's.

Content appears quickly after a share: the hub's files were already indexed for its home server, so pointing a library at a folder needs only a match pass, not a re-read of the disks.

Unsharing

Either side may end a share. The home server names the tenant:

{ "serverSlug": "lounge", "uuid": "…", "targetServerSlug": "cabin" }

A tenant detaches itself by naming only its own server — targetServerSlug may be omitted:

{ "serverSlug": "cabin", "uuid": "…" }

Unsharing is real removal, not a flag: the leaving server's library paths on the hub, its files' filings and their episode links, and its grabber pairings all go with the grant. From that server's point of view it is exactly losing a hub. The hub's own files, previews and the other tenants' libraries are untouched.

Alerts

A shared hub going offline, or running out of disk, raises the alert on every server it serves — an outage on the machine is an outage for each tenant's shelf, and each hears about it on its own board.