BOT flag lacks notification of change about ircv3-specifications HOT 5 OPEN

It seems like at this point we're talking about two different problems:

1. The bot mode is opt-in and untrusted, and users might opt in as a prank
2. The bot mode can be removed, causing a client state synchronization problem that is not addressed by the spec

but (1) is inherent to any version of this proposal, and I don't see what concrete problems (2) would cause for clients, beyond those inherent in the data not being trustworthy in the first place.

from ircv3-specifications.

But five minutes later, one of those users could issue a -B

Why would they do this? I don't see a good reason for a client to stop being a bot without reconnecting.

from ircv3-specifications.

But five minutes later, one of those users could issue a -B

Why would they do this? I don't see a good reason for a client to stop being a bot without reconnecting.

Bots don't have a reason to do this, but real users playing with /umode actually might. (I remember when half the channel had "is a bot" in their /whois despite none of them being bots...) Would it make sense to send draft/bot=0 or something? Or if "never unset" semantics are going to be introduced, put them behind a cap?

(My thinking is that at least /cap and /quote have a slightly higher barrier of "knowingly doing what you shouldn't", while umodes are much more exposed to the random user.)

from ircv3-specifications.

On enabling the bot mode, servers MUST send a TAGMSG with the draft/bot tag from the bot to all clients sharing a channel with the bot. On disabling the bot mode, servers MUST send a TAGMSG with a draft/bot=0 tag from the bot to all clients sharing a channel with the bot.

Something like that should work, yeah? (restricting it by the message-tags cap ofc) Can't really have a client stop being a bot, or at least I don't think that's a useful case to consider as part of the spec, so I reckon that'd be simple and work well enough to enable proper tracking.

edit: grawity made a good point, updated the language to account for that case too.

from ircv3-specifications.

_ but real users playing with /umode actually might.

Some users just like to watch the world burn... ;) I don't have a good reason as to why, except that they can. And if a user can, some user will. It's definitely an edge case, but maybe one that could be considered. I appreciate the commentary and consideration from everyone

from ircv3-specifications.