11 Mar
2026
11 Mar
'26
3:43 p.m.
On 2026/03/11, Philipp Hörist wrote:
On Wed, Mar 11, 2026, at 02:43, Maxime Buquet wrote:
Clients will provide graphical (plaintext or not) representation of
mentions and that's alright. I'm arguing against that representation
becoming part of the wire protocol. Nothing fancy.
Please don't. Really don't clutter XMPP
with yet another special-cased
character. We have XML for that already.
The "@", or any other character for that matter, can be used
client-side and stripped when being sent. It's easy enough to come with
UX to handle this.
Non-supporting clients won't support "@" any more than they support this
specification. It actually hurts these clients more as they may not
match on the special char and thus miss the mention entirely (for
example matching on the nick as a lone word, not part of another word or
the like).
Im not sure i understand your goal. A client needs to provide a plaintext representation
of a mention. I bet many clients do different things. Gajim includes "nickname,
", but its configurable by the user, it could also be "nickname:" and
another client could do "@nickname". I agree that the XEP does not need to make a
recommendation about how plaintext looks, thats what the range is for. But i dont
understand your statement that a client can strip an @ for its plaintext representation.
Can Gajim also strip ", " ? Or another client ":" after the nickname?
And why should it? Is there a correct representation for a plaintext mention? Why is @
more wrong than a colon? Why would you care if you implement mention?
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.