2-Way Slack Integration: Channel Watching & Signal Sharing

[Ethros19]

Overview

Phase 05 adds bidirectional Slack integration:

• Outbound: "Share to Slack" button on signal detail page posts a formatted Block Kit message with signal summary, themes, evidence count, and deep link back to Distill
• Inbound: Watch configured Slack channels and ingest messages as raw inputs for synthesis

Open Questions

These need community input before we plan the implementation:

1. Which channels should be watched?

• User-selected allowlist (admin picks specific channels)?
• All public channels with an opt-out list?
• Something else?

2. Should changelog/automated channels be excluded by default?

If a Slack channel is getting automated changelog notes, CI notifications, or bot messages — should those become synthesis inputs? Or should we exclude bot messages by default and let users opt in?

3. Inbound architecture: poll-based or event-based?

• Poll-based (Slack Web API): simpler setup, runs on a cron, but has rate limits and latency
• Event-based (Slack Events API / Socket Mode): real-time, but requires a publicly reachable endpoint or persistent socket connection

4. Should inbound messages be auto-processed or queued?

When a Slack message is ingested, should it go straight into the unprocessed inputs queue for the next synthesis? Or should there be a review step where an admin approves which messages become inputs?

Contributor Callout

If you have experience with Slack integrations (especially the Events API or Socket Mode), we would love your input on the architecture. This is a great phase for a community contribution.

See the Roadmap for full context.