14 Mar
2026
14 Mar
'26
7:05 a.m.
On 2026/03/13, Snit Guckfung via Standards wrote:
Only the last one expects any level of understanding
of the mention's
text, but it is unclear to me why one would do that. Nonetheless, the
recommendation at least gives confidence that you need only parse
within the range, and never without.
It also occurs to me that our ideas are not mutually opposed. I can
just do like:
1. "Entities SHOULD strip processing characters before sending"
2. "If sent anyways, they SHOULD be included in the range"
Sorry this makes little sense to me. One should not break a SHOULD.
There should be a compelling reason to do so. I'm trying to find
a compelling reason for breaking this one (1.) but I'm out of ideas.
I do agree it gets blurry when talking about natural languages
(including commas and all), but I don't understand what's hard with "@"
or any other character used especially for this purpose.
On Fri, 13 Mar 2026 13:49:30 +0100
Maxime Buquet <pep(a)bouah.net> wrote:
This looks reasonable (for supporting entities).
With the possibility of eating any natural language feature that isn't
part of the nickname included in the range for option 2.
I guess that's alright if that's what the sending user meant. Sending
clients should probably be careful in handling that, maybe a note there
could help.
I guess that's where we disagree. As a
receiving implementation, why
would you have to display an "implementation detail" from another
client? You can't actually remove that implementation detail if you
feel it should not be displayed in your client, as you do not
understand it.
As a receiving entity, I see three potential options upon receiving an
arbitrary mention, regardless of its format:
1. Stylise mention with text as-is
2. Acquire user's name and replace the text with that
3. Attempt to parse the mention's text for post-processing