Incoming webhook API

[titpetric]

There's an incoming webhook API needed for our purposes. The intent of the API is to provide a simple link which can be used as a web hook from scripts or third party services, that allows sending messages to a particular channel. When creating a webhook, we need to define:

• name of the message author (ie. username),
• avatar from the message originator,

Ideally, we would take "username", "avatar", and "contents" as the webhooks JSON body parameters. This enables users to use one webhook to post messages seen uniquely in a channel based on different username/avatar parameters. This requires:

• must: store "username" and "avatar" on each message (may be nested inside meta json),
• must: some sort of JWT token on the generated webhook link for authentication,
• may: on creation of a webhook, generate a user with the "bot" type so the messages have a valid rel_user (we also need to update it if the webhook details would be changed),

I'd like to stick to the discord API example as the main guideline because of it's usability. Ideally our API would be similar, but with a smaller surface:

POST/channels/{channel.id}/webhooks - create webhook
- name (string) - required,
- avatar (file) - optional,
- post method: multipart/form-data

GET/channels/{channel.id}/webhooks - get channel webhooks

PATCH/webhooks/{webhook.id} - update webhook
- name (string) - optional,
- channel (uint64) - optional (move webhook to different channel),
- avatar (file) - optional
- post method: multipart/form-data

DELETE/webhooks/{webhook.id} - delete webhook
DELETE/webhooks/{webhook.id}/{webhook.token} - delete webhook, no auth needed here

- the reasoning behing this one is more out of convenience. If some webhook link would leak and would be discovered outside of the sysadmin teams, they could invalidate the webhook just by issuing a DELETE statement. Implementation at this point: optional, but easy.

POST/webhooks/{webhook.id}/{webhook.token} - send message to channel
- username (optional)
- avatar_url (optional)
- content (string, needs some kind of size limit)

This is a minimal subset of API calls needed to support a basic incoming webhook API. Discord provides specific APIs for hooks sent from GitHub, Slack, but we don't need to support that at this point, or maybe we can think of a better way how to support them in the future.

---

Future ideas:

• support some sort of mime type for the message (ie, send image, send html, markdown,...),
• have a server-side evaluator that can take any payload and produce an expected payload (transform github/gitlab/bitbucket push JSON into username/avatar_url/content with an embedded scripting language?)
• threading support, post a reply to a thread (slack webhooks support this with thread_ts),
• OAuth pairing of third party apps (again, slack)

[titpetric]

More info: the interface for webhooks should be reachable from the channel list (right click on channel, manage webhooks - if the user has the manage.webhooks permission for this).

[titpetric]

The API signatures have changed to be only available under /webhook entrypoint.

Additionally, outgoing webhooks have been implemented. A webhook trigger word, for example fortune, will enable a /fortune command which will query an external API, and produce a message in the active channel on response. There's room for improvement - like having commands that produce a direct-message response.