Nous Portal subscription integration

[rewbs]

• Integration with Nous Portal via subscription, using device auth flow, standard refresh/access token flow, and short-lived API key rotation
• Optional request dumping for debugging

The flow is:

• User runs hermes login
• Hermes calls Portal POST /api/oauth/device/code with client_id=hermes-cli and scope inference:mint_agent_key.
• Hermes opens the browser to verification_uri_complete and polls POST /api/oauth/token (device_code grant).
• After user approval on Portal, Hermes receives access_token + refresh_token (+ optional inference_base_url) and stores them in auth state.
• Hermes immediately resolves runtime credentials:
  • refreshes access token if near expiry,
  • mints or reuses a short-lived agent inference key via POST /api/oauth/agent-key with min_ttl_seconds.
• Hermes caches the minted key + expiry and reuses it across concurrent processes when still valid.
• During chat/inference, Hermes auto-refreshes token and rotates agent key when needed (or preemptively when below TTL threshold), then calls the Nous OpenAI-compatible inference API with that key.

Note there are three different credentials with different jobs:

• access_token: short-lived bearer token the CLI uses to call Portal OAuth-protected endpoints, such as the one to mind API keys.
• refresh_token: longer-lived token used only to get a new access token, so users don’t have to re-login constantly.
• short-lived/rotating inference api_key: minted by Portal for the inference API (since that backend only understands API keys, not user/session identity).

The access_token/refresh_token pairing is standard OAuth: keep the token used on normal requests short-lived, and use a separate long-lived credential for renewal. That limits blast radius if an access token leaks and allows safer rotation/revocation policies around refresh tokens.

[teknium1]

Ported in the fundamentals, changed the way it was executed (needed multi-provider structure) - thanks!

[tradewind425]

大枠は正しい方向。但し、いくつか実装グリップを詰める必要あり：

• gateway/run.py (10.3K行) は Discord 特異的な部分が ~36箇所で全体の ~1% 程度。WhatsApp等マルチプラットフォーム対応もあり、単純な移管ではなく Discord イベントハンドル + routing を抽出→Ouroboros、残りは hermes-agent に hooks として戻す設計が必要。現在 my-changes では tui_gateway/server.py が既にこのパターンを示唆している。

• hermes_cli/personas.py (SOUL.md sync 方式) と model_switch.py (can_persist flag 追加) の hook パターンは良い候補。但し hook 呼び出し側と agent 側の API コントラクト（例：JSON-RPC、subprocess IPC）を明確に定義すべき。Discord.js 化するなら必須。

• hermes_cli/models.py 破棄 ✓、tools/file_operations.py defer ✓ で合意。

• 本計画と分離として、agent↔Ouroboros の IPC/hook boundary spec を先行タスク化すると、以降の移管作業がスムーズになりそう。