Zarf Updates

A couple of months ago, you may recall, I wrote an open letter to Slack saying that they shouldn't shut down their IRC and XMPP gateways.

Slack sent me a nice reply saying that they had passed it along to their product team. I am sure that their product team read it, and nodded sympathetically, and then didn't change their minds. Slack is still shutting down those gateways on May 15th -- tomorrow.

This is not great, but I have a partial solution.

"...Holy beefwaffles, Zarf just wrote a Slack client?!" Yes! Sort of. Ish? I wrote a very small Slack client -- the most minimal app that could still be called an interactive Slack client.

Before I describe it, let me point out a few alternatives that already exist:

• slackcat: Post snippets to Slack from the command line.
• slack-term: A terminal-window Slack client.
• terminal-slack: Another terminal-window Slack client.

These are cool! They are not quite what I want. I want something that will sit in a terminal window and show all my favorite Slack channels -- just the important ones -- in chronological order. Yes, interleaved.

The point is that I never have to type in this window; I can just keep an eye on it. Conversations flow by. If I want to jump in, I can type a reply there (to any channel).

Of course, my client doesn't handle any of the fancy Slack features like threading, reactions, search, or file attachments. It's just a plain text stream. If I want to do anything more than that, I fire up the official Slack client and go to town.

This sounds like extra work. Okay, it is extra work. But I like having lightweight and heavyweight solutions to the same problem. I use three web browsers, for example, from plain-text Lynx up to full whiz-bang Javascript-enabled Safari.

---

But you're not here for my computer usage habits! You're here for the Slack client, so here's the repository. (Python3 code.)

The install procedure is a little bit annoying, because of the way Slack handles apps. You can't just distribute a Slack client as source code, because the client needs a Slack client ID, and those are supposed to be secret. Each user has to create their own client ID on Slack's developer page. (This is also true for the open-source alternatives I linked above.)

It's a hassle, but it just takes a couple of minutes and then you can fire up the client.

---

This is, obviously, both a work in progress and a work highly tuned to my own needs. I may extend it in the future. I may not. I may add personal features. ("Gag Slackbot" is high on my list.)

People are of course welcome to use it, modify it, and build on it. I may or may not accept pull requests -- see "highly tuned to my own needs".

Future directions? I am strongly tempted to throw away the current Python Slack API. It was handy, but it's not a good fit for what I'm doing; it tries to handle too much of the protocol. (There are internal lists of channels and users which I'm ignoring, because I handle that stuff myself. Admittedly, not very well!)

Also, my client uses both threads and asyncio. Yeah, the worst of both worlds. It's because the Slack API library (and its dependencies) are all blocking calls. I have to run that in a background thread, while the main thread is all async. If I wrote my own client API module, it would be pure async and then the whole thing would be much cleaner.

But, of course, what I've got works fine and further rewrites would just be faffing around.

Mm, faffing around. Very tempting.

Anyway, this is what I've got. Enjoy.