Skip to content

feat(gateway/signal): add support for multiple image sending in single messages#17888

Closed
MaxyMoos wants to merge 1 commit into
NousResearch:mainfrom
MaxyMoos:gateway/add-multiple-image-sending
Closed

feat(gateway/signal): add support for multiple image sending in single messages#17888
MaxyMoos wants to merge 1 commit into
NousResearch:mainfrom
MaxyMoos:gateway/add-multiple-image-sending

Conversation

@MaxyMoos

@MaxyMoos MaxyMoos commented Apr 30, 2026

Copy link
Copy Markdown
Contributor

What does this PR do?

Adds support for per-platform sending of multiple images in a single message, switching over from the current "1 image per message" loop approach - which is kept as the default fallback behavior.
The send_multiple_images method is added to BasePlatformAdapter.

The PR implements this new behavior for the Signal adapter, with a maximum of 32 images per batch (sourced from Signal-Desktop/Android client code) and tries on a best-effort basis to work around rate-limits for voluminous batches (e.g. > 50 images in one go) using a platform-specific scheduler.

Voluminous batches are ones that exhaust Signal's server-side attachment bucket. Default is 50 tokens (= 1 attachment), refilled at 1 token / 4s until the server tells us otherwise).

signal-cli v0.14.3 (released on 2026-04-22) added the surfacing of the server's Retry-after hitting rate-limit failures, which we take into account if available, or fallback on the 4s-per-token default rate - observed from real-world usage in signal-cli's output.

Also adds batch-sending + rate-limit handling in the send_message tool.
The Signal scheduler is a process-wide singleton so both the send_message tool and the main adapter codepaths share the same rate-limit budget.

New tests added for the Signal adapter, its rate-limit scheduler and the send_message tool.

Related Issue

No existing issue as far as i can tell.

Type of Change

  • 🐛 Bug fix (non-breaking change that fixes an issue)
  • ✨ New feature (non-breaking change that adds functionality)
  • 🔒 Security fix
  • 📝 Documentation update
  • ✅ Tests (adding or improving test coverage)
  • ♻️ Refactor (no behavior change)
  • 🎯 New skill (bundled or hub)

Changes Made

File Change
gateway/platforms/base.py Add send_multiple_images with default implementation to BasePlatformAdapter; route multiple image calls to it
gateway/platforms/signal_rate_limit.py New file: singleton scheduler that monitors attachment (images only, for now) uploads mirroring Signal's server-side rate-limit logic. Calibrates token refill rate based on server Retry-after hints upon hitting 429 errors
gateway/platforms/signal.py Implement custom send_multiple_images to support multi-image sending using the scheduler above
gateway/run.py Adapt attachment/media splitting for correct handling of new send_multiple_images method
tools/send_message_tool.py Rewrite _send_signal to chunk attachments + use the new scheduler
tests/gateway/test_signal.py 27 tests added
tests/gateway/test_signal_rate_limit.py 18 tests added
tests/tools/test_send_message_tool.py 8 tests added
website/docs/user-guide/messaging/signal.md Add mention of send_multiple_images alongside send_image_file. Also, add a warning block with info about rate-limits.

How to Test

  1. Ask the agent to send you multiple images in a Signal channel
  2. Receive the images bundled in a single message response (up to 32 per batch)
  3. If the batches have to be delayed for more than 10s (e.g. more than 50 images have to be sent in one go, exhausting the Signal server-enforced limit), the scheduler paces sends and users get notified by a message e.g. "(More images coming — pausing ~52s for Signal rate limit, batch 2/2.)"

Code

  • I've read the Contributing Guide
  • My commit messages follow Conventional Commits (fix(scope):, feat(scope):, etc.)
  • I searched for existing PRs to make sure this isn't a duplicate
  • My PR contains only changes related to this fix/feature (no unrelated commits)
  • I've run pytest tests/ -q and all tests pass - No but i've run gateway and send_message tool tests with no regressions
  • I've added tests for my changes (required for bug fixes, strongly encouraged for features)
  • I've tested on my platform: Arch Linux

Documentation & Housekeeping

  • I've updated relevant documentation (README, docs/, docstrings)

Screenshots / Logs

screen1 screen2

Known limitations

  • Per-image alt-text is dropped on Signal - not supported
  • Only multi-image sending triggers the scheduler-bound codepath, single-image events will make the scheduler state fall out-of-sync with server-side. This is partially covered because the scheduler recalibrates internal state (feedback method) upon receiving an HTTP 429.

@MaxyMoos
feat(gateway/signal): add support for multiple images sending
983cd23 
Adds a new `send_multiple_images` method to the ``BasePlatformAdapter``
that implements the default "One image per message" loop and allows for
platform-specific overriding.

Implements such an override for the Signal adapter, batching images
and trying (best-effort) to work around rate-limits for voluminous
batches using a specific scheduler.

Also implements batching + rate-limit handling in the `send_message`
tool.

New tests added for the Signal adapter, its rate-limit scheduler and the
`send_message` tool
@MaxyMoos MaxyMoos force-pushed the gateway/add-multiple-image-sending branch from c749206 to 983cd23 Compare April 30, 2026 10:11
@alt-glitch alt-glitch added type/feature New feature or request P2 Medium — degraded but workaround exists comp/gateway Gateway runner, session dispatch, delivery platform/signal Signal CLI adapter comp/tools Tool registry, model_tools, toolsets labels Apr 30, 2026
@teknium1 teknium1 mentioned this pull request Apr 30, 2026
Merged
teknium1 added a commit that referenced this pull request Apr 30, 2026
@teknium1 @MaxyMoos
feat(gateway): native send_multiple_images for Telegram, Discord, Sla…
3de8e21 
…ck, Mattermost, Email

Ports PR #17888's send_multiple_images ABC to every gateway platform that
has a native multi-attachment API, so images arrive as a single bundled
message instead of N separate ones.

Native overrides:
- Telegram: send_media_group (10 photos per album, chunks over); animated
  GIFs peeled off and routed through send_animation (albums don't support
  animations)
- Discord: channel.send(files=[...]) (10 attachments per message, chunks
  over); URL images downloaded into BytesIO so they render inline; forum
  channels use create_thread with files=[...]
- Slack: files_upload_v2(file_uploads=[...]) (10 per call, chunks over);
  respects thread_ts; records thread participation
- Mattermost: single post with file_ids list (5 per post — Mattermost cap,
  chunks over)
- Email: single SMTP message with multiple MIME attachments (no chunk cap,
  SMTP size governs); remote URLs remain linked in body (parity with
  existing send_image)

All platforms fall back to the base per-image loop on any failure, so a
single bad image in a batch never loses the rest.

Matrix, WhatsApp, and single-attachment platforms (BlueBubbles, Feishu,
WeCom, WeChat, DingTalk) continue to use the base default loop — their
server APIs only accept one attachment per message anyway.

Tests: adds tests/gateway/test_send_multiple_images.py with 19 targeted
tests covering base default loop, chunking, animation peel-off, fallback
paths, and empty-batch no-ops across all five new overrides.

Co-authored-by: Maxence Groine <maxence@groine.fr>
@teknium1

teknium1 commented Apr 30, 2026

Copy link
Copy Markdown
Contributor

Merged via #17909 — your Signal commit was cherry-picked and authorship is preserved in git log (commit 04ea895). Salvage PR extended the send_multiple_images ABC you designed to every other platform with a native multi-attachment API (Telegram send_media_group, Discord files=[...], Slack files_upload_v2, Mattermost file_ids, Email MIME multi-attach), so the improvement you built for Signal now applies everywhere it can. Nice design on the ABC — it slotted in cleanly. Thanks!

cluricaun28 referenced this pull request in cluricaun28/Logos Apr 30, 2026
@teknium1 @MaxyMoos
feat(gateway): native send_multiple_images for Telegram, Discord, Sla…
d2407ef 
…ck, Mattermost, Email

Ports PR #17888's send_multiple_images ABC to every gateway platform that
has a native multi-attachment API, so images arrive as a single bundled
message instead of N separate ones.

Native overrides:
- Telegram: send_media_group (10 photos per album, chunks over); animated
  GIFs peeled off and routed through send_animation (albums don't support
  animations)
- Discord: channel.send(files=[...]) (10 attachments per message, chunks
  over); URL images downloaded into BytesIO so they render inline; forum
  channels use create_thread with files=[...]
- Slack: files_upload_v2(file_uploads=[...]) (10 per call, chunks over);
  respects thread_ts; records thread participation
- Mattermost: single post with file_ids list (5 per post — Mattermost cap,
  chunks over)
- Email: single SMTP message with multiple MIME attachments (no chunk cap,
  SMTP size governs); remote URLs remain linked in body (parity with
  existing send_image)

All platforms fall back to the base per-image loop on any failure, so a
single bad image in a batch never loses the rest.

Matrix, WhatsApp, and single-attachment platforms (BlueBubbles, Feishu,
WeCom, WeChat, DingTalk) continue to use the base default loop — their
server APIs only accept one attachment per message anyway.

Tests: adds tests/gateway/test_send_multiple_images.py with 19 targeted
tests covering base default loop, chunking, animation peel-off, fallback
paths, and empty-batch no-ops across all five new overrides.

Co-authored-by: Maxence Groine <maxence@groine.fr>
nickdlkk pushed a commit to nickdlkk/hermes-agent that referenced this pull request May 11, 2026
@teknium1 @MaxyMoos @nickdlkk
feat(gateway): native send_multiple_images for Telegram, Discord, Sla…
9e74e3a 
…ck, Mattermost, Email

Ports PR NousResearch#17888's send_multiple_images ABC to every gateway platform that
has a native multi-attachment API, so images arrive as a single bundled
message instead of N separate ones.

Native overrides:
- Telegram: send_media_group (10 photos per album, chunks over); animated
  GIFs peeled off and routed through send_animation (albums don't support
  animations)
- Discord: channel.send(files=[...]) (10 attachments per message, chunks
  over); URL images downloaded into BytesIO so they render inline; forum
  channels use create_thread with files=[...]
- Slack: files_upload_v2(file_uploads=[...]) (10 per call, chunks over);
  respects thread_ts; records thread participation
- Mattermost: single post with file_ids list (5 per post — Mattermost cap,
  chunks over)
- Email: single SMTP message with multiple MIME attachments (no chunk cap,
  SMTP size governs); remote URLs remain linked in body (parity with
  existing send_image)

All platforms fall back to the base per-image loop on any failure, so a
single bad image in a batch never loses the rest.

Matrix, WhatsApp, and single-attachment platforms (BlueBubbles, Feishu,
WeCom, WeChat, DingTalk) continue to use the base default loop — their
server APIs only accept one attachment per message anyway.

Tests: adds tests/gateway/test_send_multiple_images.py with 19 targeted
tests covering base default loop, chunking, animation peel-off, fallback
paths, and empty-batch no-ops across all five new overrides.

Co-authored-by: Maxence Groine <maxence@groine.fr>
02356abc pushed a commit to 02356abc/hermes-agent that referenced this pull request May 14, 2026
@teknium1 @MaxyMoos
feat(gateway): native send_multiple_images for Telegram, Discord, Sla…
f8fc506 
…ck, Mattermost, Email

Ports PR NousResearch#17888's send_multiple_images ABC to every gateway platform that
has a native multi-attachment API, so images arrive as a single bundled
message instead of N separate ones.

Native overrides:
- Telegram: send_media_group (10 photos per album, chunks over); animated
  GIFs peeled off and routed through send_animation (albums don't support
  animations)
- Discord: channel.send(files=[...]) (10 attachments per message, chunks
  over); URL images downloaded into BytesIO so they render inline; forum
  channels use create_thread with files=[...]
- Slack: files_upload_v2(file_uploads=[...]) (10 per call, chunks over);
  respects thread_ts; records thread participation
- Mattermost: single post with file_ids list (5 per post — Mattermost cap,
  chunks over)
- Email: single SMTP message with multiple MIME attachments (no chunk cap,
  SMTP size governs); remote URLs remain linked in body (parity with
  existing send_image)

All platforms fall back to the base per-image loop on any failure, so a
single bad image in a batch never loses the rest.

Matrix, WhatsApp, and single-attachment platforms (BlueBubbles, Feishu,
WeCom, WeChat, DingTalk) continue to use the base default loop — their
server APIs only accept one attachment per message anyway.

Tests: adds tests/gateway/test_send_multiple_images.py with 19 targeted
tests covering base default loop, chunking, animation peel-off, fallback
paths, and empty-batch no-ops across all five new overrides.

Co-authored-by: Maxence Groine <maxence@groine.fr>
jsboige pushed a commit to jsboige/hermes-agent that referenced this pull request May 14, 2026
@teknium1 @MaxyMoos
feat(gateway): native send_multiple_images for Telegram, Discord, Sla…
d62126a 
…ck, Mattermost, Email

Ports PR NousResearch#17888's send_multiple_images ABC to every gateway platform that
has a native multi-attachment API, so images arrive as a single bundled
message instead of N separate ones.

Native overrides:
- Telegram: send_media_group (10 photos per album, chunks over); animated
  GIFs peeled off and routed through send_animation (albums don't support
  animations)
- Discord: channel.send(files=[...]) (10 attachments per message, chunks
  over); URL images downloaded into BytesIO so they render inline; forum
  channels use create_thread with files=[...]
- Slack: files_upload_v2(file_uploads=[...]) (10 per call, chunks over);
  respects thread_ts; records thread participation
- Mattermost: single post with file_ids list (5 per post — Mattermost cap,
  chunks over)
- Email: single SMTP message with multiple MIME attachments (no chunk cap,
  SMTP size governs); remote URLs remain linked in body (parity with
  existing send_image)

All platforms fall back to the base per-image loop on any failure, so a
single bad image in a batch never loses the rest.

Matrix, WhatsApp, and single-attachment platforms (BlueBubbles, Feishu,
WeCom, WeChat, DingTalk) continue to use the base default loop — their
server APIs only accept one attachment per message anyway.

Tests: adds tests/gateway/test_send_multiple_images.py with 19 targeted
tests covering base default loop, chunking, animation peel-off, fallback
paths, and empty-batch no-ops across all five new overrides.

Co-authored-by: Maxence Groine <maxence@groine.fr>
dannyJ848 pushed a commit to dannyJ848/hermes-agent that referenced this pull request May 17, 2026
@teknium1 @MaxyMoos
feat(gateway): native send_multiple_images for Telegram, Discord, Sla…
07580c1 
…ck, Mattermost, Email

Ports PR NousResearch#17888's send_multiple_images ABC to every gateway platform that
has a native multi-attachment API, so images arrive as a single bundled
message instead of N separate ones.

Native overrides:
- Telegram: send_media_group (10 photos per album, chunks over); animated
  GIFs peeled off and routed through send_animation (albums don't support
  animations)
- Discord: channel.send(files=[...]) (10 attachments per message, chunks
  over); URL images downloaded into BytesIO so they render inline; forum
  channels use create_thread with files=[...]
- Slack: files_upload_v2(file_uploads=[...]) (10 per call, chunks over);
  respects thread_ts; records thread participation
- Mattermost: single post with file_ids list (5 per post — Mattermost cap,
  chunks over)
- Email: single SMTP message with multiple MIME attachments (no chunk cap,
  SMTP size governs); remote URLs remain linked in body (parity with
  existing send_image)

All platforms fall back to the base per-image loop on any failure, so a
single bad image in a batch never loses the rest.

Matrix, WhatsApp, and single-attachment platforms (BlueBubbles, Feishu,
WeCom, WeChat, DingTalk) continue to use the base default loop — their
server APIs only accept one attachment per message anyway.

Tests: adds tests/gateway/test_send_multiple_images.py with 19 targeted
tests covering base default loop, chunking, animation peel-off, fallback
paths, and empty-batch no-ops across all five new overrides.

Co-authored-by: Maxence Groine <maxence@groine.fr>
gweeteve pushed a commit to gweeteve/hermes-agent that referenced this pull request Jun 2, 2026
@teknium1 @MaxyMoos
feat(gateway): native send_multiple_images for Telegram, Discord, Sla…
cbbdb32 
…ck, Mattermost, Email

Ports PR NousResearch#17888's send_multiple_images ABC to every gateway platform that
has a native multi-attachment API, so images arrive as a single bundled
message instead of N separate ones.

Native overrides:
- Telegram: send_media_group (10 photos per album, chunks over); animated
  GIFs peeled off and routed through send_animation (albums don't support
  animations)
- Discord: channel.send(files=[...]) (10 attachments per message, chunks
  over); URL images downloaded into BytesIO so they render inline; forum
  channels use create_thread with files=[...]
- Slack: files_upload_v2(file_uploads=[...]) (10 per call, chunks over);
  respects thread_ts; records thread participation
- Mattermost: single post with file_ids list (5 per post — Mattermost cap,
  chunks over)
- Email: single SMTP message with multiple MIME attachments (no chunk cap,
  SMTP size governs); remote URLs remain linked in body (parity with
  existing send_image)

All platforms fall back to the base per-image loop on any failure, so a
single bad image in a batch never loses the rest.

Matrix, WhatsApp, and single-attachment platforms (BlueBubbles, Feishu,
WeCom, WeChat, DingTalk) continue to use the base default loop — their
server APIs only accept one attachment per message anyway.

Tests: adds tests/gateway/test_send_multiple_images.py with 19 targeted
tests covering base default loop, chunking, animation peel-off, fallback
paths, and empty-batch no-ops across all five new overrides.

Co-authored-by: Maxence Groine <maxence@groine.fr>
Egavasyug pushed a commit to Egavasyug/hermes-agent that referenced this pull request Jun 10, 2026
@teknium1 @MaxyMoos
feat(gateway): native send_multiple_images for Telegram, Discord, Sla…
508df31 
…ck, Mattermost, Email

Ports PR NousResearch#17888's send_multiple_images ABC to every gateway platform that
has a native multi-attachment API, so images arrive as a single bundled
message instead of N separate ones.

Native overrides:
- Telegram: send_media_group (10 photos per album, chunks over); animated
  GIFs peeled off and routed through send_animation (albums don't support
  animations)
- Discord: channel.send(files=[...]) (10 attachments per message, chunks
  over); URL images downloaded into BytesIO so they render inline; forum
  channels use create_thread with files=[...]
- Slack: files_upload_v2(file_uploads=[...]) (10 per call, chunks over);
  respects thread_ts; records thread participation
- Mattermost: single post with file_ids list (5 per post — Mattermost cap,
  chunks over)
- Email: single SMTP message with multiple MIME attachments (no chunk cap,
  SMTP size governs); remote URLs remain linked in body (parity with
  existing send_image)

All platforms fall back to the base per-image loop on any failure, so a
single bad image in a batch never loses the rest.

Matrix, WhatsApp, and single-attachment platforms (BlueBubbles, Feishu,
WeCom, WeChat, DingTalk) continue to use the base default loop — their
server APIs only accept one attachment per message anyway.

Tests: adds tests/gateway/test_send_multiple_images.py with 19 targeted
tests covering base default loop, chunking, animation peel-off, fallback
paths, and empty-batch no-ops across all five new overrides.

Co-authored-by: Maxence Groine <maxence@groine.fr>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

comp/gateway Gateway runner, session dispatch, delivery comp/tools Tool registry, model_tools, toolsets P2 Medium — degraded but workaround exists platform/signal Signal CLI adapter type/feature New feature or request

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@MaxyMoos @teknium1 @alt-glitch