feat(simplex): groups, native attachments, text batching, auto-accept

[jooray]

Summary

Extends the SimpleX Chat platform plugin merged in #27???/09d9724a0 with the features our deployment was carrying out-of-tree against the older core-modifying SimpleX integration (#2558/#4870). All additions live inside plugins/platforms/simplex/ — no edits to any core file — and the existing tests/gateway/test_simplex_plugin.py suite (27 tests) passes unchanged except for two that asserted send-format details we believe are wrong (see Test changes below).

This PR is a new PR, not a refresh of #4870. #4870 was the original core-modifying version. After the plugin landed upstream we rebuilt the work on top of the plugin contract, which is the architecture this codebase is clearly moving towards. #4870 should be closed in favour of this one.

Where the current plugin falls short

The current plugins/platforms/simplex/ adapter is a faithful first port from the original PR description, but in a real deployment it has a few gaps:

Area	Current plugin	This PR
Group chats	Inbound items are parsed as DMs only; no allowlist gate, no chat_type="group" on the event.	SIMPLEX_GROUP_ALLOWED env var (comma-separated IDs or *); inbound items surface with chat_id="group:<id>" + chat_type="group". Omitted by default — a bot in a group otherwise processes every member's traffic.
Inbound files / voice notes	_fetch_file does /freceive then sleep(2) and scans ~/Downloads, ~/.simplex/files, /tmp/simplex_files for the filename. Race-prone on large files; voice notes that need >2s for XFTP transfer get dropped.	Hooks rcvFileDescrReady to send /freceive immediately on file announcement; defers the chat item via _pending_file_transfers and replays it once rcvFileComplete fires. Distinguishes voice notes (→ MessageType.VOICE), photos, and documents.
Outbound media	send_image is a stub: posts f"{caption}\n{image_url}" as plain text. No send_voice, send_video, send_document.	Real send_image_file / send_image (PNG/JPEG with Pillow or ImageMagick conversion + inline thumbnail), send_voice (native msgContent.type="voice" so the receiving client renders the inline voice-note player rather than a generic file download), send_video, send_document. All addressed by numeric ID via the structured /_send … json [...] form so groups with non-unique display names don't get the wrong target.
MEDIA:<path> tags in agent replies	Not supported — the tag would arrive as literal text.	Stripped from the text body and dispatched as voice (audio extensions) or document, matching the convention other Hermes adapters use.
Text-burst batching	None. A user pasting a multi-line prompt produces N separate MessageEvents, and only the first reaches the agent before the rest get queued/dropped.	HERMES_SIMPLEX_TEXT_BATCH_DELAY (default 0.8s). Rapid-fire inbound texts within the quiet window are concatenated into one MessageEvent — same pattern as Telegram's text batching.
Auto-accept contact requests	Not handled — contactRequest events are silently ignored, so every new contact has to be approved manually.	SIMPLEX_AUTO_ACCEPT (default true). Disable explicitly to gate every new contact behind an allowlist.
Send path: groups	cmd_str = f"#[{group_id}] {content}". This silently doesn't deliver in production unless the group's display name is literally the numeric ID — the daemon parses #[...] as display-name lookup. Confirmed by sending messages to group:1 (display name Victoria-H) and watching them never arrive in the chat while the gateway reported "Sending response (... chars) to group:1".	cmd_str = f"/_send #{group_id} json [...]". Structured form; addresses by numeric ID; json.dumps escapes newlines and quotes correctly.
Send path: DMs	cmd_str = f"@[{chat_id}] {content}" — also bracket form.	cmd_str = f"@{chat_id} {content}" — bare form, matches what's worked in production for months.

Test changes

test_send_dm and test_send_group previously asserted the bracket form. Both expectations were updated to match the formats above; this is in the same commit so the suite still passes 27/27.

If you'd rather keep the bracket-form expectations, the daemon-side parser is the place to fix it — a #[ID] text payload addressed by numeric ID would Just Work and would be consistent with the rest of the plugin's /_send calls. Happy to follow that thread separately.

What's not in this PR

• The original out-of-tree adapter had a deeper integration with tools/send_message_tool for out-of-process (cron) sends including media. The plugin's standalone_sender_fn contract is text-only, and that's preserved here. If we want media for hermes cron running as a separate process from hermes gateway, that's a follow-up that probably belongs in the plugin contract.
• New env vars are surfaced in plugin.yaml (version bumped to 1.1.0) and documented in website/docs/user-guide/messaging/simplex.md.

Test plan

• pytest tests/gateway/test_simplex_plugin.py — 27 passed
• Production: running on victoria continuously against simplex-chat 6.4 since March 2026 in its core-modifying form, and since 2026-05-18 in this plugin form. Tests cover:
  • DM inbound + outbound (text, images, voice notes, documents)
  • Group inbound + outbound (text, voice digest delivery via deliver=simplex)
  • XFTP inbound voice messages, deferred replay via rcvFileComplete
  • Outbound voice notes from TTS pipeline via MEDIA:<path> tags
  • Text-burst batching from multi-line paste
  • Auto-accept of incoming contact requests

The bracket-form regression I mentioned above was caught the same day we deployed this PR's branch and is the reason the send paths look the way they do here.

[lambertian]

+1 on the WS-native direction. One empirical data point on the recurring "does the -p daemon actually push inbound events, or do we have to poll?" question — since the parallel polling PRs (#26433, the #30150 thread) assume it doesn't, and that's a genuinely easy assumption to land on.

Tested against simplex-chat v6.5.1.1: it does push. With a single passive WebSocket client connected (nothing else talking to the daemon) and no /_start or any command sent, an inbound DM arrived on its own as an async {"resp":{"type":"newChatItems",...}} frame within a couple of seconds. Sending /_start afterward just returned chatRunning — a no-op, since the controller already runs under -p — and the next message pushed the same way. So native push works and /_start isn't the trigger, at least on v6.5.1.1.

The reason it so easily looks like the daemon doesn't push: items are nested under resp, so a handler reading chatItems at the top level gets nothing and silently drops every pushed event — a perfectly-pushing daemon looks silent, and polling becomes the natural workaround. (Easy one to miss.) Consuming the events the way this PR does, instead of bolting on a DB//tail poller, looks like the right direction.

One note for the end-to-end file path: this PR adds the adapter-side media methods, but the send_message_tool tool-layer still has to route media_files to them (its in-process branch currently calls adapter.send() text-only). That tool-layer routing looks already handled by #18686 / #23770 — so this PR plus one of those should close the loop for tool/cron file sends.

[lambertian]

A follow-up from a deeper read of the SimpleX adapter (alongside the inbound-document fix in #35490). Four issues land in regions this PR rewrites — documenting them here, and I've since opened standalone PRs for each against current main:

1. Inbound message_id is never set (fix(simplex): populate inbound message_id from chat item itemId #35556). The MessageEvent(...) build doesn't populate message_id from meta.itemId, so reply-anchoring, the [Replying to: …] disambiguation prefix, and transcript-id features silently no-op on SimpleX. The one-line set is message_id=str(meta.get("itemId")) if meta.get("itemId") is not None else None (the None-guard matters — otherwise you get the literal "None"). This covers transcript-id + reply anchoring; native threaded replies would also need send() to honor reply_to.

2. send() doesn't chunk long messages (fix(simplex): chunk long outbound messages in send() #35558). The adapter advertises a max message length, but the reply path passes full content straight to send(); every other text adapter self-chunks via truncate_message. A truncate_message(content, MAX_LEN) loop in send() keeps long replies (and code-fence-aware splitting) intact.

3. Non-retryable handshake failures retry forever (fix(simplex): escalate non-retryable WebSocket handshake rejections instead of looping forever #35557). A handshake 4xx (e.g. a permanently misconfigured daemon) falls into the generic reconnect arm and busy-loops with no gateway-visible fatal state. An except InvalidStatus arm (or InvalidStatusCode on older websockets) that calls _set_fatal_error(..., retryable=False) before breaking matches the IRC adapter's pattern.

4. Null-unsafe groupProfile / member-profile .get(..., {}) (fix(simplex): avoid AttributeError when an inbound group profile is null #35521). The group-name and sender-profile lookups do .get("groupProfile", {}).get(...), which raises on a daemon-emitted "groupProfile": null (the {} default only applies to a missing key, not a present-null one). The same (... or {}) guard is needed wherever this code lands.

This PR rewrites these same regions but doesn't address any of the four, so they're complementary, not duplicates — cross-linking so the overlap is visible and whoever merges second has the context.