lib/discordgo: add activity to message struct

[l-zeuch]

Add a new MessageActivity type to the Message struct.
This MessageActivity type represents the activity sent with a message,
commonly referred to as an invite to a game session and such.

This is a suggestion on the support server, found here:
https://discord.com/channels/166207328570441728/356486960417734666/1125192216650977360

Signed-off-by: Luca Zeuch l-zeuch@email.de

[mrbentarikau]

any examples on how you'd use it, because it probably starts throwing <nil> at you in most cases.
also upstream dgo has type MessageActivity using constants for Type field

[l-zeuch]

any examples on how you'd use it, because it probably starts throwing
<nil> at you in most cases.

If you mean usage in templates it's simply .Message.Activity --
though I think you meant a use case; such one was presented here:
https://discord.com/channels/166207328570441728/525535451839463424/1125219568453947412

Summarised the OP suggested it to be used to moderate such invites, as
there is no way to prevent them with Discord permissions and most bots
don't read them either.

(Though there could probably be an automod v2 trigger as well -- but
that's not in scope of this PR.)

upstream dgo has type MessageActivity using constants for Type field

I'll take a look at that once I'm free again, thanks for the pointers.
For now I'll convert this to a draft to prevent premature merging.

Luca

[mrbentarikau]

Just, if you getMessage random message and .Activity over it, you will get nil - this is in most cases, so not really that usable if 0.003% of users are ever going to need it for template code.

Maybe adding it to amV2 as a rule to prevent such activity messages?

[l-zeuch]

if you getMessage random message and .Activity over it, you will get
nil - this is in most cases, so not really that usable if 0.003% of
users are ever going to need it for template code.

I'm not sure if I'm 100% following you here — are you saying just
because it isn't set most of the time it should not be added, even
though it is documented in the Discord API docs?

In a handful of servers I'm in such invites are constantly sent, so I
wouldn't say it's that rare.

Additionally, I wouldn't say just because something is rarely used it
shouldn't be added — it's not like it's a huge amount of code or causing
issues for the bot (unlike .Guild.Members, which we deliberately do
not expose to custom commands — it's still present on the struct though)

Maybe adding it to amV2 as a rule to prevent such activity messages?

That is certainly a good idea, though it still would have to be added
to the message struct nonetheless, how else will we be able to read it
for automod purposes?

I'll look into implementing such a trigger with a decent configuration
interface on the weekend.

[User9684]

Maybe adding it to amV2 as a rule to prevent such activity messages?

While it is a rare usecase, I can come up with reasons why someone might want it to be exposed in the message object.
What if someone wants to maybe ping a specific role when someone sends an invite to a specific game?
What if they want to give people a role that sent an invite to a specific game?

Just random ideas that people might come up with as a usecase for activity to be exposed in message.

[ashishjh-bst]

Maybe adding it to amV2 as a rule to prevent such activity messages?

While it is a rare usecase, I can come up with reasons why someone might want it to be exposed in the message object. What if someone wants to maybe ping a specific role when someone sends an invite to a specific game? What if they want to give people a role that sent an invite to a specific game?

Just random ideas that people might come up with as a usecase for activity to be exposed in message.

This doesn't tell you game details, just gives you activity type and party id.

[l-zeuch]

This doesn't tell you game details, just gives you activity type and
party id.

party_id contains some marginal info on what the invite is about —
for example, a spotify "listen along" invite will have spotify:123456
as party_id, where 123456 is the ID of the user sending the invite.

[l-zeuch]

I suggest we merge this change to the library and then, whenever we feel
like it, add a trigger to automod v2 (Advanced Automod), seeing as this
change will be necessary either way and I'm not a fan of having this
much logical separation in a single PR.