Thread Support

[Cisien]

I understand it's still very early in the rollout of thread support to discord communities, but large public communities are starting have the option of enabling this feature in their servers. Unfortunately, bots written in discord.net cannot see the messages sent in threads, and therefore cannot moderate threads.

Is thread support on the roadmap for discord.net? Or should we seek out alternatives?

[xXBuilderBXx]

Gateway events for threads are on version 9 of the Discord API atm which would probably need some major changes to the code also it dosen't even support buttons and slash commands yet either so threads are gonna take a while.

[JimboJacksonBroDudeMan]

IMO this one should be waaaaaaay higher priority than slash commands or buttons. a lot of us use discord.net for moderation functions so having our bots not being able to see threads complicates everything.

[Cisien]

It means that discord.net isn't suitable for purpose on servers that wish to use this feature.

[JimboJacksonBroDudeMan]

So your solution here is to completely rewrite our bots using something else. Got it. Very helpful.

[Cisien]

I'm not affiliated with this project. For what it's worth; we are re-writing our bots to use other libraries that have support for threads.

[AntiTcb]

You don't have to complete re-write your bots; you can have multiple applications running simultaneously. Keep your existing bot in D.NET, and you're free to also have an application running using a separate API library with the support for the newer Discord features that this library doesn't support yet.

[Cisien]

Yeah, sure. That's AN option, but a terrible one.

[SubZero0]

I understand how critical threads can be for some, I'll try to get some time to add support to them in the latest version.
So applications can, at least, receive and process messages sent in those.

For now, my plan is doing it in a similar way as private channels, as not keeping them in cache (unlike text channels), and I'll probably need to request the ability to use threads in a private server to Discord so I can test it.

[JimboJacksonBroDudeMan]

I understand how critical threads can be for some, I'll try to get some time to add support to them in the latest version.
So applications can, at least, receive and process messages sent in those.

For now, my plan is doing it in a similar way as private channels, as not keeping them in cache (unlike text channels), and I'll probably need to request the ability to use threads in a private server to Discord so I can test it.

Check your servers. My partnered server didnt have it enabled till after the partnered happy hour today but a server of mine with 7 members had it enabled before that and another with a few hundred had it before as well.

I checked two of my friend's private servers and both have threads enabled already.

[SubZero0]

To start, I wrote two possible solutions:

#1901 - Change the IMessage.Channel property from IMessageChannel to Cacheable<IMessageChannel, ulong>
Pro: this would make pretty easy to know if the channel is present or not, while making people adjust their code (won't get surprised by the change since they will need to redo the logic as it'll break)
Con: sending messages isn't as trivial as before as Channel could not be there, would require adding SendMessage and SendFile to the client and changing from context.Channel.SendMessageAsync(... to context.Client.SendMessageAsync(channelId, ... if they don't want to possibly download the channel

#1902 - Create a new channel type: UnknownChannel
Pro: won't require any changes as Channel will still exist as an IMessageChannel, no weirdness to send messages/files
Con: logic from before might not work well, since this new channel type wasnt considered when they built their applications (Name would be null and different logic as this channel at the moment could only be a thread channel but not classified as one since the id is the only thing present), would require to get the actual channel ("download" by REST) to do more than send messages/files

At this moment, I'm leaning towards the second because one of the two:

• If I decide to cache thread channels, the lib consumer will barely notice the existance of SocketUnknownChannel when a proper SocketThreadChannel is added by a following PR.
• If I don't, it's still "plug'n'play" and trivial to send messages, except that when using the lib, it might be needed to be careful with SocketUnknownChannels and deal with it differently since it would be needed to get the channel by REST (for now, the only case for an unknown channel is a thread).

[quinchs]

I mean... labs has threads, i can open a PR and we can work from there to implement them here @SubZero0