Slackdump
github.com
github.com
After trying some other tools/scripts to export/archive Slack, I was amazed how well Slackdump worked.
Are you referring to some deprecation by Slack which affects all free users? Or is it just your 90d retention period elapsing at the end of August?
Before slack kept the messages and didn't let you see them, but you had rhe option to unlock by paying in future.
In August they will actually delete the data
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.
This is fine, or you have installed something bad and are about to give it your Slack credentials, and it's definitely not fine.
If you want to to this on an organization you need to impersonate every account from your domain(s).
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?
#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).
Particularly nice that the top article right now is a takedown of a company that screwed me over, so I might also be biased.
zulip's rather great tho.
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.
We have a free Slack server with 3k members, and buying some better license that’d let us export old messages is like $25k
1. Disable all the users except one
2. Buy a license for the one remaining user
3. Export all your messages
4. Downgrade back to the free plan
5. Enable all the users again
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 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 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.