11 Mar
2026
11 Mar
'26
4:56 p.m.
On Wed, 11 Mar 2026 20:43:07 +0100
Maxime Buquet <pep(a)bouah.net> wrote:
If a client were to use "@" to autocomplete
nicknames, just like
gajim does, the client could also not include it in the wire protocol.
Just like gajim does.
As for anything that qualifies as a natural language (punctuation?)
like you showed, well I surely hope that also doesn't get specified
as the wire format.
It would be weird if it was mandated to include a comma (",") when
communicating in languages that don't use them, or use something else
(Japanese for example, and full-width chars). It's a good thing that
gajim made this configurable.
We can take natural languages into account to help shape the document
but we probably don't want to reference every single use-case/language
in it. We also don't want to ignore anything non-ascii/non-western
like it's been done in other XEPs, by mandating a specific character.
Making sure we're on the same page: the original idea here would NOT
have mandated the use of any character, nor any particular one. One
could send "user", "@user", "user:", or anything else, and
all I asked
was that the extra formatting character be included in the range, IF
you opt to send them at all. This recommendation would have applied
equally to all languages and characters with NO exceptions. It would
also not have recommended one way or the other whether to even send
those characters to begin with.
A client might stylise all mentions as "@user". It should be able to
receive "user", "@user", "user:", or anything else in the
body, and
know that it'll render as "@user", not "@@user" or
"@user:". This was
my sole goal.
Nonetheless, if people prefer to simply NEVER send the extra
characters, then I'm okay with that as well, since it also
achieves this goal. Though I think its less flexible, personally.