Webhooks

[Zomatree]

No description provided.

[itzTheMeow]

could the author ID be the webhook ID? and the webhook property holds information about the webhook (avatar, name, etc)

[arktn]

Why would message author be optional? I would think something along the lines of @itzTheMeow's comment would be better to work with. Leave the author id out and just use the webhook id.

[Zomatree]

Both ways is still a breaking change, I would prefer to properly separate them out, having to check other keys to find out how to parse a different item is not a good way to handle it.

[itzTheMeow]

you still have to check that the webhook key exists (or that the author id doesn't). also why not send the webhook name/avatar with the message instead of making the user fetch it separately? or add a way to fetch all hooks for a server

[itzTheMeow]

is there going to be a way to reset the webhook token without recreating it? or does that seem unnecessary

[insertish]

As per internal group chat, if the webhook is actually attached to a message, it should use the following struct:

struct MessageWebhook {
  // Id of Webhook
  id: String,
  // The name of the webhook - 1 to 32 chars
  name: String,
  // The id of the avatar of the webhook, if it has one
  avatar: Option<String>,
}

[Andre601]

One thing I was wondering about. Given the github integration, why not also support other remote git repo hosts like GitLab, BitBucket, Codeberg, etc, if they allow webhook sending?

Maybe even have two general paths /webhooks/<target>/<token>/gitea and /webhooks/<target>/<token>/forgejo to allow a more general support for self-hosted repos using Gitea or Forgejo respectively (I assume Forgejo utilizes the same webhook mechanics as Gitea but could be good to keep it separate, just in case), allowing a lot more repo hosts to be supported (Would eliminate the need to support Codeberg as it runs on Forgejo).

EDIT:
One other question I have is, if the PATCH route would allow the edit of specific messages.
If not could it perhaps be done by providing a message id within the request body itself to indicate an edit of a specific webhook message with the provided info (avatar, name, message, etc) rather than a global edit.

Alternatively could additional routes be provided like this:

PATCH  /webhooks/<target>/<token>/<message> - Edits a webhook message using a token, no permission required
PATCH  /webhooks/<target>/<message> - Edits a webhook message, requires permission
DELETE /webhooks/<target>/<token>/<message> - Deletes a webhook message using a token, no permission required
DELETE /webhooks/<target>/<message> - Deletes a webhook message, requires permission

This - again - is based on if the current PATCH and DELETE routes don't allow a webhook message id to be provided (Which I feel could be the better aproach).

[Andre601]

Also, this is unrelated to this RFC in particular, but to RFC in general: Maybe re-structure the shown API routes a bit by having a code highlighting (http) applied and also align the paths for easier readability?

See my previous comment for a working example.
This imo improves readability a bit by distinguishing the method and path from each other.

[Zomatree]

One thing I was wondering about. Given the GitHub integration, why not also support other remote git repo hosts like GitLab, BitBucket, Codeberg, etc, if they allow webhook sending?

I mentioned in the future ideas section on expanding the supported platforms, in the future I think it would be good to add more in another RFC, for the core webhooks RFC just GitHub support will be enough.

I cant see why a edit message route would be needed for webhooks, as all you should need is just creating messages, if you can think of some good examples on where you would need it then I might consider it.

[Rexogamer]

It might be useful if someone, say, edits an issue/comment? For what it's worth I think Discord lets you edit webhook messages, although if so they don't use this for the GitHub integration so hmm

[Rexogamer]

is there going to be a way to reset the webhook token without recreating it? or does that seem unnecessary

For what it's worth this also seems like a good idea to me

[Zomatree]

It might be useful if someone, say, edits an issue/comment? For what it's worth I think Discord lets you edit webhook messages, although if so they don't use this for the GitHub integration so hmm

webhooks are stateless in how they are implemented so we have no way of mapping the edit to the correct message, i dont think its worth maintaining a state for this.

[Andre601]

I cant see why a edit message route would be needed for webhooks, as all you should need is just creating messages, if you can think of some good examples on where you would need it then I might consider it.

The only case I could give is something similar to Discord's announcement feature, allowing to update a previously crossposted message.
Tho, this may be a thing for the bridge feature instead.

[insertish]

Tho, this may be a thing for the bridge feature instead.

Bridges as they currently exist don't use webhooks and instead use masquerades, and I don't think there's any benefit to switching to webhooks. "Native bridges" as they would be implemented later, would not have anything to do with webhooks either.

[insertish]

I think this is pretty much ready to merge now?
Only thing that I think might be unaccounted for is what kind of channels webhooks can be created on, I would probably deny Saved Messages, Voice Channels, and DMs but not group DMs (since those have settings).

[xXBuilderBXx]

Webhooks will have some interesting uses for Revolt but definitely could be better than other platforms.

Maybe a good idea would be to add a seperate permission set for webhooks so you can restrict masquerade so the webhook can't change name/avatar and only use default one, send embeds, use external emojis from other servers (not sure if it can check) and other stuff in the future.

[xXBuilderBXx]

Most services also have a /slack webhook type that is popular to use by many services, would there be support for this.

[Andre601]

Webhooks will have some interesting uses for Revolt but definitely could be better than other platforms.

Maybe a good idea would be to add a seperate permission set for webhooks so you can restrict masquerade so the webhook can't change name/avatar and only use default one, send embeds, use external emojis from other servers (not sure if it can check) and other stuff in the future.

Agree on this.
I hate Discord's system where Webhooks inherit permissions from the default (everyone) role instead of allowing a different set of permissions to be applied.
Can make it risky where you want to allow a webhook to mention roles via the "Tag everyone, here and all roles" permissions, but with the channel being accessible to everyone with write perms...

[insertish]

Webhooks will be available on staging soon for testing, some caveats which need to be addressed:

• Webhooks ignore all permissions currently.
• There is no way to restrict mentions on a message.

[nulldg]

it's a bit late for this but can't webhooks be handled by an official appbot?

[Zomatree]

I don't see the use in merging them together, they are separate ideas.

[Zomatree]

This RFC is now in its final comment period, if no other discussion is needed, this RFC can be merged.

[Andre601]

There is one thing I was wondering about.
I didn't research it enough, so sorry if there is a clear answer to this...

Does Revolt have a base-level check for malicious URLs using a database when messages are send to prevent such sending.
I ask because if that was the case, would it also extend to webhook messages?

[insertish]

Does Revolt have a base-level check for malicious URLs using a database when messages are send to prevent such sending. I ask because if that was the case, would it also extend to webhook messages?

Currently no, however if it were to be added it would automatically be available for webhooks since they share the message sending code.