Merge pull request #200 from theta42/release-v2.5.0

release(v2.5.0): no-inbound relay automation, mesh-preferred replication
This commit is contained in:
2026-08-10 18:28:27 -07:00
committed by GitHub
2 changed files with 8 additions and 1 deletions
+7
View File
@@ -1,3 +1,10 @@
# v2.5.0 - 2026-08-10
### Added
- **No-inbound relay automation.** A spoke with no public IP of its own can now register as such (`noInbound`/`meshIp`/`publicHost` on `POST /api/site/spokes`, forwarded through `POST /api/site/join` for the real operator join flow), and the master auto-creates/updates the relay route on its own `theta-proxy` via `utils/proxy_client.js` — a new self-service `prx_...` API token client, reusing `theta-proxy`'s existing token system rather than inventing a new credential type. Verified against a real running `theta-proxy` container (`GET /api/host/:item`'s actual `{item, results: {...}}` response shape, not the flat shape first assumed).
- **Replication traffic prefers the mesh.** `utils/site_replicate.js`'s fire-and-forget resync push now tries a registered spoke's `meshIp` first (falling back to its public `endpoint` on failure) — cross-component routing over the gateway-to-gateway WireGuard mesh instead of the open internet, for any spoke that's registered one.
- `POST /api/site/join` surfaces the resulting relay status in its response (`relay.note`), and `theta-suite`'s bootstrap flow (`CFG_SPOKE_NO_INBOUND`/`CFG_SPOKE_PUBLIC_HOST`, `bootstrap/site-relay-register.js`) drives all of this from the real operator-facing setup script, not just the API.
# v2.4.0 - 2026-08-10
### Added
+1 -1
View File
@@ -1,6 +1,6 @@
{
"name": "t42-theta-directory",
"version": "2.4.0",
"version": "2.5.0",
"description": "A very simple LDAP management and SSO system",
"author": [
{