coilyco-gaming/sirens-echo

Watch

Add file upload support for Discord messages #755

New issue

Closed

opened 2026-08-14 00:12:39 +00:00 by coilyco-ops-gaming · 2 comments

coilyco-ops-gaming commented

2026-08-14 00:12:39 +00:00

Member

Feature Request: File Upload in Discord Messages

Current limitation: This service cannot accept or process file attachments from Discord messages. When a message includes an attachment, the service reports it as unreadable rather than attempting to parse the content.

Requested capability: Enable the service to receive and interpret files attached to Discord messages (images, documents, spreadsheets, etc.) so members can share data directly in conversation.

Use cases:

Sharing screenshots for bug reports or visual questions
Uploading CSV/JSON data for analysis
Sending configuration files for review
Attaching logs or output files

Proposed implementation:

Discord gateway receives file attachments alongside message content
Attachments are stored temporarily in the request context
Service tools gain ability to read attachment URLs or downloaded content
Response can reference or analyze uploaded file contents

This would expand the service beyond text-only input and allow richer member interactions.

## Feature Request: File Upload in Discord Messages **Current limitation:** This service cannot accept or process file attachments from Discord messages. When a message includes an attachment, the service reports it as unreadable rather than attempting to parse the content. **Requested capability:** Enable the service to receive and interpret files attached to Discord messages (images, documents, spreadsheets, etc.) so members can share data directly in conversation. **Use cases:** - Sharing screenshots for bug reports or visual questions - Uploading CSV/JSON data for analysis - Sending configuration files for review - Attaching logs or output files **Proposed implementation:** 1. Discord gateway receives file attachments alongside message content 2. Attachments are stored temporarily in the request context 3. Service tools gain ability to read attachment URLs or downloaded content 4. Response can reference or analyze uploaded file contents This would expand the service beyond text-only input and allow richer member interactions.

coilyco-ops-gaming added the

🔒⚠️📦⚠️🔒 SANDBOXED 🔒⚠️📦⚠️🔒

label

2026-08-14 00:12:39 +00:00

coilysiren removed the

🔒⚠️📦⚠️🔒 SANDBOXED 🔒⚠️📦⚠️🔒

label

2026-08-14 00:15:58 +00:00

coilyco-ops commented

2026-08-15 01:29:49 +00:00

Member

Olaf (ops, claude seat). This reads as already delivered. Flagging rather than closing, because the title and the body ask for different things and only one of them shipped.

The body asks for inbound: "receive and interpret files attached to Discord messages", attachments reachable by tools, responses that analyze uploaded content. That exists.

internal/community/attachmentingest.go fetches uploads, with egress bounded to cdn.discordapp.com and media.discordapp.net.
agent.go:613 attachmentSources pulls them off the gateway message.
The file lands in the requester's scratchpad under a reserved uploads/, read back through scratch_read and scratch_search, with path confinement, a per-file limit, and a per-requester quota inherited from the tool-result spill path.
docs/sirens-echo-attachments.md documents the whole design, including why uploads/ is reserved against the model writing there and forging a member-supplied file.
Recent commits 7557ab9 and 388d5f1 refine what the turn is told about the stored upload.

Two gaps against the body as written, both already tracked elsewhere:

Text only. Ingest validates UTF-8 and refuses on a null byte, so the screenshot case in the use-case list is not covered. That is #168, and the "temporary virtual filesystem work" it says it waits on is what the scratchpad uploads/ path now is, so #168 looks unblocked rather than blocked.
CSV and JSON work as text; spreadsheets in a binary format do not.

The title is the part that could mislead. "Add file upload support for Discord messages" reads as outbound, and outbound genuinely does not exist: the harness constructs no Files and no Embeds anywhere, so nothing needs ATTACH_FILES today. I added that bit to the corrected install link in coilyco-bridge/deploy as forward capacity and labelled it there as the one permission with no issue behind it. If outbound file posting is actually wanted, it deserves its own issue rather than being read into this one.

Suggest closing this as delivered and letting #168 carry images, unless the intent was outbound all along.

**Olaf (ops, claude seat).** This reads as already delivered. Flagging rather than closing, because the title and the body ask for different things and only one of them shipped. The body asks for inbound: "receive and interpret files attached to Discord messages", attachments reachable by tools, responses that analyze uploaded content. That exists. * `internal/community/attachmentingest.go` fetches uploads, with egress bounded to `cdn.discordapp.com` and `media.discordapp.net`. * `agent.go:613` `attachmentSources` pulls them off the gateway message. * The file lands in the requester's scratchpad under a reserved `uploads/`, read back through `scratch_read` and `scratch_search`, with path confinement, a per-file limit, and a per-requester quota inherited from the tool-result spill path. * `docs/sirens-echo-attachments.md` documents the whole design, including why `uploads/` is reserved against the model writing there and forging a member-supplied file. * Recent commits `7557ab9` and `388d5f1` refine what the turn is told about the stored upload. Two gaps against the body as written, both already tracked elsewhere: * **Text only.** Ingest validates UTF-8 and refuses on a null byte, so the screenshot case in the use-case list is not covered. That is #168, and the "temporary virtual filesystem work" it says it waits on is what the scratchpad `uploads/` path now is, so #168 looks unblocked rather than blocked. * CSV and JSON work as text; spreadsheets in a binary format do not. **The title is the part that could mislead.** "Add file upload support for Discord messages" reads as outbound, and outbound genuinely does not exist: the harness constructs no `Files` and no `Embeds` anywhere, so nothing needs `ATTACH_FILES` today. I added that bit to the corrected install link in `coilyco-bridge/deploy` as forward capacity and labelled it there as the one permission with no issue behind it. If outbound file posting is actually wanted, it deserves its own issue rather than being read into this one. Suggest closing this as delivered and letting #168 carry images, unless the intent was outbound all along.

coilyco-ops referenced this issue

2026-08-15 01:30:03 +00:00

allow reading images #168

coilyco-ops added the

priority

autonomy

async-consult

labels

2026-08-15 15:18:13 +00:00

coilyco-ops added the

role/engineer

label

2026-08-15 21:12:26 +00:00

coilyco-ops commented

2026-08-17 20:31:04 +00:00

Member

Closing: the premise is half wrong, and #915 carries the real gap

Decided by Kai, 2026-08-17, recorded by Darren (director seat).

This issue says the service "reports [an attachment] as unreadable rather than attempting to parse the content." That is true only for binary. Reading internal/community/attachmentingest.go:

Uploads are fetched from exactly two hosts, cdn.discordapp.com and media.discordapp.net, off the Gateway payload rather than from message text.
The declared content type is recorded and never trusted, because the uploader chooses it.
The body is checked for a null byte and for utf8.Valid. Text passes and reaches the turn as a tool-readable document, capped by SIRENS_ECHO_ATTACHMENT_BYTES at 128 KB.
Anything failing those checks is recorded as refused_binary.

So text uploads already work. Of this issue's four use cases, the CSV and JSON analysis ones and the configuration-file and log ones are text and should work today. The screenshot case does not, and that is the whole remaining gap.

#915 was filed this afternoon scoped exactly to that: binary and image input, with the model-vision question separated from the media-format question, and with the cheaper half called out - making the refusal visible to the member is worth doing even if vision never lands, since today an ignored image is silently ignored.

What I offered and Kai did not take

Re-scoping this issue to verifying and documenting what text upload does today. Not chosen. Recording it because that verification is still worth someone's ten minutes: this issue is evidence that the working half is undiscoverable, and #906 explains why, since Echo cannot describe her own ingest layer.

#915 - the binary and image gap, priority/P3.
#201 - GIF reading, blocked behind the same model-vision question.
#869 - the outbound half. Echo cannot deliver a file either.

Closing as superseded by #915.

## Closing: the premise is half wrong, and #915 carries the real gap **Decided by Kai, 2026-08-17, recorded by Darren (director seat).** This issue says the service "reports [an attachment] as unreadable rather than attempting to parse the content." That is true only for binary. Reading `internal/community/attachmentingest.go`: * Uploads are fetched from exactly two hosts, `cdn.discordapp.com` and `media.discordapp.net`, off the Gateway payload rather than from message text. * The declared content type is recorded and **never trusted**, because the uploader chooses it. * The body is checked for a null byte and for `utf8.Valid`. Text passes and reaches the turn as a tool-readable document, capped by `SIRENS_ECHO_ATTACHMENT_BYTES` at 128 KB. * Anything failing those checks is recorded as `refused_binary`. So **text uploads already work.** Of this issue's four use cases, the CSV and JSON analysis ones and the configuration-file and log ones are text and should work today. The screenshot case does not, and that is the whole remaining gap. **#915** was filed this afternoon scoped exactly to that: binary and image input, with the model-vision question separated from the media-format question, and with the cheaper half called out - making the refusal *visible* to the member is worth doing even if vision never lands, since today an ignored image is silently ignored. ### What I offered and Kai did not take Re-scoping this issue to verifying and documenting what text upload does today. Not chosen. Recording it because that verification is still worth someone's ten minutes: this issue is evidence that the working half is undiscoverable, and #906 explains why, since Echo cannot describe her own ingest layer. ### Related * **#915** - the binary and image gap, `priority/P3`. * **#201** - GIF reading, blocked behind the same model-vision question. * **#869** - the outbound half. Echo cannot deliver a file either. Closing as superseded by #915.

coilyco-ops closed this issue

2026-08-17 20:32:08 +00:00

No milestone

No project

No assignees

2 participants

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

coilyco-gaming/sirens-echo#755

No description provided.

Rows
Columns