Client: Feature request: Allow bots

[NiklasBr]

The Terms of Service today forbids the use of bots or other automated tools, but the ability to have bots would be a huge boon for Teams. Is there any way to convince the Keybase team to allow bots?

For example, consider the ability to connect your CRM or intranet to Keybase Teams. Upon some events in the CMR/Intranet the CRM can post to a team channel that something happened, and maybe attach a file in the shared directory at the same time. Think Slack Bots.

I understand the need to prevent abuse (including automated abuse) of the system, so, rather than argue that bots should have free rein, I have a few ideas how I imagine bots can be allowed.

1. maybe the bot can be signed for by a real user who promises that it will behave. And if that promise is broken, the user who signed will be punished.

2. Or maybe a bot must be locked to a single Team and will not be allowed to interact with users outside ot that Team?

3. Make bots a paid feature. If your bot misbehaves, you have to pay again. :)

[mcassaniti]

I'd certainly like this feature too, but I'm also curious to know from a developer if it's even possible to support something like this.

I need a Slack webhook token If some automated system I have sends a message to a Slack channel via a webhook. All that token essentially does is provide authorisation (i.e.: I can actually send this message to this Slack team).

I can't understand the key interactions well enough to know what keys are involved when encrypting a message to a subteam and a channel. I mention a subteam because it's harder to get subteam information than team information from Keybase. If I wanted to post to the nike.hr team in the general channel, the Keybase servers would need enough information to know where to send that message and what keys to encrypt it with.

I can envisage a potential solution if the webhook needed to look quite similar to a Keybase user, which assumes that the Keybase servers don't know enough to deliver the message. This would require a fair bit of client side crypto work.

The other part of the problem is how the Keybase servers would authorise sending a message to a channel in a subteam using nothing more than a token, assuming that the Keybase servers do have enough information to post a message there.

[benthroop]

Just wanted to pipe in and say that Slack's ability to receive notifications from source control and post them is super important to us. Any thought of moving to Keybase from Slack would be a nonstarter without it.