Slack will delete chats and files from free workspaces at end of August. Slackdump is even better than Slack's built-in export feature because it works without admin access and downloads attachments (e.g. images) in addition to messages. Exports can be browsed offline or loaded into Discord or Mattermost.
After trying some other tools/scripts to export/archive Slack, I was amazed how well Slackdump worked.
Huh. Files I understand, but text is so small--it always seemed like such a clever carrot to dangle in front of people, at a cost of practically nothing. "All of this history could be yours."
We've used https://www.linen.dev/ to preserve history for our community. It's nice because it makes the contents searchable and let's us not worry about slack deleting data.
I would remind all the people to recompile the build themself, before downloading a random binary and allowing it to access the Slack workspace. But, very interesting project!
I’m honestly surprised there aren’t way way more… extremely nefarious straight up trojan data exfil builds out there of all kinds of rando tools posted as like “hey here’s a convenience build I got to compile for toy arch | codesigned for macOS | helpful VM or Docker image | did something sneaky to bypass API rate limits | fixes that one annoying thing YMMV” etc. and posted as comments on HN or anywhere by seemingly helpful nerds, with the web server serving up the evil build 5% of the time or GeoIP’d to the Bay Area.
Like it seems like such easy low effort “hacking” why isn’t it more common?
Hell even GitHub “Releases” on your fork can also just not match the repo.
Well. I can’t use this at work. But what I really need is not even to export the messages themselves.
I just want to save a list of all my channels, and the categories I’ve put them in.
Anyone know a way to do that, using either just Slack itself, or some specific tool that is only about managing followed channels and the categories you’ve grouped them into?
Slackdump also has a mode that exports a list of channels. Not sure about category groupings. You could also screenshot/OCR or copy and paste from the browser?
Some paid Slack plans allow exports from their platform. Inside the ZIP, there will be an XML file that lists the channels - channels.xml, if I am not mistaken. However, I don‘t know about „categories“ - this could be some client configuration that actually is not part of the export. If it‘s not, I would perhaps take screenshots (overlapping is OK), and feed it to some LLM/VLM for extraction. I am confident that GPT-4o or Claude 3.5 Sonnet will work, but Gemini 1.5 Pro should also work.
Hm yeah true. I use the desktop app and sometimes I forget that it’s all Electron and that they also have a web version you can use in the browser as well. Thanks, that should be doable :)
The web version is amazing for scripting stuff. I used it to download all the emojis one time, just from the console. So easy to automate just from in there.
So if you can do this, could you "reverse" it when you're done dumping messages and use API to repost them all to slack again? This way you could cycle channels every expirationperiod and have infinite slack retention on a free plan. Only downside is each cycle gets larger as it has (N+1)*90 days worth of data.
The problem is, as always, that the value people take out of these systems is not inherent to the system itself but rather to the people on it.
Moving 100s of people out of a certain Slack server to a different chat system may prove untenable or outright impossible.
Doing that for a few Slack servers, especially ones where you're just another regular user, would likely be a full-time job, and a fool's errand at that.
yes but IRC was made for a different era and failed to modernize. Now, if you want to take a bunch of plugins and specific clients on top of baseline IRC so it's actually competitive then you'd want to call it something new. something that accounts for the matrix of options available to users. hmm.
Let me generalize this thread because it was archetypical.
#1: Much used, leading service went down the enshittification route. If we did this extremely convoluted geeky hack everything would be back to normal (it wouldn't).
#2: Let's use another service.
#3 and on: yes, here are other services which no one aside from statistical error uses.
Sigh.
Remember when people suggested to use Lemmy instead of Reddit?
You might ask, what's the point of this comment. Well, it's to get people to read https://pluralistic.net/ more and for the geeks to start unionizing before it's too late (it already is).
A few Reddit communities moved to Lemmy successfully. The key was that the community leader decisively said "We are moving there. No more posting here." and people who wanted to remain in the community did so. Another important factor is that people wanted to remain in the community - it wasn't just slop content for scrolling past, that no one missed.
I used to really dislike Cory Doctorow back in the BoingBoing days, but he's really putting out some great stuff lately. I'm not sure which of us changed.
Particularly nice that the top article right now is a takedown of a company that screwed me over, so I might also be biased.
The default export will download the text of all the messages, but it won't download any attached images (it will just have links to them). This tool doesn't export the whole history but it does export the attachments.
I think it might! Despite the Slack interface not showing messages older than 30 days, the official Slack export (even on the free tier) exports all messages. Slackdump might have similar access (didn't try).
It unfortunately does not. I just tried. It only has the last 90 days. You'll need to upgrade, export, then downgrade to get the full history plus the attachments.
I always wonder why people write such projects with Go, I understand the performance benefits but I don't see it in this use case, and it's such a verbose language.
There’s a ton of acceptable reasons for it, and many of them have nothing to do with the relative fitness of Go to the task.
A couple easy-to-reach-for examples are: the author could write this faster in Go than another language, because of their familiarity; or the author deliberately wrote it in a language to learn something new or try something.
I understand, it's just that I often see projects that are a natural fit for a scripting language written in Go, specifically, it's rarer with Rust even. I wonder why that is.
To me go is a scripting language. Bash doesnt have great concurrency or type checking. When I was pulling some discord and slack it got real slow with curl and unmanageable with bash. Few hours later i was done with it in go and it was super fast
I often have to do similar at work where you could just bulk process say ALB access logs with bash into some simple stats, And it would work but in the time it took for bash to complete which was about 7 days per days of logs on the services that I was working on I was able to write go code that did it in a under 30 minutes for a day of logs. I was also able to easily make it where it output to parquet instead and then started pulling the data up in Jupiter notebooks and being able to get every stat I ever wanted as opposed to chucking away 99% of the data and bash. That was also able to keep my computer mostly active and maximizing bandwidth and CPU.
And if it's in go it's entirely portable cross-platform and I can build a compiler binary I can just hand the people to do the same thing. Scripting languages require a lot of environment set up and libraries and specifics that are not always true on other people's machines.
And finally as the other person said I'm actually just good at go so why would I learn bash or another scripting language that's actually not as good for this solution space
I think there's a lot of personal preference here, but for me "projects that are a natural fit for a scripting language" would be one-off 100-line scripts.
I think for a CLI tool such as this with 38 kloc and used by others, I'd personally be more productive using a strongly typed language (such as Rust) as the compiler will catch many mistakes before I run it.
But as I said, there's a lot of personal preference... I don't know how much that also applies to Go and you definitely could write this in Python if you wanted to (although I'd use mypy for maintainability).
I also agree with your parent, familiarity and just liking to use the language are big factors when choosing a language, even more for side projects.
After trying some other tools/scripts to export/archive Slack, I was amazed how well Slackdump worked.