hermes - 💡(How to fix) Fix Feature request: opt-in X-Hermes-User-Id header to scope per-user long-term memory over the HTTP API [1 pull requests]

Is your feature request related to a problem?

Yes. The HTTP API server (gateway/platforms/api_server.py) accepts an X-Hermes-Session-Key header that scopes long-term memory to a single chat/transcript, but it never forwards an end-user identity to the agent — even though the rest of the stack already consumes one:

• run_agent.py — AIAgent.__init__ already accepts user_id: str = None and forwards it to init_agent.
• agent/agent_init.py — stores it (agent._user_id = user_id) and passes it to the memory layer.
• plugins/memory/honcho/__init__.py — the bundled Honcho provider uses it as the per-user peer name (runtime_user_peer_name=kwargs.get("user_id")).
• gateway/platforms/api_server.py — _create_agent() builds AIAgent(... gateway_session_key=...) without ever setting user_id.

Because the API server is the only entry point that omits user_id, every request over HTTP collapses onto the same default memory peer. The per-user isolation Honcho provides by construction (one peer = one user_id) is unreachable over the HTTP API — not because of Honcho, but because the identity is never supplied. A session key only separates transcripts of the same user; it cannot represent a user across their sessions.

Describe the solution you'd like

An opt-in X-Hermes-User-Id request header on the API server, behaving exactly like the existing X-Hermes-Session-Key (same API-key-auth requirement, same validation), whose value is threaded to AIAgent(user_id=...). This would let an authenticated front-end scope long-term memory per end-user (a Honcho peer) over the HTTP API, in a single Hermes instance serving multiple users.

Describe alternatives you've considered

• Running one Hermes instance per user — defeats the point of the HTTP API and is heavy.
• Using X-Hermes-Session-Key as a stand-in for user identity — incorrect: it scopes a chat, not a person, so it can't give a stable per-user representation across sessions.

Additional context

• Backward compatible by design: when the header is absent, user_id stays None and behavior is unchanged (current default peer).
• Security: it should mirror X-Hermes-Session-Key — honored only when an API key is configured (else 403), control characters rejected, length bounded — so an unauthenticated client on a local-only server can't inject itself into another user's memory scope.
• A working reference implementation (~95 lines, one file) exists and can be shared as a PR if the maintainers are open to the approach. Posting this as a feature request first to confirm the direction.