Change current role of 'type' and 'roles' regarding bot accounts

BOTs Special Interest Panel
1

Introduction

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.

The 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

Problem

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:

  1. 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.
  2. 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.

Solution

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.

2 Likes
2

This is awesome stuff. I agree with the direction and think it could lay the foundation for many future improvements, which is the whole point of the project, so that’s ace.

One such future enhancement could be providing a different login method, such as tokens, for bots. I think the roles are still important and should remain the central determining logic for access to data and platform features, because even different bot users will have different requirements in that regard. I don’t want this to be seen by anyone as a potential parallel system for determining that kind of access or processing, where the logic would check for type instead of role. So we need to be clear about what type is for and what roles are for. i.e. Some simple and direct documentation to that effect. Perhaps within the bots developer guides.

e.g. “Bots Accounts and Roles” - explaining the default bot role, that it gives bots a label and allows admins to control default permissions specific for bots, but they can also assign bots with different roles, or create bots without that role. Then finally explaining that all bots have a type field, which is only used for:

  • Showing appropriate fields when creating / editing account
  • Handling the account model differently in templates (e.g. not displaying emails)
  • Preventing emails (offline notifications etc) being sent unnecessarily to bots
  • Splitting accounts into groups (users or bots) for listing in admin screens
  • …whatever else you can think of

Lastly, on the point about the profile. I’d suggest it would be easier to just disable profile editing from with the bot’s view of the app. As long as the admin can set an avatar or change username / name for the user from bots management screen, there’s no reason they’d need to login as the bot to do it, which would be a big improvement over the current system. It also avoids trying to rewire a profile template for a different user type, which would be a pain.

1 Like
3

More from our discussion, for the record:

I think label should still come from role. The admin can set a custom label per role. They may not want it to say bot, they might want to change it to agent or have different labels for multiple bot roles like bot and super bot. That’s all aesthetics and preference, so we shouldn’t be locking it down. It has no effect on how they work, so leave it customisable per instance.

I want it to be super obvious for developers to avoid incorrectly implementing the type attribute when they should have used role instead, or the other way round. I’d like to find some kind of rule-of-thumb for when type is used. Something simple, like “only use the type field for account creation / edit and display - for processing in any method calls, api requests, room joins, etc (basically anything else) use the standard permissions to determine what the user can do, even if the user is a bot.”

4

One more idea: I feel a bot being a user partially ugly: Thought it can be addressed like a human, I doubt that all permissions shall be administered like the ones of users.
Personally, I consider a bot just an application with a text-based user interface. The logic and the way it integrates make it more similar to a Rocketchat App. I also discussed this with @bradley.hilton earlier: An app shall be impersonatable (what a beautiful word :wink: ). This would also allow the bot to bring other artifacts (starting from icons continuing to own rich form-based messages and even server side methods) and also provide a common mechanism to actually ship/deploy the Rocket.Chat side of a bot.

2 Likes
5

@bradley.hilton A good read about apps vs. bots to which I couldn’t agree more: https://blog.growthbot.org/chatbots-were-the-next-big-thing-what-happened

Also worth noting how Microsoft sees an app

Microsoft Teams apps are web apps, you can use any web-programming technology and can host them on any hosting platform.

An app in Teams consists of the following parts:

Tabs
Bots
Connectors
Messaging extensions
Activity feed integrations
Outgoing web hooks

6

On the topic of “a bot being a user partially ugly” I disagree. I can see that from a particular use-case or perspective, one might want to reform that status quo, but there are thousands upon thousands of bots that are purpose built to communicate this way. Wether it’s to provide sales or support automation or respond to natural language queries, there are often user identities attached to the bot that provide additional value to the interactions, they’re not just a means to an end.

I don’t see bots as simply a facade for an app, but an evolution of the app convention. Within a messaging platform, conversational UI provides a distinct and possibly more powerful alternative to a conventional app. The barriers to creation and adoption are all lower the less the interaction depends on a visual UI, in regard to responsiveness, accessibility, design, information architecture, user on-boarding and UX.

I’ve added some detail on how I see the distinction here, between what we’re discussing and Rocket.Chat apps. https://rocket.chat/docs/bots/bots-faq/#what-kinds-of-bots-work-with-rocketchat
These aren’t the same thing and it’s not a case of picking one over the other, the context, utility and value each provide is unique and I don’t think there’s any rationale to go all in on just one.

In regards to whether bot features should be subject to the current permissions system, yes they should. Rocket.Chat apps (afaik) are limited by the application interfaces available to them, so that’s a different issue. Conversational (external) bots main interactions within Rocket.Chat are to read and write messages and occasionally administer users and rooms, all provided for in the permissions system.

These concepts go well beyond what this topic was intended to cover, but it’s obviously an issue where people have concerns from a larger context. Essentially however, we’re talking about small changes to meet some short term objectives and lay foundations for the following steps. Pushing such broad concepts that would re-shape the use of heavily ingrained architectural components, is just not feasible, and can make it harder to take programatic steps forward.

7

I’m not following the details of this conversation but thought this…

image
image.jpg1614×606 141 KB

is a nice diagram showing the spectrum of rich message components from conversation to full GUI.

I also thought this link was interesting from the perspective of if a bot should impersonate a user: https://chatbotsmagazine.com/good-bots-to-great-companion-bots-part-1-3-ea7a11d45e0c
.

8

@tim.kinnane thanks for clarifying here. Of course I have to disagree :wink:
Not in all the places though (I understand this very topic as limited to the actual accounts stuff), but maybe where Rocket.Chat should be aiming at.
I’ll try to elaborate a bit - and then leave it.

I don’t see bots as simply a facade for an app, but an evolution of the app convention.

I agree with bots bot being a facade, but nor are they an “evolution”: Conversational interface lost a lot of advantages a GUI has got. While they follow an application logic (a state machine or a guided procedure), they don’t reveal their state to the user in a one-glance-manner. As a consumer of a bot, you don’t know what the bot additionally needs to know in order to fulfill the task at hand - nor what he might have got wrong.
Thus, in one aspect a purely conversational interface (even with rich buttons as proposed by @bizzbyster) has somewhat minor capabilities compared to apps. And I believe this should be changed by combining them.

Rich messages are a first step into this direction. They provide a GUI for a single interaction with the bot. What they don’t do is to visually represent the state (well, they can be, but only for simple scenarios). So imho, the next step is to develop apps/bots which have both, a graphical and conversational interface.

From a developer’s perspective, those would be two optional interfaces, an “app”, “rich bot”, “you-name-the-thing” (I would call it “Rocketlet” :wink: ) can offer. And Rocket.Chat (on desktop) has a good starting point with the sidebar being always visible.

Therefore, I made my point: Think about bots being more than what bots are out there, thousands of thousands with high expectations.

2 Likes
9

Agreed. But I think there are ways to improve upon this via persistent menus and other persistent state indicators so that at any time a user can see something about the bot/app state and also start doing whatever the user wants to do independent of where the bot is in a given conversation. While I don’t think bots can replace all apps, I think we can go much further towards the “Rich Bots” you envision to cover a larger number of use cases with bots than we do today.

I think its interesting to track what is happening with DAPPS in the blockchain world. They are essentially little web apps and interfaces like Status.im present them in the same UI interactive style as chats or chatbots. This was one of the motives behind “widechat” which integrates web browsing and web apps into the chat inbox/chatroom type interface. It would be great if we could architect Rich Bots in such a way that all of the functionality they need could be delivered by the bot architecture itself so that there is no need to register any additional thing like a Rocketlet. But perhaps that is what you are both trying to figure out here.

1 Like
10

It would be also nice to have an extra setting to manage bot accounts via LDAP.
E.g. have one OU in LDAP for people and another one for bots.
So have a second set of LDAP optons especially for bots (own filter, search base and attribute mappings, …).

1 Like