+polite

[awfulcooking]

Indicates the message is not pressing / doesn't wish to distract (some of) the mentioned nicks.

Up to the recipient if this does anything.

@+polite=jwheare :[email protected] PRIVMSG #irccloud :B: yeah that'd be good for jwheare to take a look at in the morning

:Foo PRIVMSG #game !scores
@+polite=Wodda,Score,Jeff :Bot PRIVMSG #game :Foo: top scores | Wodda 100 | Score 90 | Jeff 80

@+polite=emersion :val PRIVMSG #project :i think emersion tried that at one point, then Amelie picked it up.

[emersion]

A hack I use to avoid highlighting users is to insert a zero-width space (U+200B) after the first character.

[awfulcooking]

A hack I use to avoid highlighting users is to insert a zero-width space (U+200B) after the first character.

Yes, that's excellent in some ways, but then I worry that someone seeing their nick not be underlined, highlighted or hoverable without explanation would be even more distracting..

Edit: imagine they copy it into a search, etc

[jesopo]

A hack I use to avoid highlighting users is to insert a zero-width space (U+200B) after the first character.

my bot used to do this until i realised it was both rendering as an actual space in some clients and breaking character width calculations in some terminals

[emersion]

someone seeing their nick not be underlined, highlighted or hoverable without explanation would be even more distracting

Right.

rendering as an actual space in some clients and breaking character width calculations in some terminals

These seem like client bugs, ie. not something that needs a new spec.

[progval]

Nitpick: the separator should be \s instead of comma because spec-wise, commas are allowed in nicks

EDIT (2023-08-25): actually they aren't, because commas are already used as a separator in KICK (and PRIVMSG)

[jesopo]

These seem like client bugs, ie. not something that needs a new spec.

one of these cases is actually a bug in Mac OS' terminal, which is out of scope for us to fix. i think making highlights an explicit act is a good idea, though i'm not sure about doing it by +polite

[awfulcooking]

The experience I pictured was your nick still being pilled or linked, and maybe appearing still in your highlight drawer, just not with a notification

[awfulcooking]

These seem like client bugs, ie. not something that needs a new spec.

It not being underlined / clickable would still be a significant UX bug, and not being fixable without "e\u200Bmersion" becoming the spec

[emersion]

one of these cases is actually a bug in Mac OS' terminal, which is out of scope for us to fix

If a client wanted to workaround this, they could strip out any U+200B from the message text after looking for highlights.

i think making highlights an explicit act is a good idea, though i'm not sure about doing it by +polite

Yup, same here.

An alternative would be to make highlights explicit by requiring a tag or a new formatting character to be present to represent highlights. Backwards compat needs to be addressed with this approach though.

[nektro]

there could be a capability for mention references to coordinate the backwards compat. enabled it could be like:

nektro is a polite mention

<@nektro> is an explicit mention

for clients that dont support the capability, the server can convert the latter back into the former

[awfulcooking]

That's an interesting idea @nektro. In that paradigm, would you expect the server to be polite-by-default?

CAP REQ polite-mentions

[nektro]

thanks, hmm I was more thinking about a UI that would parse the message and send the right one based on whether or not the user wanted it to be polite. if we wanted to optimize for hand-written messages to some degree i think keeping do-ping by default is the way to go. maybe nektro vs !nektro!

although, the !nektro! almost looks like a "super-ping" but im hesitant to use <nektro> for the non-ping version since ive seen this syntax used to reply to folks a lot before

having the ping-ness in-band is ideal i think but perhaps having it in the message metadata would indeed be better

having it in-band makes messages easier to write but the backwards compatibility easier or harder depending on what you're optimizing for
having it in the message meta puts the onus on clients to implement a UI to disable the ping-ness of a message, something like twitter's reply options

[acidvegas]

L O L

[awknode]

hahahahahaha

[hgw8]

Lmao