Skip to content

[Feature]: Discord UX parity prototype without plugins or multi-account #2040

@alanwilhelm

Description

@alanwilhelm

Summary

This issue proposes a Discord-native UX direction for Hermes inspired by the richer interaction model seen in tools like OpenClaw, but scoped to Hermes' actual goals.

This is not a request for immediate merge of one giant branch. It is a request for feedback on product direction and implementation slicing.

Goal

Bring Hermes' Discord experience closer to a first-class chat UX with:

  • richer native slash command behavior
  • rich /status, /help, /commands, and /whoami
  • interactive /model, /models, and /model status
  • reusable Discord component runtime for buttons, selects, and modals
  • better approval UX
  • runtime controls like /debug, /bash, /subagents, /kill, /steer, /tell, and /acp
  • thread/session/focus controls that feel native in Discord

Explicit Exclusions

This proposal intentionally does not include:

  • plugins
  • multiple Discord accounts
  • a multi-bot or multi-connection model
  • broad Discord server administration / moderation parity
  • full OpenClaw backend/plugin architecture

Why Open A Separate Issue

#1559 is broader and leans toward a much larger Discord Gateway v2 / server-management direction.

This issue is narrower and more product-facing:

  • single Hermes gateway runtime
  • single Discord bot/account
  • richer Discord-native UX for the commands and workflows Hermes already exposes
  • no plugin system requirement

It is also adjacent to #503, but specifically focused on Discord UX rather than generic cross-platform rich interactions.

Working Prototype

There is an active prototype branch for this direction:

  • alanwilhelm:feature/discord-architecture

Recent work on that branch includes:

  • Discord-native slash registration/runtime
  • internal discord_impl decomposition
  • component runtime
  • rich runtime/status/help views
  • model picker
  • native slash response fixes

Proposal To Maintainers

I do not expect this to merge as-is; I’m proposing the direction and a working prototype.

If the direction is useful, the likely merge path would be a set of smaller PRs carved out of the prototype branch.

Questions

  1. Is this Discord UX direction desirable for Hermes?
  2. If yes, which slices would be acceptable to upstream first?
  3. Which parts should be dropped or postponed even if the UX direction is accepted?

Metadata

Metadata

Assignees

No one assigned

    Labels

    P3Low — cosmetic, nice to havecomp/gatewayGateway runner, session dispatch, deliveryplatform/discordDiscord bot adaptertype/featureNew feature or request

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions