mirror of
https://github.com/NousResearch/hermes-agent.git
synced 2026-06-17 09:41:58 +00:00
docs(memory-providers): cover gateway identity mapping for Honcho
The Honcho provider page documented the per-profile peer model (user peer / AI peer / observation) but never the gateway axis — how platform runtime IDs map to peers. Adds the three keys to the config table and a short Gateway identity mapping subsection that points at the Honcho page for the resolver ladder. Uses the corrected pinUserPeer wording (pins non-agent users, overrides aliases) so the provider-comparison reader gets the same accurate framing as the dedicated page.
This commit is contained in:
parent
c7513df4f9
commit
6dde7d4657
1 changed files with 15 additions and 0 deletions
|
|
@ -95,6 +95,9 @@ The legacy `hermes honcho setup` command still works (it now redirects to `herme
|
|||
| `messageMaxChars` | `25000` | Max chars per message (chunked if exceeded) |
|
||||
| `dialecticMaxInputChars` | `10000` | Max chars for dialectic query input to `peer.chat()` |
|
||||
| `sessionStrategy` | `'per-directory'` | `per-directory`, `per-repo`, `per-session`, `global` |
|
||||
| `pinUserPeer` | `false` | Gateway only. When `true`, every non-agent gateway user collapses to `peerName`; the pin overrides all aliases |
|
||||
| `userPeerAliases` | `{}` | Gateway only. Maps runtime IDs to peers (`{"7654321": "alice"}`). Many-to-one |
|
||||
| `runtimePeerPrefix` | `""` | Gateway only. Namespaces unknown runtime IDs (`telegram_7654321`) when no alias matches |
|
||||
|
||||
</details>
|
||||
|
||||
|
|
@ -199,6 +202,18 @@ Server-side toggles set via the [Honcho dashboard](https://app.honcho.dev) win o
|
|||
|
||||
See the [Honcho page](./honcho.md#observation-directional-vs-unified) for the full observation reference.
|
||||
|
||||
### Gateway identity mapping
|
||||
|
||||
The peer model above covers CLI, TUI, and desktop sessions, where every conversation resolves to `peerName`. The [gateway](../../developer-guide/gateway-internals.md) adds a second axis: users arrive with platform-native runtime IDs (Telegram UID, Discord snowflake, Slack user), and three keys decide which peer each ID resolves to.
|
||||
|
||||
| Key | Effect |
|
||||
|-----|--------|
|
||||
| `pinUserPeer: true` | Every non-agent gateway user collapses to `peerName`. The pin is checked first, so it overrides all aliases — pick it only when no user-side identity needs its own peer |
|
||||
| `userPeerAliases` | Maps specific runtime IDs to peers (`{"7654321": "alice"}`). The home for routing distinct identities — including agents that each carry their own peer |
|
||||
| `runtimePeerPrefix` | Namespaces any unmapped runtime ID (`telegram_7654321`) so platforms with same-shaped IDs don't collide |
|
||||
|
||||
Off-gateway these keys do nothing. `hermes memory setup` only prompts for them when it detects a connected gateway platform. See the [Honcho page](./honcho.md#gateway-identity-mapping) for the resolver ladder and the setup flow.
|
||||
|
||||
<details>
|
||||
<summary>Full honcho.json example (multi-profile)</summary>
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue