hermes - 💡(How to fix) Fix [Feature]: Unify text + TTS audio in a single Signal message

Problem or Use Case

Bonjour 👋🏻

I'd like to propose a new feature for Hermes Agent: sending unified messages on Signal that combine both text and TTS audio in a single message (instead of two separate messages).

• Hermes Agent currently sends text and TTS audio as two distinct messages on Signal
• OpenClaw already supports this unified approach using signal-cli with the --attachment flag for audio
• Example of current command:
  • signal-cli -a +33XXXXXXXXX send -m "..." --attachment output.ogg +33YYYYYYYYY
• This creates two separate messages: one text message and one voice message

Proposed Solution

• Add an option in Hermes Agent to send unified messages (text + TTS audio) in a single Signal message
• Implementation could include:
  • A new configuration option (e.g., voice.auto_tts=true for unified mode)
  • Modification of the send_message command to include audio as an attachment in the same message as text

Alternatives Considered

Proposed by agent itself

Current issue: The skill is deployed via a fork in /root/hermes-fork/ and uses PYTHONPATH=/root/hermes-fork to survive updates. However, there's an active bug preventing proper functionality:

1. SignalAdapter has SUPPORTS_MESSAGE_EDITING = False (file signal.py:181), which causes the stream consumer creation in run.py to silently throw an exception and fall back to the non-streaming path
2. In the non-streaming path (base.py _process_message), the voice_mode variable is never checked, so the text is always sent via adapter.send() even when voice_mode="all" is configured Fixes already applied in the fork:

• Added a voice_mode field to StreamConsumerConfig
• Added an early-return guard in GatewayStreamConsumer._send_or_edit that immediately returns if voice_mode == "all"
• Passed voice_mode to both StreamConsumerConfig creation locations in run.py
• Added caption=text in _send_voice_reply so the text travels with the audio But the bug persists because: The stream consumer is never reached due to SUPPORTS_MESSAGE_EDITING = False. The solution requires either:
• Modifying SUPPORTS_MESSAGE_EDITING = True in SignalAdapter (but this might break other functionality)
• OR adding a voice_mode check in base.py around line 3038 to skip adapter.send() when voice_mode == "all" Current behavior: There's still an active bug that sends text messages twice in addition to the unified message - one via the normal text path and one as part of the unified message with audio attachment.

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)