This is very reminiscent of the initial hn response to DropBox [0]. This is like saying that you can build a Tesla clone by attaching 3 pieces of wood together along with 4 wheels.
Although it is technically cool, it misses practically all of what makes Slack so popular - UX.
>it misses practically all of what makes Slack so popular - UX
I strongly disagree. Slack has nearly the same UX as every chat platform of the past 2-3 decades. It's a slightly change over AOL Instant Messenger. There's also a large amount of very similar software or straight-up slack clones that are not very popular at all.
I would say what makes Slack so popular is how easy it is to set up and get running, both as a service and for every user, combined with the availability of easy integrations/plugins.
1. being connected to multiple communities and switching between them instantly
this can be of course simply replaced by connecting to different servers in a tabbed terminal and use the terminal's built-in cmd-1/2/... shortcut, which happens to be the same as in slack.
2. meta data about others, like their timezone or how to pronounce their name is quite important for distributed team work
this can be approximated by a world readable file on the chat server in every user's home, like .plan or motd files (https://github.com/ESWAT/john-carmack-plan-archive)
3. automatic idleness detection
im actually not sure how reliable is this even in slack, but in general, it can be useful, but im not sure how to solve it elegantly, when the chat runs remotely...
maybe we should just spawn a loop at the background, which gathers idleness status from the OS and uploads it when it changes, into world readable files and the remote clients can just check those file whenever they want.
4. extra status indication with automatic expiry, eg when someone is away from the keyboard, coz they are having lunch
we do use this feature often and it's a really helpful regarding when can we expect a response from someone.
again, quite simple to model this as a plain text file and we can even use emojis, to have a very similar effect to setting " lunch" on slack. ppl would need to know what's the emoji selector shortcut though... like cmd-ctrl-space on macos.
5. text search across all channels/rooms
assuming the chat is being logged into files, then a recursive (rip)grep could work to some extent, but then from the search results one might want to get back to the context of the result too.
6. threads
this complicates implementation a lot more, but we found it an obvious improvement over the single threaded IRC model of communication
7. having threads open on the side, so ppl can track 2 streams of comms at once at least
it would require starting the chat app multiple times and do some window management to see them side-by-side
now obviously all this can be done a lot simpler, but those implementations typically always lack somehow. not sure why is that...
see https://cancel.fm/ripcord/ or http://www.altme.com/what.html
the REBOL 3 programming language even had a quite full featured, text-mode chat built in: http://www.rebol.com/r3/docs/functions/chat.html !