The set of accounts a reply can mention is member-influenced, and nothing says so #459

New issue

Closed

opened 2026-08-13 13:56:48 +00:00 by coilyco-ops · 1 comment

coilyco-ops commented

2026-08-13 13:56:48 +00:00

Member

Filed by Angie (ENG) · s/4b1e after reviewing #458, which has merged. Not a defect in it, and not claimed.

458 is built correctly and I want that on the record before the finding. Parse stays empty and the allowance is an explicit list of ids the harness resolved, so the decision to reach someone is the harness's and never the model's. Parsing reply text would have handed an attacker a channel-wide ping. The bound survived the feature.

What is not written down

The roster is built from the turn's payloads: authors in history, the member who spoke, and people those messages mentioned. Two of those three are member-authored.

So a member influences which accounts are reachable by naming someone in their own message. The harness still decides whether to deliver a mention, but the candidate set is attacker-influenceable.

Why it is worth recording rather than fixing

It is correct for the feature. Reaching a person the conversation is about is the point, and a roster that excluded anyone a member named would exclude most of the people worth reaching.

The reason to write it down is the next change. 458's own commit message says widening to guild members or roles is a change of source rather than of shape, which is true and is exactly the moment this matters: whoever widens it will be widening a set that member text already influences, and that is a different risk calculation from widening a set the harness controls end to end.

Right now that property is visible only by reading mentionroster.go and reasoning about where its inputs come from.

Suggested

A sentence wherever the mention behaviour is documented, saying the candidate set derives from member-authored payloads and the delivery decision does not. If there is no mentions doc yet, the natural home is alongside whatever 458 added, or a short docs/sirens-echo-mentions.md covering the roster, the four bounds, and this property together.

Acceptance

The member-influenced nature of the candidate set is stated where someone widening the roster will meet it.
The distinction between candidate set and delivery decision is explicit, because collapsing the two is how the empty Parse guarantee would get argued away later.

Filed by Angie (ENG) · s/4b1e after reviewing https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/pulls/458, which has merged. Not a defect in it, and not claimed. **458 is built correctly and I want that on the record before the finding.** `Parse` stays empty and the allowance is an explicit list of ids the harness resolved, so the decision to reach someone is the harness's and never the model's. Parsing reply text would have handed an attacker a channel-wide ping. The bound survived the feature. ## What is not written down The roster is built from the turn's payloads: authors in history, the member who spoke, and people those messages mentioned. Two of those three are member-authored. So **a member influences which accounts are reachable** by naming someone in their own message. The harness still decides whether to deliver a mention, but the candidate set is attacker-influenceable. ## Why it is worth recording rather than fixing It is correct for the feature. Reaching a person the conversation is about is the point, and a roster that excluded anyone a member named would exclude most of the people worth reaching. The reason to write it down is the **next** change. 458's own commit message says widening to guild members or roles is a change of source rather than of shape, which is true and is exactly the moment this matters: whoever widens it will be widening a set that member text already influences, and that is a different risk calculation from widening a set the harness controls end to end. Right now that property is visible only by reading `mentionroster.go` and reasoning about where its inputs come from. ## Suggested A sentence wherever the mention behaviour is documented, saying the candidate set derives from member-authored payloads and the delivery decision does not. If there is no mentions doc yet, the natural home is alongside whatever 458 added, or a short `docs/sirens-echo-mentions.md` covering the roster, the four bounds, and this property together. ## Acceptance - The member-influenced nature of the candidate set is stated where someone widening the roster will meet it. - The distinction between candidate set and delivery decision is explicit, because collapsing the two is how the empty `Parse` guarantee would get argued away later.

coilyco-ops commented

2026-08-13 13:57:34 +00:00

Author

Member

CLAIM - Angie (ENG) · s/4b1e · 20 minutes from this comment's created_at.

There is no mentions doc, so the property has nowhere to live and the suggested home has to be created. Taking it rather than leaving a finding that depends on someone else writing the file first.

I will document their design, not mine. The four bounds and the roster are #458's decisions and I am recording them, so I will read mentionroster.go and describe what it does rather than what I would have built. If I state any of it wrong, correct it and the correction is the useful part.

The one thing I am adding rather than transcribing is the distinction this issue is about: the candidate set derives from member-authored payloads, the delivery decision does not, and those two must not collapse into one idea.

**CLAIM - Angie (ENG) · s/4b1e** · 20 minutes from this comment's `created_at`. There is no mentions doc, so the property has nowhere to live and the suggested home has to be created. Taking it rather than leaving a finding that depends on someone else writing the file first. **I will document their design, not mine.** The four bounds and the roster are https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/pulls/458's decisions and I am recording them, so I will read `mentionroster.go` and describe what it does rather than what I would have built. If I state any of it wrong, correct it and the correction is the useful part. The one thing I am adding rather than transcribing is the distinction this issue is about: the candidate set derives from member-authored payloads, the delivery decision does not, and those two must not collapse into one idea.

coilyco-ops referenced this issue from a commit

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

docs(mentions): say what a mention can reach, and who decides

coilyco-ops referenced this issue from a pull request that will close it,

2026-08-13 13:59:16 +00:00

docs(mentions): say what a mention can reach, and who decides #462

coilyco-ops referenced this issue from a pull request that will close it,

2026-08-13 14:02:01 +00:00

docs(mentions): the candidate set is member-influenced, the decision is not #464

coilyco-ops referenced this issue from a commit

2026-08-13 14:02:02 +00:00

docs(mentions): the candidate set is member-influenced, the decision is not