Establish a real Timmy ↔ Vincent machine-to-machine collaboration path using the native hermes peer transport, with this Forge issue as the durable authorization and evidence record.
Correct transport contract
Hermes peer does not use generated public peer identity keys. Each receiving Hermes gateway exposes its authenticated api_server; the caller registers its private URL and API_SERVER_KEY. The network path should be private (Tailscale/WireGuard/LAN) or protected by TLS. The bearer key is a secret and must never be posted in this issue or any group chat.
Responsibility split
Native Hermes peer: short direct questions and asynchronous bounded task/result exchange.
Stackchain Forge: scope, ownership, commits, PRs, tests, evidence, and human gates.
Telegram: operator direction and final decisions only; no ambient bot-to-bot loop.
Pilot scope
Timmy endpoint: tailnet-only API server, strong bearer key, no public listener.
Vincent endpoint: equivalent private authenticated API server.
Each side registers the other with hermes peer add.
Use hermes peer run ... --idempotency-key stackchain-lab-loop-peer-pilot-<issue> for the first long exchange.
Maximum three substantive reciprocal turns; no acknowledgements or automatic hand-back loops.
No merge, deploy, publication, destructive action, financial action, or credential rotation authority.
Acceptance criteria
Both endpoints answer /health over the approved private network.
Unauthenticated /v1/models is rejected; authenticated access succeeds.
hermes peer list on each host shows the other peer with a stored key.
Timmy sends one fresh bounded request; Vincent receives exactly one agent turn and returns one result.
Vincent sends one fresh bounded request; Timmy receives exactly one agent turn and returns one result.
A repeated idempotency key does not create duplicate work.
Durable output is linked here as a commit, PR, artifact, or reproducible test receipt.
No API key, token, raw prompt, hidden reasoning, environment dump, or private transcript appears in Forge or Telegram.
Telegram dispatch counts show no bot-to-bot echo.
Required private exchange
Each operator privately sends the other:
tailnet/VPN API server URL;
that gateway's API_SERVER_KEY;
intended peer alias and profile target.
Publicly post only readiness, non-secret endpoint name, run IDs, artifact links, test results, and blockers.
## Goal
Establish a real Timmy ↔ Vincent machine-to-machine collaboration path using the native `hermes peer` transport, with this Forge issue as the durable authorization and evidence record.
## Correct transport contract
Hermes peer does **not** use generated public peer identity keys. Each receiving Hermes gateway exposes its authenticated `api_server`; the caller registers its private URL and `API_SERVER_KEY`. The network path should be private (Tailscale/WireGuard/LAN) or protected by TLS. The bearer key is a secret and must never be posted in this issue or any group chat.
## Responsibility split
- Native Hermes peer: short direct questions and asynchronous bounded task/result exchange.
- Stackchain Forge: scope, ownership, commits, PRs, tests, evidence, and human gates.
- Telegram: operator direction and final decisions only; no ambient bot-to-bot loop.
## Pilot scope
- Timmy endpoint: tailnet-only API server, strong bearer key, no public listener.
- Vincent endpoint: equivalent private authenticated API server.
- Each side registers the other with `hermes peer add`.
- Use `hermes peer run ... --idempotency-key stackchain-lab-loop-peer-pilot-<issue>` for the first long exchange.
- Maximum three substantive reciprocal turns; no acknowledgements or automatic hand-back loops.
- No merge, deploy, publication, destructive action, financial action, or credential rotation authority.
## Acceptance criteria
1. Both endpoints answer `/health` over the approved private network.
2. Unauthenticated `/v1/models` is rejected; authenticated access succeeds.
3. `hermes peer list` on each host shows the other peer with a stored key.
4. Timmy sends one fresh bounded request; Vincent receives exactly one agent turn and returns one result.
5. Vincent sends one fresh bounded request; Timmy receives exactly one agent turn and returns one result.
6. A repeated idempotency key does not create duplicate work.
7. Durable output is linked here as a commit, PR, artifact, or reproducible test receipt.
8. No API key, token, raw prompt, hidden reasoning, environment dump, or private transcript appears in Forge or Telegram.
9. Telegram dispatch counts show no bot-to-bot echo.
## Required private exchange
Each operator privately sends the other:
- tailnet/VPN API server URL;
- that gateway's `API_SERVER_KEY`;
- intended peer alias and profile target.
Publicly post only readiness, non-secret endpoint name, run IDs, artifact links, test results, and blockers.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Goal
Establish a real Timmy ↔ Vincent machine-to-machine collaboration path using the native
hermes peertransport, with this Forge issue as the durable authorization and evidence record.Correct transport contract
Hermes peer does not use generated public peer identity keys. Each receiving Hermes gateway exposes its authenticated
api_server; the caller registers its private URL andAPI_SERVER_KEY. The network path should be private (Tailscale/WireGuard/LAN) or protected by TLS. The bearer key is a secret and must never be posted in this issue or any group chat.Responsibility split
Pilot scope
hermes peer add.hermes peer run ... --idempotency-key stackchain-lab-loop-peer-pilot-<issue>for the first long exchange.Acceptance criteria
/healthover the approved private network./v1/modelsis rejected; authenticated access succeeds.hermes peer liston each host shows the other peer with a stored key.Required private exchange
Each operator privately sends the other:
API_SERVER_KEY;Publicly post only readiness, non-secret endpoint name, run IDs, artifact links, test results, and blockers.