Right now @data in a channel replies at top level, which floods the channel for any back-and-forth conversation. Threads keep the noise contained.
Change
In the direct-mention handler in app.js, pass thread_ts: message.thread_ts || message.ts to say(). If the user @-mentions Data inside an existing thread, the reply stays in that thread; if they @-mention at top level, a new thread starts.
Side effect to consider
The current handler explicitly drops messages with thread_ts set (likely to avoid Data replying to its own thread cascades). With the new behavior, Data should be willing to chat inside threads it started — needs a check like "thread_ts is set, but the root of the thread is a message Data replied to, so keep going."
Probably easiest: track which thread_ts values Data is "in" via Keyv with a short TTL, or just match message.parent_user_id === context.botUserId.
DMs are unaffected — they have no thread concept that matters.
Right now
@datain a channel replies at top level, which floods the channel for any back-and-forth conversation. Threads keep the noise contained.Change
In the direct-mention handler in
app.js, passthread_ts: message.thread_ts || message.tstosay(). If the user @-mentions Data inside an existing thread, the reply stays in that thread; if they @-mention at top level, a new thread starts.Side effect to consider
The current handler explicitly drops messages with
thread_tsset (likely to avoid Data replying to its own thread cascades). With the new behavior, Data should be willing to chat inside threads it started — needs a check like "thread_ts is set, but the root of the thread is a message Data replied to, so keep going."Probably easiest: track which
thread_tsvalues Data is "in" via Keyv with a short TTL, or just matchmessage.parent_user_id === context.botUserId.DMs are unaffected — they have no thread concept that matters.