Echo cannot see any uploaded image, because attachment ingest refuses every binary file #915

Open
opened 2026-08-17 18:09:52 +00:00 by coilyco-ops · 0 comments
Member

Filed by Darren (director seat) during a capability audit mapping Go stdlib surface areas against what Echo can actually reach. Kai confirmed this should be its own issue rather than folded into #201.

What happens

A member posts a screenshot in a gaming community and Echo is blind to it. Not degraded, not partially informed. She receives nothing and has no way to say why.

The mechanism

internal/community/attachmentingest.go fetches uploads from the two Discord CDN hosts and then rejects anything that is not text:

// A null byte is the strongest binary signal and the cheapest to read.
...
return utf8.Valid(body)

A failing file is recorded as refused_binary. Every PNG, JPEG, GIF and WebP fails both checks on the first block. Text uploads work, capped by SIRENS_ECHO_ATTACHMENT_BYTES at 128 KB.

The egress bound itself is correct and is not what this issue is about. attachmentHosts is exactly cdn.discordapp.com and media.discordapp.net, the URL arrives on the Gateway payload rather than from message text, and the declared content type is recorded and never trusted because the uploader chooses it. Keep all of that.

Why this is worth its own issue

Two separable questions have been sitting in one place:

  1. Can the model accept image input at all? That is a model and deployment question, and nothing in this repository answers it today.
  2. Which media formats do we handle? That is #201, which asks for GIF reading at priority/P3.

Question 2 cannot be worked before question 1 is settled, and question 1 is not a media-format question. Folding them loses that ordering.

Why it matters more than the tier suggests

Sirens is a gaming community. Screenshots are how members show a base, a crafting screen, a bug, a market board. Echo answers questions about Eco while being structurally unable to look at the single most common way a member would show her one. She also cannot explain the refusal, since #906 records that she has no visibility into her own classifier or ingest layer, so the member gets an answer that ignores their image without acknowledging it exists.

Shape of a fix

  • Settle whether the deployed model on this lane accepts image input.
  • If it does, admit an allowlisted set of image MIME types past the binary check, keeping the CDN host bound and the declared-type distrust exactly as they are.
  • If it does not, make the refusal visible rather than silent, so a member is told their upload was not read. That is worth doing on its own even if vision never lands, and it is much cheaper.

The second bullet is the part that should not wait on the first.

  • #201 - GIF reading support, priority/P3. Blocked behind the same question.
  • #869 - the outbound half. Echo cannot deliver a file either.
  • #906 - Echo cannot describe her own ingest or classifier, which is why the refusal is silent.
Filed by Darren (director seat) during a capability audit mapping Go stdlib surface areas against what Echo can actually reach. Kai confirmed this should be its own issue rather than folded into #201. ## What happens A member posts a screenshot in a gaming community and Echo is blind to it. Not degraded, not partially informed. She receives nothing and has no way to say why. ## The mechanism `internal/community/attachmentingest.go` fetches uploads from the two Discord CDN hosts and then rejects anything that is not text: ```go // A null byte is the strongest binary signal and the cheapest to read. ... return utf8.Valid(body) ``` A failing file is recorded as `refused_binary`. Every PNG, JPEG, GIF and WebP fails both checks on the first block. Text uploads work, capped by `SIRENS_ECHO_ATTACHMENT_BYTES` at 128 KB. The egress bound itself is correct and is not what this issue is about. `attachmentHosts` is exactly `cdn.discordapp.com` and `media.discordapp.net`, the URL arrives on the Gateway payload rather than from message text, and the declared content type is recorded and never trusted because the uploader chooses it. Keep all of that. ## Why this is worth its own issue Two separable questions have been sitting in one place: 1. **Can the model accept image input at all?** That is a model and deployment question, and nothing in this repository answers it today. 2. **Which media formats do we handle?** That is #201, which asks for GIF reading at `priority/P3`. Question 2 cannot be worked before question 1 is settled, and question 1 is not a media-format question. Folding them loses that ordering. ## Why it matters more than the tier suggests Sirens is a gaming community. Screenshots are how members show a base, a crafting screen, a bug, a market board. Echo answers questions about Eco while being structurally unable to look at the single most common way a member would show her one. She also cannot explain the refusal, since #906 records that she has no visibility into her own classifier or ingest layer, so the member gets an answer that ignores their image without acknowledging it exists. ## Shape of a fix * Settle whether the deployed model on this lane accepts image input. * If it does, admit an allowlisted set of image MIME types past the binary check, keeping the CDN host bound and the declared-type distrust exactly as they are. * If it does not, make the refusal **visible** rather than silent, so a member is told their upload was not read. That is worth doing on its own even if vision never lands, and it is much cheaper. The second bullet is the part that should not wait on the first. ## Related * #201 - GIF reading support, `priority/P3`. Blocked behind the same question. * #869 - the outbound half. Echo cannot deliver a file either. * #906 - Echo cannot describe her own ingest or classifier, which is why the refusal is silent.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
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#915
No description provided.