This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # aws (6)
- # beginners (129)
- # calva (9)
- # cider (4)
- # cljs-dev (2)
- # clojure (41)
- # clojure-beijing (2)
- # clojure-dev (3)
- # clojure-spec (23)
- # clojure-uk (46)
- # clojurescript (38)
- # community-development (20)
- # core-async (4)
- # cursive (12)
- # data-science (7)
- # datascript (13)
- # datomic (15)
- # duct (11)
- # emacs (18)
- # figwheel-main (5)
- # fulcro (26)
- # off-topic (4)
- # pathom (28)
- # pedestal (3)
- # reagent (8)
- # reitit (6)
- # shadow-cljs (32)
- # specter (3)
@hmaurer Not really -- it requires knowing the timestamp of the message and is per-message, per-channel so we'd need something that searched for all messages from a given user, across all channels and then deleted them all one-by-one.
Yes, it is definitely possible for someone to write such a tool. I'm sure the Admins would love someone to volunteer to do that.
Right now, so far, it's still quicker to delete the messages manually in the channels that folks alert us to than to learn about Slack's API, develop, and debug tooling to do this sort of stuff. Of course, if a community member feels inclined to build such a clean up tool for the busy Admin team, I'm sure that wold be much appreciated.
@hmaurer I started a proposal for a bot that would allow community members to flag message with spam and at a certain threshold ban the user and delete all flagged messages. Ideas came from an earlier chat in this channel. Once I finish my current side project I should be able to get started unless others wish to help https://github.com/eccentric-j/cjl-slack-auto-mod/issues/1
@jayzawrotny ah! I was just thinking that would be cool. If commuinty members could “vote” on messages and, as you said, above a threshold of “trusted users” it would auto-delete them
You might want to also check if there is an API that would allow the bot to deactivate a member account as well.
Here's what currently happens when a spammer appears: 1. Someone notifies one or more Admins (via DM or via the #slack-help channel) 2. Admin looks to see who the spammer(s) is/are and deactivates their account(s) -- this is currently a manual task that often involves downloading the entire current membership as a CSV and looking at recent accounts signups (I'll clarify why in the next message) 3. Admin goes into each channel where the spammer(s) posted and manually deletes each message (and usually the rather pointless interactions other members have tried to have with them). (same issues as #2 above apply here) 4. Admin goes into the files section and manually deletes each file uploaded by the spammer(s) -- this is typically easier since files are shown most recent first and it's clear which ones are not code fragments 😐
So, why do we have to look at the CSV file? Because the spammers often try to impersonate other members or use very short nicknames that are hard to search for in the Slack UI/Admin console. For privacy/identity reasons, we don't expose members' email addresses here, so the only place they show up is in the CSV file -- and spammers often use specific dodgy email domains.
This is also what makes finding and deleting messages hard: if they're impersonating another member, or changing their nickname regularly, using their nickname to search within the UI is ineffective. Also, not all Admins are in all channels, so we often need to be told of spammers posting in channels where we're not present (although this is usually contained to the channels that everyone auto-joins -- but not always).
One of the last rounds of spam came from a member with the nickname
b as I recall -- impossible to search for in Slack's UI since it matches every nickname or real name that contains a word starting with
Deactivation of the spammer account is key: the very first thing we need to do is shut them off. Kicking them out of channels doesn't work, they immediately rejoin. Deleting their messages and files is pointless if their account is still active so they can keep posting.
I like fleshing out what the ideal behaviors are then figuring out how to implement it. If the API doesn’t support deactivation, we may be able to be script it using something like codeceptjs + puppeteer to start a headless browser.