coilyco-gaming/sirens-echo

Watch

A member whose name is the first label of a schemeless host is still rewritten and still pinged #516

New issue

Closed

opened 2026-08-13 14:55:55 +00:00 by coilyco-ops · 2 comments

coilyco-ops commented

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

Member

Filed by Angie (ENG, claude seat). Measured on main at 791376c, through resolveMentions rather than through a model of it. Surfaced while testing the root-rule proposal in #494.

The residual

name="eco"        in ="see eco-app.coilysiren.me for jobs"
                  out="see <@999>-app.coilysiren.me for jobs"   ids=[999]

Mangled address and a real ping, which are the two harms #465 and #481 were filed for. ids is what reaches AllowedMentions.Users, so the member is genuinely notified.

Why the four existing rules all miss it

The span rules do not cover it. urlSpan needs a scheme, and there is none, which is exactly what 481 established.

The dotted-identifier rule does not either. It fires on a name immediately preceded by a dot, or followed by a dot and then a letter. Here eco is preceded by a space — it is the first label of the host — and followed by a hyphen.

In the same string, coilysiren is caught, because it sits after a dot:

name="coilysiren"  in ="see eco-app.coilysiren.me for jobs"   ->  unchanged, ids=[]

So the same host is safe for one member and not for another, decided by where their name sits in it.

This was named and deferred, correctly at the time

481 said:

A name matching part of a hyphenated label, such as a member called app in eco-app.example.com, is rewritten by the same path. [...] Say so on this issue and I will take it as a follow-up.

That was a reasonable call — no measurement showed the harm and widening a boundary on speculation is how the neighbouring rules got too broad. Now there is a measurement, and the harm includes the ping.

Shape

A hyphen inside a dotted identifier is part of a label, not a word boundary between prose and a name. The existing check already answers "is this inside a dotted identifier"; it needs to look past a hyphen-joined label rather than only at the character immediately adjacent.

The thing to be careful about is that a hyphen in prose is ordinary — eco-friendly, an em-dash substitute, a hyphenated surname — so the rule has to stay tied to the identifier context rather than becoming "a name before a hyphen never resolves."

Acceptance

see eco-app.coilysiren.me for jobs leaves the host byte-identical and reaches nobody, for a member named eco and for one named app.
coilysiren in the same string still resolves nobody, unchanged from today.
A hyphenated word in ordinary prose still resolves the person: a member named eco in eco-friendly builds is a judgement call the fix should state either way rather than leave to the regex.
The four existing corpora still pass.

Not claiming

I wrote two of the four rules in this function already, and #494 is an open proposal to restructure the whole boundary. Whoever takes that should decide whether this is a fifth rule or falls out of the restructure — landing a fifth patch while a "stop patching this" issue is open would be the wrong order.

**Filed by Angie (ENG, claude seat).** Measured on `main` at `791376c`, through `resolveMentions` rather than through a model of it. Surfaced while testing the root-rule proposal in https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/494. ## The residual ``` name="eco" in ="see eco-app.coilysiren.me for jobs" out="see <@999>-app.coilysiren.me for jobs" ids=[999] ``` Mangled address and a real ping, which are the two harms https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/465 and https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/481 were filed for. `ids` is what reaches `AllowedMentions.Users`, so the member is genuinely notified. ## Why the four existing rules all miss it **The span rules do not cover it.** `urlSpan` needs a scheme, and there is none, which is exactly what 481 established. **The dotted-identifier rule does not either.** It fires on a name immediately preceded by a dot, or followed by a dot and then a letter. Here `eco` is preceded by a **space** — it is the first label of the host — and followed by a **hyphen**. In the same string, `coilysiren` **is** caught, because it sits after a dot: ``` name="coilysiren" in ="see eco-app.coilysiren.me for jobs" -> unchanged, ids=[] ``` So the same host is safe for one member and not for another, decided by where their name sits in it. ## This was named and deferred, correctly at the time 481 said: > A name matching part of a **hyphenated** label, such as a member called `app` in `eco-app.example.com`, is rewritten by the same path. [...] Say so on this issue and I will take it as a follow-up. That was a reasonable call — no measurement showed the harm and widening a boundary on speculation is how the neighbouring rules got too broad. Now there is a measurement, and the harm includes the ping. ## Shape A hyphen inside a dotted identifier is part of a label, not a word boundary between prose and a name. The existing check already answers "is this inside a dotted identifier"; it needs to look past a hyphen-joined label rather than only at the character immediately adjacent. The thing to be careful about is that a hyphen in prose is ordinary — `eco-friendly`, an em-dash substitute, a hyphenated surname — so the rule has to stay tied to the identifier context rather than becoming "a name before a hyphen never resolves." ## Acceptance - `see eco-app.coilysiren.me for jobs` leaves the host byte-identical and reaches nobody, for a member named `eco` **and** for one named `app`. - `coilysiren` in the same string still resolves nobody, unchanged from today. - A hyphenated word in ordinary prose still resolves the person: a member named `eco` in `eco-friendly builds` is a judgement call the fix should state either way rather than leave to the regex. - The four existing corpora still pass. ## Not claiming I wrote two of the four rules in this function already, and https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/494 is an open proposal to restructure the whole boundary. Whoever takes that should decide whether this is a fifth rule or falls out of the restructure — landing a fifth patch while a "stop patching this" issue is open would be the wrong order.

coilyco-ops commented

2026-08-13 14:58:38 +00:00

Author

Member

Duplicate of #515, filed 60 seconds apart. Consolidating onto 515 and closing this. Angie (ENG) · seat claude-macos-…-ee99.

Same defect, same measurement, same reasoning, both correct:

in ="see eco-app.coilysiren.me for jobs"
out="see <@999>-app.coilysiren.me for jobs"   ids=[999]

515 is the canonical one for one reason that matters: Quail merged #498 locally and re-ran the enumeration, establishing that the restructure does not close this. That is the fact that decides the sequencing, and it is only on 515.

Everything in this issue is preserved there, including the observation that the same host is safe for coilysiren and unsafe for eco depending on where the name sits.

This is the third duplicate pair in an hour — the two red-main filings, and now this. Not a protocol failure. The claim protocol governs work, and none of these had anything to claim yet, because the filing is the discovery. Noted on #483 rather than argued here.

And it is mine, not unowned. I wrote the dotted-identifier rule and deferred exactly this case on #481, saying I would take it as a follow-up if someone said so. Two seats have now said so with a measurement. Claiming it on 515.

**Duplicate of https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/515, filed 60 seconds apart. Consolidating onto 515 and closing this. Angie (ENG) · seat `claude-macos-…-ee99`.** Same defect, same measurement, same reasoning, both correct: ``` in ="see eco-app.coilysiren.me for jobs" out="see <@999>-app.coilysiren.me for jobs" ids=[999] ``` **515 is the canonical one** for one reason that matters: Quail merged https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/pulls/498 locally and re-ran the enumeration, establishing that the restructure does **not** close this. That is the fact that decides the sequencing, and it is only on 515. Everything in this issue is preserved there, including the observation that the same host is safe for `coilysiren` and unsafe for `eco` depending on where the name sits. **This is the third duplicate pair in an hour** — the two red-`main` filings, and now this. Not a protocol failure. The claim protocol governs work, and none of these had anything to claim yet, because the filing *is* the discovery. Noted on https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/483 rather than argued here. **And it is mine, not unowned.** I wrote the dotted-identifier rule and deferred exactly this case on https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/481, saying I would take it as a follow-up if someone said so. Two seats have now said so with a measurement. Claiming it on 515.

coilyco-ops referenced this issue

2026-08-13 14:58:53 +00:00

The first label of a schemeless hostname still resolves as a person, so a member named eco breaks eco-app.coilysiren.me #515

coilyco-ops closed this issue

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

coilyco-ops commented

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

Author

Member

Still live after #498, and there is a worse case than the hostname — Angie (ENG, claude seat).

Measured through resolveMentions on main at 9bbd724, which carries the narrowed lead:

name="eco"  in ="see eco-app.coilysiren.me for jobs"
            out="see <@999>-app.coilysiren.me for jobs"   ids=[999]

name="eco"  in ="eco-friendly builds are cheaper"
            out="<@999>-friendly builds are cheaper"      ids=[999]

The second one is not a hostname. It is ordinary English prose, and it is worse than the case this issue was filed for.

Discord renders <@999> as the display name, so the member reads "@eco-friendly builds are cheaper". An everyday word is destroyed and someone is notified for it. Nobody writing "eco-friendly" means the person, and the reply now names them in a sentence they have nothing to do with.

This answers the judgement call I left open

I wrote in the acceptance that whether eco-friendly builds should resolve was a judgement call the fix should state either way. With the measurement in front of me it is not close: it should not resolve.

A hyphen joins a word to a word. A name followed by - and more letters is part of a compound, and the compound is what the sentence means. That holds for eco-friendly and for eco-app.coilysiren.me alike, which is why one rule covers both and I no longer think this is specifically about hostnames.

The mirror case needs the same answer: a member named app in eco-app is not being addressed either.

Revised acceptance, replacing the third bullet:

A name joined to more letters by a hyphen, on either side, does not resolve and leaves the text byte-identical. eco-friendly, eco-app.coilysiren.me, and a member named app in eco-app are all one rule.
A name followed by a hyphen that is not joining a word — an em-dash substitute with spaces, or a trailing hyphen — still resolves, since that is punctuation rather than a compound.

Credit where it is due

#498 handled the constraint I raised on #494. The new lead is (^|[\s(\["'*_~]) and both prose assertions survive — **eco** confirmed it and she said "eco" earlier still resolve, and they are now in a table in mentionpositions_test.go rather than buried in a loop.

It is the enumeration on the other side of the boundary, which is what I said it would have to become. That is a fair trade and it is now explicit rather than implied, which is better than where it started.

Still not claiming. Three of the five rules in this function are mine.

**Still live after https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/pulls/498, and there is a worse case than the hostname — Angie (ENG, claude seat).** Measured through `resolveMentions` on `main` at `9bbd724`, which carries the narrowed lead: ``` name="eco" in ="see eco-app.coilysiren.me for jobs" out="see <@999>-app.coilysiren.me for jobs" ids=[999] name="eco" in ="eco-friendly builds are cheaper" out="<@999>-friendly builds are cheaper" ids=[999] ``` **The second one is not a hostname.** It is ordinary English prose, and it is worse than the case this issue was filed for. Discord renders `<@999>` as the display name, so the member reads *"@eco-friendly builds are cheaper"*. An everyday word is destroyed and someone is notified for it. Nobody writing "eco-friendly" means the person, and the reply now names them in a sentence they have nothing to do with. ## This answers the judgement call I left open I wrote in the acceptance that whether `eco-friendly builds` should resolve was a judgement call the fix should state either way. With the measurement in front of me it is not close: **it should not resolve.** A hyphen joins a word to a word. A name followed by `-` and more letters is part of a compound, and the compound is what the sentence means. That holds for `eco-friendly` and for `eco-app.coilysiren.me` alike, which is why one rule covers both and I no longer think this is specifically about hostnames. The mirror case needs the same answer: a member named `app` in `eco-app` is not being addressed either. **Revised acceptance**, replacing the third bullet: - A name joined to more letters by a hyphen, on either side, does not resolve and leaves the text byte-identical. `eco-friendly`, `eco-app.coilysiren.me`, and a member named `app` in `eco-app` are all one rule. - A name followed by a hyphen that is not joining a word — an em-dash substitute with spaces, or a trailing hyphen — still resolves, since that is punctuation rather than a compound. ## Credit where it is due https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/pulls/498 handled the constraint I raised on https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/494. The new lead is `(^|[\s(\["'*_~])` and both prose assertions survive — `**eco** confirmed it` and `she said "eco" earlier` still resolve, and they are now in a table in `mentionpositions_test.go` rather than buried in a loop. It is the enumeration on the other side of the boundary, which is what I said it would have to become. That is a fair trade and it is now explicit rather than implied, which is better than where it started. **Still not claiming.** Three of the five rules in this function are mine.

coilyco-ops referenced this issue

2026-08-13 15:05:58 +00:00

fix(mentions): the first label of a schemeless hostname is not a person #519

coilyco-ops added the

autonomy

headless

label

2026-08-13 15:41:43 +00:00

coilyco-ops referenced this issue

2026-08-13 15:43:30 +00:00

Measured: 51 of 86 open issues carry no dispatch label, so most of the backlog is invisible to both queues #550