hermes - 💡(How to fix) Fix [Feature]: Expose user_id alongside user_name in single-user session context

Problem or Use Case

Problem or Use Case: I'm building a multi-user team profile that relies on identity-mapping rules in the system prompt (e.g., "user_id A is person 1, user_id B is person 2"). The goal is for the model to identify users by stable numeric user_id rather than mutable display name, since display names can change.

Looking at gateway/session.py in build_session_context_prompt(), the current logic uses an elif pattern where **User ID:** is only shown when no display name exists:

elif context.source.user_name:
    lines.append(f"**User:** {context.source.user_name}")
elif context.source.user_id:
    uid = context.source.user_id
    if redact_pii:
        uid = _hash_sender_id(uid)
    lines.append(f"**User ID:** {uid}")

For platforms like Telegram where users almost always have a display name set, this means the user_id is effectively never exposed to the model in single-user sessions. Identity rules in the system prompt that reference user_id are therefore unreachable in practice.

This is a real limitation when building team profiles where the system prompt needs to authoritatively map stable identifiers to people, independent of what display name a user happens to be showing at the moment.

Proposed Solution

When both user_name and user_id are available, include both in the session context. Example:

Current: User: Display Name

Proposed: User: Display Name (user_id: 12345)

This is a small change in build_session_context_prompt() that replaces the elif with an if/combined logic. The same pattern could apply to the shared multi-user sender prefix in gateway/run.py (currently [Display Name], would become something like [sender: Display Name, user_id: 12345]).

If PII is a concern, the existing redact_pii flag would still apply to the user_id portion, preserving the hashing behavior already in place.

Happy to submit a PR if this direction is acceptable.

Alternatives Considered

1. System prompt fallback to display name as identity: works for stable display names, but breaks when users change their Telegram display name. We worked around this with an alias-learning approach in the system prompt ("if display name matches a known alias, use that; otherwise ask which authorized user is messaging"), but this depends on the user_id being authoritative at the gateway/allowlist layer for security, while the model operates only on display names.

2. Local patch to expose user_id: technically works (small change to session.py and run.py) but creates a local fork of frequently-updated upstream Hermes, which makes upgrades painful.

3. Storing the user_id ↔ display_name mapping in memory and inferring identity from chat history: works for established users with conversation history, but fails for fresh users on first contact, since the model has no prior context to anchor on.

The proposed solution (expose both in the prompt) is the simplest and lets the system prompt make the actual identity decision with full information, while the gateway allowlist continues to be the security boundary.

Feature Type

Gateway / messaging improvement

Scope

Small (single file, < 50 lines)

Contribution

• I'd like to implement this myself and submit a PR

Debug Report (optional)