BOT flag lacks notification of change

[vanosg]

First, I'd like to preface this with the fact that I understand this is more of a documentation of existing capability, rather than a novel specification to add. I'd like to go over what I see as a perceived weakness in the implementation and how changes could make the bot flag more useful and effective. These comments are made in the spirit of collaboration and improvement, not criticism of existing implementations.

The challenge I encountered with how the bot flag is currently used is the ability of a user to add or remove it without a notification being sent to other clients who have an interest in tracking bots on a channel. As it stands right now, I as a client could join the channel and use WHO to get a list of users for the channel, and note which users have the BOT flag attached to their 352 reply. Maybe if I'm in a GUI client, those bots are colored differently in the user list, or perhaps flood settings are modified for them- I'm sure users are far more creative with possible uses here than I am, so for arguments sake, lets assume I have a really killer use case. But, the fact remains, I have a list of users I think are bots. But five minutes later, one of those users could issue a -B and no longer be marked as a bot, but my client is unaware of the change, and whatever systems I have depending on that status being current are no longer synced or accurate. The counter point to this could be to track messages in channel and look for the draft/bot tag, but if the user is not talking, those tags are not shown.

I propose one of two options:

The first would be to prevent a user from removing a BOT flag they have applied unless they reconnect to the server. This is not 100% ideal because a client could still add it after joining the channel (which wouldn't be tracked as the change isn't announced), but at least clients marked as bots would not be out of synch due to a user removing a flag. This would also ease parsing requirements of message tags to look for a bot tag for each line read, as it tends to be easier to look for something that is there instead of something that isn't there.

The other alternative would be to add on to this standard with something similar to the away-notify method of tracking away statuses- send an update of some form when a bot flag is added or removed from a client- possibly something as simple as a TAGMSG could be generated, notifying the channel of the change. This way, an initial WHO of the channel would get the current status of a channel, a WHO of new members joining a channel would get the status of new joins, and any changes that occurred while a client was in a channel could then be tracked via a TAGMSG notifying others of the change.

I would also add that, in a general sense, the ability to arbitrarily change whether you are registered as a bot or not could defeat the purpose of the bot tag in the first place, if you remove a bot flag to evade a detection or punishment, or apply a bot flag to gain some reward or status. If it can't be trusted or consistently used, users are likely less inclined to implement or incorporate its functionality to their clients.

So there are two general solutions I see as a possibility for improving the current draft/WIP implementation, I'm sure there are other better approaches than that and I hope someone is able to suggest some. I personally, with not much background on history or implementation, would advocate for the TAGMSG approach or something similar.

Thanks, and I look forward to seeing if there are any changes we can make to aid in keeping BOT lists synched!

[progval]

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.

[DanielOaks]

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.

[grawity]

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.)

[vanosg]

_ 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

[slingamn]

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.