hermes - 💡(How to fix) Fix Honcho memory provider: support runtime peer alias/prefix mapping for multi-user gateways

Feature description

For multi-user gateway platforms, it is useful for the Honcho memory provider to map platform runtime user IDs to stable Honcho peer IDs. Known users may need aliases to preserve an existing peer, while unknown users should be scoped into predictable peer IDs with a platform prefix.

Motivation

A single gateway profile may serve multiple platform users. Pinning all traffic to one static peerName mixes users. But simply using raw platform IDs can break continuity for a known owner/user who already has a stable Honcho peer.

Proposed solution

Add optional config fields such as:

{
  "hosts": {
    "hermes.example": {
      "pinPeerName": false,
      "userPeerAliases": {
        "<platform-user-id>": "stable-peer-id"
      },
      "runtimePeerPrefix": "dingtalk_"
    }
  }
}

Resolution behavior:

1. If the runtime platform user ID matches userPeerAliases, use the mapped peer ID.
2. Otherwise use runtimePeerPrefix + runtime_user_id, sanitized as a Honcho peer ID.
3. Fall back to existing peerName behavior when no runtime user is available.

Local workaround tested

A local patch added user_peer_aliases and runtime_peer_prefix to the Honcho config and used them in session peer resolution. Tests were added for host-block config parsing, known-user alias mapping, and unknown-user prefix mapping.

Environment

• Hermes checkout commit: 9f182bd7b
• OS: Ubuntu 24.04 / Linux
• Plugin: Honcho memory provider