|
Experimentation over a few days has revealed a lot more about Discord thread
and forum behavior to me, so here's a halfass summary of lessons-learned.
Nowhere am I implying that any server admin should uproot existing structures,
but this may offer some insight into phased migration strategies, building
other servers for different purposes and communities, and where all this
may head in the future.
Understanding the behavior and caveats, and possibly Discord's thought process
behind it all, is the first step.
Threads and forums are basically channels at heart, despite what various online "documentation" sources try to say. There's quite a bit of evidence to support this. Most visibly, if you're viewing in a browser with a "https://discord.com/channels/BIGNUMBER/BIGNUMBER" location displaying, the second number changes whenever you navigate to any thread or forum. This tells us that not only is the same basic channel structure underlying these mechanisms, any message in a server can be directly navigated to with the three-part server/channel/message URL suntax [the full "message link"] regardless of which structure type it resides in. Discord's support doc seems to present an inaccurate notion of threads, calling them "temporary" and claiming that they are messages rather than channels. They are as temporary or permanent as anyone chooses to make them, really. Sure, they go "inactive" and tend to disappear from left-column lists, but they're always findable again. The same is true of forums and their content. Discord's own informational messages often refer to threads as "channels". For example, this transpired inside a thread: |
|
| It really is a channel |
|
To clarify Discord's own confusing nomenclature around it, any normal text
channel can be a "treehead" for sets of threads underneath,
and forum channels are treeheads for posts which are simply
another grouping system for messages.
Regular users can start a new thread under a channel, or a new "post"
[effectively another sequence of messages] within a forum.
The result is largely the same.
New channels or forums themselves need elevated permissions to
create in the first place, which an administrator generally wants to name
in a way to imply general areas of discussion interest.
Here's a real kicker, though:
with either "create threads" permission, any user can
turn ANY normal channel message into a new thread, including those of
other users!
This is evidently by design, to allow everyone to corral long discussions in
a separate space.
But in some contexts that seems completely crazy, and could really screw up
the flow of a normal channel where threads aren't expected.
The only way to disable that is to deny "create public/private threads"
generally and reserve that structure-building ability for admins.
Forums, on the other hand, do not have this problem -- users must create
whole new post chains up front, rather than disrupting prior conversations.
The "send messages in threads" role permission governs the ability to add a message to *either* an existing thread or forum-post. Ironically, without the "send in threads" permission, a user can start a new forum post or thread and then immediately not be able to post anything more into it -- including their original starting message! And the error text is bogus. |
|
| Stuck! Can't post to my own new thread |
| [This doesn't even make sense, as this wasn't an attempt to send a DM but simply post in a thread.] This is further evidence that threads and forums are largely the same underlying mechanism, but with minor inconsistencies. They're not fully independent, though. Threads and posts themselves have no permission overrides -- they inherit everything from the head channel, so if you need a conversation to be private, it has to go in its own tree with suitable starting permissions. For even more confusion, there are also channel-level overrides for "create posts" and "send messages in posts" applicable only to forum-type channels, which don't show up anywhere else such as in general role permissions. What are they actually for, and what's the relationship to the analog in thread-specific permissions? Maybe Discord will get these UX/permission behaviors more in line with each other someday. During this transition period it's pretty clear that forums are likely a more developed version of the threads model, and we can see frequent crossover of the nomenclature in the user interface. Here's a right-click on a forum post, and it's talking about "thread ID". |
|
| Forum posts another form of "thread"?? |
|
Thread visibility in also kind of confusing, and may behave differently
in different user clients.
New threads don't just show up in the lefthand list for everybody, only a
pointer gets dropped in the head channel and a user has to go chase that to
read the content and/or join the thread.
This is a great way to actually lose track of conversations -- force
everyone to go digging for them and do some manual step to "join" or "follow"
if they want to see updates.
Inactive threads and posts generally won't show up in an individual user's
subscribed list either, unless new traffic occurs and they go active
again.
Any user with appropriate "send messages in threads" permission can perform
any of these actions to re-activate an old thread or post:
That last one is interesting: even the act of setting an individual "unread" marker somewhere in a closed item will implicitly re-open it, causing it to reappear for all other users still subscribed to it. What and/or when that happens in such cases seems to vary somewhat based on Discord client and caching, at least as of this writing. Threads and posts can also be viewed passively, by simply visiting one from the pop-up list. If nobody has joined or followed the given item, visiting it in this way shows no right-hand user list column at all! It's thus easy to read these items in "stealth", without cluing others in that you're viewing the content. Just don't post or set an "unread" marker and re-open the item for everyone. Threads and forums really break the built-in search mechanism. It is often useful to use the "in:" construct to confine a search to one channel, but this luxury is not available within individual threads or forum-posts. The only referenceable entity is the head channel or forum, which brings up results from *everything* underneath it. Less useful in many situations, especially as busy channel content builds up. Once a user creates a new thread, they cannot delete it, even if they delete their original sent message first. On the other hand, if a forum post has no content other than the user's original message or nothing at all, the user can delete the whole thing -- but not if any additional content has been added since. All they can then do with either of these items, as the original "owner" of it, is close it and make it go dormant for others. Some Discord bots cannot see inside threads or forums yet, so common bot functions such as auto-moderation can't necessarily be expected to work in those areas at all. A simple text-trigger function will probably work fine in a head channel, but may not in threads underneath it -- because the bot isn't "subscribed" to those threads and doesn't see events inside, or appear in the subscribed list when the item is viewed. According to this exchange, a bot has to upgrade to using the "v9" Discord API to receive events in those sub-channels. Even with that, the UX at the bot configuration portal may not be able to select threads or forums as specific places to operate in. That is probably why Discord has been offering its own moderation apps, even if they may not be as configurable or programmable as other time-tested popular bots. Presumably these are more thread/forum aware than the third-party bots -- this remains to be investigated. Bots are also unlikely to be able to send logging to a thread or forum-post, as those don't show up in configuration drop-down selectors at the bot portal. It's best to create a "real channel" for that sort of thing. Another thing to be aware of is that threads and forums created within a server do NOT get copied into server templates, at least at this time. As that is user-generated content despite behaving very much like channels, only base channel structure and permissions get saved. Forum treeheads don't show up at all in a cloned server. Again, these facilities within Discord are still under development, so this is only a snapshot in time of how things work [or don't] at this moment. It would not surprise me if "threads" eventually becomes deprecated, since it seems to be fairly badly implemented, and Discord should pride itself on *not* being too much like Slack. For a very broad spectrum of topics, the forums mechanism works more in keeping with typical blog sites. Most servers are more focused, and can run fine on a handful of ordinary topically-named channels. Frankly, I find a short chain of replied-to messages within a normal channel easier to follow and see context around than being shunted off to a completely separate place. This investigation is probably not going to make *me* any less likely to categorically prohibit use of threads and forums completely in servers I spin up, unless it's for some very particular context that could benefit from them. I'd rather allow for a little topical "channel bloat", than lead people astray into a forest of obscure rabbit-holes. |