As of now there is not a single difference between user and bot accounts, even the ‘bot’ role is just a role. This is not optimal because it difficults implementing bot-specific features, such as the issue #7125.
I’ve discussed this problem with @tim.kinnane when I found out about the
type attribute on User models. All users have
type: 'user' set (including bot accounts), while the
rocket.cat account is the only account with
type: 'bot'. My idea was to use it to better separate bots from normal users. @sing.li and diego.dorgam suggested me to see the current state of this attribute and discuss it with the rest of the community.
type account attribute is not really used, the few occurrences of it do not change their behavior with accounts of different types, you can see them here (mixed with a few bot properties of message objects): https://pastebin.com/BPTA5HiF
In the current situation, if an admin creates different roles to manage multiple bot accounts, the current approach of integrating bots by selecting them via the ‘bot’ role will stop working. A workaround would be to have a set of bot roles used by the system and changeable by the admin, however this is not practical as it would add more overhead on the code base and on the user experience.
Even if it is feasible to know who is a bot by their roles, other problems are still not solved. If an account with bot roles has them removed and others added, it would not be treated as a bot anymore. That is a problem for 2 reasons:
- If the intended behavior was to now treat it as an user account, it could be missing an e-mail or other properties needed by users but not by bots. Also, bot-specific properties once used become useless.
- If the intention was to still use it as a bot account, the account is not treated as a bot anymore and it might lose bot-specific features.
The reverse operation, converting users to bots, also has its problems, bot accounts do not currently need additional properties, but this will probably change as more features are launched. By converting a normal user account into a bot account, these properties will need to be set and to do that, the system will have to detect when bot roles are added to an user account and execute an operation to get additional details for the new bot.
All of the approaches above add unnecessary overhead to deal with bots and are just coupling even more the current system.
The main idea is to completely separate roles from the user type, we should not rely on roles to be able to tell who is a bot and who is not.
The ‘bot’ role should be only a default role for all accounts with
type: 'bot', with the possibility to be changed. If you add the ‘bot’ role to a
type: 'user' account, nothing happens besides the fact that a few more permissions were added to the user (in case they didn’t already have them).
The creation of the different types of accounts would be separated, as well as converting them into one another.
This decoupling, by defining a clear barrier between an user account a bot account, will help possible future improvements such as removing the need for an e-mail (soon) or using tokens to login instead of user/pass, simply because it will be easier to have different login systems, and that is just one example.
All changes regarding bots will probably benefit from this decoupling.