New invite and reaction events, and a new endpoint!

[msciotti]

We built this: #838

There's a new endpoint and event that goes with it!

There's also some new events for when invites are created and deleted.

The features flags on the reactions endpoint should be abled now; if you have issues accessing it, please let us know here.

[kyranet]

Is there any reason why the MESSAGE_REACTION_REMOVE_EMOJI packet doesn't include a guild_id field? Feels inconsistent with MESSAGE_REACTION_REMOVE_ALL.

[msciotti]

@RogueException could speak better to that one, if ya don't mind just kidding, turns out I'm blind

[night]

probably a documentation bug? all events sent from guilds have a guild_id injected into them.

[MBR-0001]

Looks like the invite events are sent to a bot only if it has the MANAGE_CHANNELS permission, this may be worth documenting (unless there's a plan to remove this requirement?)

[Dramex]

#448 when

[spergmoment]

I noticed MESSAGE_REACTION_ADD is also quite... odd. Its hard to get any asynchronous events from it, is this known or is it normal.

[ghost]

I feel like in the same way you provide us full info on a message that is deleted, with all the metadata, you should consider providing this information on the delete endpoint for invites like you do for create.

The main issue I am finding is that without having to keep a full history client side of every reaction made, users will still struggle to find out who created the invite that just got deleted, etc, which would be overly useful for auditing as well as for providing a consistent interface to the end user.

For example, in the framework I am implementing currently, I can provide the full invite object to the user on the invite_create event, but on the invite delete event, I can only provide the guild, channel, and the invite code, which is inconsistent and doesn't provide any real benefit to the user other than a string of a few characters representing the URL that no longer works.

[Skillz4Killz]

If memory serves MESSAGE_DELETE only provides a id, channel id and guild id. Isn't it just the same way to handle invites? Cache the invites so you can provide it the lib user when its deleted

[ghost]

@Skillz4Killz maybe i was mistaken then; the problem is that without having to physically request invites for each guild on startup, there is no way to determine what the invite was that just got removed, which is not helpful for moderation bots, for example, that may go offline during a partial outage; it is one more place that you have to rely on a bot having 100% uptime to provide the ability to track invites correctly.

While this might be fine for things like messages, I would assume the main usecase for tracking invite creation and deletion in the first place is for moderation purposes. Presumably this information is still available to Discord before they delete the entity in their backend.

I guess my point is this: for the sake of a slightly larger payload, you would be able to provide much greater detail to bots about what invite was actually removed, even if the invite was added before the bot came online. It would also then reduce the number of bots that are spamming the get invites endpoint on startup/resume/guild creation to fill in this missing information.

For the argument of performance, this sort of operation should be seen much less frequently than with other endpoints such as message deletion.

The other solution would be to include invite data in the Guild entity that is sent on guild creation if the bot has permission to view them

[ghost]

true, the other fields that you mentioned would be useful though; I'll admit I didn't really think this through before opening my mouth lol

[night]

we should just clone https://discordapp.com/developers/docs/resources/invite#invite-metadata-object behavior and link to the user object as this event is just serializing the invite the same way. then we avoid redocumenting user

[msciotti]

I notice here that we actually serialize this different than our normal invite object. Our invite object from our REST API returns guild and channel objects in which are id fields, but this event flattens them out. From our API:

"code": "123456",
    "guild": {
        "id": "290926798626999999",
        "name": "Mason's Test Server",
        "splash": "75610b05a0dd09ec2c3c7df9f6975ea0",
        "banner": "5c3cb8d1bc159937fffe7e641ec96ca7",
        "description": null,
        "icon": "389030ec9db118cb5b85a732333b7c98",
        "features": [
            "BANNER",
            "NEWS",
            "INVITE_SPLASH",
            "VANITY_URL",
            "COMMERCE",
            "VERIFIED",
            "VIP_REGIONS"
        ],
        "verification_level": 0,
        "vanity_url_code": "absh12385f"
    },
    "channel": {
        "id": "651144899865089999",
        "name": "news",
        "type": 0
    },
    "inviter": {
        "id": "53908232506183680",
        "username": "Mason",
        "avatar": "a_d5efa99b3eeaa7dd43acca82f5692432",
        "discriminator": "1337"
    }
}

Should we normalize these?

[Erk-]

It seems that the INVITE_CREATE event is currently sometimes sent without the inviter field. Is this a bug or an issue with the documentation?

[night]

Invites do not always have an inviter. For example, an invite created by a widget has no inviter.

[night]

lgtm otherwise