Well, in general you can also ignore people on IRC, you can ban people from channels, and some IRCds support restricted DM permissions which require a user to share channels with you and be _validated_ to message you.

We don't have these sorts of controls in Slack because it's built to support companies with Human Resource departments. Communities like ours don't give the Slack shareholders value.

So in some ways it's worse than IRC.

>you can ban people from channels

Why not ban them completely and have a private appeal process? How often are people a nuisance in one channel yet valuable in another?

I see your point and it does make sense. But from an IRC perspective, most people/groups only care about a handful of channels. So you might have the #community or #support channel, and someone starts acting up. A channel operator can ban them from that channel directly. Alternatively, a lot of IRC "teams" maintain a bot to manage the channel. The bot can give someone a temporary channel ban (a timeout) based on keywords, or a mod in the channel might type something like "!ban userx because of rule 12" and that bot might ban that user from a list of managed channels.

That user is then still on the server, they can make their own channels or message admins directly. There might be an #ops channel where they can go and plead their case. If they annoy the admins or someone else that reports them to the admins, then they might get a server-wide ban.

A lot of this comes behavior from public irc servers. Channel operators can manage their channel however they desire, and if the users don't like it, they can start their own channel. But for an organization ran IRC server, a server wide ban is more possible. But in the case of say, Mozilla, there are all sorts of different groups running their own channel. So a group working on a mozilla labs project might just start a channel for that project, but not actually have server-ban privileges. So they can moderate their channel and perhaps request a server ban on someone, but that server ban might take hours to approve, or the bad actor might just go away.

Generally, channels are independently moderated. The moderation is done by someone in the channel, often just the person who started the channel.

The distributed moderation works well with large networks, because the people doing the moderation are in the channel reading it and keeping up with the conversation.

However, because the bar for becoming a channel operator is low, it's not a good idea to give full ban access to them.

More than you'd imagine. Someone may be strongly against a feature, library, or tool and their presence in a channel focused on that thing may not be ideal.

And yet, slack has seen exponential growth, while IRC was always available but rarely used.

We have seen this before and we will see it again. If OSS wants to be widely used, it needs to take UI seriously, and not dismiss it as frivolous “eye-candy”.

It’s ok so say ‘no, we are fine within our niche’. But then you don’t get to arrogantly explain to them how they are “taking one step forward, two back” by not embarking on the joyful journey of fiddling with config files.

> while IRC was always available but rarely used.

Freenode has about 85,000 people logged in right now and there's over 50,000 channels.

I'm in a bunch of tech related channels and there's hundreds (or 1,000+) people in most of them. It's still active and has been for 15+ years. Freenode is just 1 IRC network of many too but it's where a lot of tech channels are set up.

IRC is awesome. You can use it from a terminal (or get a GUI client that uses < 20MB of RAM), it opens instantly, you can connect to a bunch of channels and networks automatically (with password protection on your nick), typing feels instant and you get infinite log history. Doesn't get much better in my opinion.

You don't get the log history of what happened while you were offline, though. This is probably the killer feature of Slack over IRC, especially for professional use, together with more seamless attachment integration.

Don't get me wrong, I love IRC. I have been using it for over 20 years (wow, I'm old). I have met there very important people in my life. But I coordinate a team at work, we use Slack and I wouldn't even consider using IRC instead.

You can track logs if you want. It's up to the channel owner. Once you have that set up you won't miss anything, and people new to the channel could view previous history. You could also connect remotely through a server that never reboots too and log things yourself (as a client).

I find Slack to be even worse in that regard because they'll purge your history after 10,000 lines unless you pay, but the payment scheme doesn't make sense for a lot of communities. Like, whose going to pay $15/month per USER if you have 300 people in your channel? That would be $4,500 / month to get unlimited history right? I never signed up because I don't want to pay a mortgage to get chat history.

I dunno. I just don't see the appeal of Slack for both communities and small teams.

First off, the history is NOT purged. It's just not searchable beyond 10,000 messages. Pay for a month (if you can afford it!) and you'll see the entire history available. Further, the cost is $6.67/month -- substantially less that $15.

I'm not fan of Slack for large communities but, seriously, let's stick to facts when discussing the pros and cons.

Interesting. When I goto Slack's pricing page it shows me $15 / month per user (monthly, not annual). But if I goto the same page when logged out then it shows me $6.67 / month.

I'm a part of Slack for some large communities (not by choice but because it's where the organization wants to be), and every few months all of my private message history disappears and it tells me something about upgrading. It's not searchable, but it's also not in the back log either. It's 100% removed from the UI.

To me, that's not a good user experience, where you wake up one day and all of your important chat history is unavailable. It's even worse that it's still available but behind a paywall. So they hold your data hostage unless you pay that 1 month of fees. It's not about not being able to afford it. If you have a large community with 8,000 people, are you really going to spend $53,000+ to get your private messages which you only have access to for 1 month? Not even big companies with 100 million of funding have the paid plan. It might as well be purged even though technically it's not.

IRC is rarely used compared to Slack, with its 10 million users.

I used it daily for decades, but let's not forget netsplits, nick collisions, zero log history (without a bouncer, and then you need a place to run a bouncer!), no file-sharing in a NAT world (dcc stopped working a loooong time ago), and no integration with any other apps, and on and on.

Don't get me wrong, I wish there was an open-source project that built a big group chat system that worked as well as slack and discord do, but it's a joke to say that irc is better than slack.

Netsplits happen once in a blue moon nowadays (on freenode at least), nick collisions are also solved (you can register your nick on freenode and other networks), and you can totally set up logging on your channel and unlike Slack it won't disappear after 10,000 messages. You can also make it accessible through the web so people can easily see past history.

File transfers are definitely an issue over IRC but https://send.firefox.com/ solves that problem very well. For sharing code, there's gists (which I often send directly through my code editor which makes it seamless).

So, what client just allows you to join a channel and scroll up without having to learn the idiosyncrasies of a bot? Now, how do you search every channel on the instance?

I'm curious if someone has figured this out in the interm.

(My current hope lies in Mattermost, honestly.)

My chat logs are just plain text under ~/.weechat/logs and I search them using rip-grep. Works really fast. I am guessing a nicer interface like IRCCloud or TheLounge can work like Slack for searching, file/snippet hosting etc in a more approachable manner.

So, you come to a new job and join a channel that has been around for 2 years. Design decisions and discussions from 4 months ago with the old tech lead are there. Does weechat give you access to those logs?

No, not by default but if your organization uses IRC then it would be near guaranteed that whoever set up the IRC server will enable logging on all channels and then likely give you a web front end to it so you can easily read and search through all of the history.

In other words, yes, in any reasonable environment you would have access to everything ever said in any logged channel.

So, someone is tasked with building and maintaining a small part of what Slack provides as a service?

I agree to what nickjj said but hopefully decisions like that are not taken in chat but rather on a mail or an issue so it is documented.

>netsplits, nick collisions

It really sounds more like you used IRC daily decades ago.

> Freenode has about 85,000 people logged in right now and there's over 50,000 channels.

lol.

It seems a bit rich to be complaining about "fiddling with config files" when the alternative in this specific case is writing custom code against an undocumented API ;)

The difference is only a small number of users need to write that custom code, while with tools like IRC everyone needs to fiddle with config files.

There are plenty of easy to use GUI clients with no config files.

IRC has gigatons of clients because it is an open protocol. Some clients are even shareware/commercial. Same goes for servers and server admin interfaces.

IRC may have its shortcomings, but its worst defect, for the too many people that want to have fun while pretending to communicate, is that it is not "modern".

Its worst problem is the inability to request scrollback from the server. I don't understand why that extension wasn't written, like, 20 years ago.

You also need a "de facto official" client that includes a small list of default servers, and big friendly buttons for /JOIN and /PART - in fact the user should not be required to type a /COMMAND at any point.

Yes, I think this is fundamentally the main issue people have with IRC.

Some IRC users don’t like the idea of the channel being logged though? That’s the best I can come up with for an argument against it.

I think if you make it clear the channel is logged it's the best you can do, since they can choose to partake in the conversation or not. No forcing function. The downside comes when you've a Netsplit and you lose one side of the conversation.

It does surprise me that some people are supporters of open source, but aren't supporters of open and transparent communication. Seems like a miss.

I haven't seen netsplits since my teens and I'm 36.

they happen regularly on efnet, occasionally on freenode. Presumably they don't occur on mozilla irc since it's a single node?

If it is a public channel, then I think it should be logged. (People who do not want their messages logged should send them privately to the recipient instead; you can still use IRC for this).

A command for receiving the log may be helpful to have though as an optional extension.

I can't see why anyone would want that. If you weren't connected to the server then those lines were not sent to you. They're ephemeral. Ask someone to fill you in on what happened or send you a log.

Because chat is not ephemeral? It’s an asynchronous communication method like sms, im, email, and snail mail of old. When I send a text to a friend at 2am I don’t expect a response right then. I expect that their phone will be muted and they’ll see my message in the morning and then they can choose if and when to respond back.

This is how literally all my peers think.

It's definitely something that people have looked at, eg:

https://github.com/ircv3/ircv3-specifications/pull/292

There are IRC bouncers and Matrix bridges that can give you server history.

Why even call it "part"? The word everyone's familiar with is "leave". "part" is already an irc jargon.

it is perfectly valid english. E.g. "to part ways".

> for the too many people that want to have fun while pretending to communicate

It's exactly this kind of flippant dismissal that is why IRC is dying, because there are too many people who equate modernity with frivolity. That is, unless our requirements strictly adhere to your arbitrarily-defined notions of that which has merit, our voices are left unheard.

And IRC's greatest defenders wonder why everybody jumps ship.

Whereas, for the rest of us, we just want the same features I've been using on other platforms not just since the rise of Slack, Discord and its ilk, but other platforms besides, both before and after the rise of Web 2.0 and social media.

I find it pretentious that anybody could consider the following features "having fun while pretending to communicate", showing their profound lack of understanding for what communication can, perhaps should, be:

- the ability to modify one's own messages

- the ability to delete one's own message, and have that deletion propagated

- the ability to delete other peoples' messages, and have that deletion propagated

- simple but flexible role-based permissions systems that can be defined on a per-community basis

- collections of text channels in one community/guild/server that can be ordered, and that ordering propagated and standardised for all participants in that community (for the sake of consistency)

- usernames and nicknames that don't collide, using a normally-hidden primary key for each user that is associated with an account rather than ever-changing hostmasks that can be hidden, making bans and ignores ineffectual

- automatically-created community-based moderation logs

- the ability to create private group discussions without needing to create a text channel

- the ability for all participants in the community to see messages in the same format, including code blocks with syntax highlighting, images, video links, and web embeds

- a contacts list that travels across sessions, regardless of client, sign-in location, etc., and associated direct message history

- the ability to read missed messages while offline without needing to set up a bouncer (either necessitating a home computer be left on all the time AND be accessible via the web, not always practical; or every individual user paying for a bouncer, something that should be considered vastly unnecessary)

- everything just working

Instead of thinking "everybody just wants to send silly emojis and video chat, what a waste of time", the IRC crowd would do well to listen to what people actually want, need, and have come to expect from online communication, rather than derisively and condescendingly covering their eyes and putting their fingers in their ears.

>the ability to modify one's own messages

>- the ability to delete one's own message, and have that deletion propagated

> - the ability to delete other peoples' messages, and have that deletion propagated

These 1) don’t work when you need them too and 2) are very much antifeatures

I’ve been in slack and discourd channels with important people who will post things that cause me to make some decision and then will go back and delete or edit their message. It’s gotten to the point where whenever these people post to slack I always take a screenshot. On discourd you can just use finch and all the edits show up as new messages.

I really liked how on IRC you just sent messages and that was the end of it.

>- everything just working

Hah, that would describe IRC better than discourd IMO. Slack “works” but good god is it slow.

> These 1) don't work when you need them too

They don't? They work perfectly fine for me and always have. Citation needed.

> 2) are very much antifeatures

According to whom?

People use and profit from these features all day, every day on Slack and Discord. Whether you put any stock into them doesn't make any difference: they are features for a vast number of people other than yourself, they are definitely features.

> I really liked how on IRC you just sent messages and that was the end of it

I did, until I realised I and other people didn't have to spam the text channel with minor corrections to spelling, grammar, and markdown formatting with further messages containing the edits — and those messages may themselves contain errors, necessitating further ex post facto editing with more new lines.

> that would describe IRC better than discourd IMO

The day I can log into any IRC client, web or otherwise, without having had to set up my own bouncer and leave it running at home exposed to the internet or pay for a server, and it negotiates my IRC capabilities, joins all my channels, re-opens my private messages, shows me my chat history, and gives me a scrollback of the messages I've missed since my last session, I might be inclined to agree.

Not to mention what happens if I typically connect to multiple servers.

Until I am no longer forced to use such ugly workarounds to what should be simple session management that practically every other chat service has figured out, even before Discord and Slack, I don't consider IRC to 'just work' except in the sense that, yes, a non-negligible number of people have managed to get their fragile IRC configurations working just-so, likely on only one machine — good for them, but I have higher standards.

> People use and profit from these features all day, every day on Slack and Discord. Whether you put any stock into them doesn't make any difference

You have totally missed the point of what I said. I know some people want them and it's nice to be able to correct your "there" to "their." That's fantastic, good for them.

My complaint is that these features are abused by nasty people who you end up having to work with. By not having them they can't be abused. When I can't trust software running on my own machines to accurately tell me what someone said yesterday that's unacceptable. I'd rather the thing not work at all than give me bad data.

And I don't think there's any bigger work around than having to screenshot an app every time certain people send you a message.

> My complaint is these features are abused by nasty people who you end up having to work with

I mean, not being able to edit or remove messages, by one's own and those of others in the case of a moderator, can be just as susceptible to abuse.

Abusive messages not being able to be removed, potentially and needlessly staying in front of hundreds or thousands of users' eyes is one issue I can come up with off the top of my head. Especially true for IRC clients that provide image previews for posted spam links if those links contain disturbing content (and no, it's not a reasonable response to expect people to turn those off; people can enjoy media the way they want, not just the way you deem fit).

> When I can't trust software running on my own machines to accurately tell me what someone said yesterday that's unacceptable

Just as well Discord, Slack, and others put a little "(edited)" annotation next to edited messages. Plus, one can only edit one's own messages; moderators cannot edit other peoples' messages as they can on forums.

> I don't think there's any bigger work around than having to screenshot an app every time certain people send you a message

Bots can log messages, including message editing and deletion events. If your preferred Discord/Slack server provides a public log, that sorts that out; if it's your own Discord/Slack server, you can provide your own bot. These can be as simple as 20 lines of Python, maybe less. I'm sure services like Mattermost, which seems to be the top open Slack clone, would facilitate these features more easily.

I would imagine Mozilla would keep logs. Further, Discord also automatically provides a moderation log to keep a history of all those events.

It really sounds like you're inventing to do with software with which you've little experience.

> people can enjoy media the way they want, not just the way you deem fit

Unless the official client doesn't support it of course. (showing edits as new messages is a great example of this.)

And I'm not saying they shouldn't be allowed to enjoy that, but everything has trade offs and automatically opening links from strangers certainly has a lot of those.

>Just as well Discord, Slack, and others put a little "(edited)" annotation next to edited messages. Plus, one can only edit one's own messages; moderators cannot edit other peoples' messages as they can on forums.

I'm well aware of that, it still doesn't help me when I need to see the original version of the message.

> Bots can log messages,

Having to run personal bots is one of the arguments you've made against IRC. Furthermore, it's often not allowed.

> If your preferred Discord/Slack server

If I could pick the server most of my problems would go away.

>It really sounds like you're inventing to do with software with which you've little experience.

I have less experience with it than IRC, when I used to use IRC it was voluntary because it was actually pleasant. I never use slack, discord, or lync/skype voluntarily, but I've been forced to use all three by various organizations.

I agree that it doesn't work and is antifeatures. I also like that on IRC you can just sent messages and there it is. You can have public logs, possibly server side logs (although as far as I know, implementations of this aren't common, but this is easily possible without altering the protocol or clients at all); private messages would not be logged though, so if you wish to remain private you should send the message private instead (the server administrator should not look at private messages either, unless the message is addressed to them). Messages that you do not like, you can filter out on the client side (if the operator can provide a default filter file for uses who do not want to see everything or to customize it, that could also do; however, (public) messages should probably still be stored except that you do not have unlimited disk space, so you will have to avoid some anyways).

> You can have public logs

You could equally have public logs in Discord and/or Slack. At least on Discord, this can be achieved through a bot — which, if logging is the aim, could be a very simple 20-line Python script.

> - the ability to delete one's own message, and have that deletion propagated > - the ability to delete other peoples' messages, and have that deletion propagated

That means you are asking for control over other people's computers and what information they are allowed to display, i.e. DRM. It is also a falsification of history.

> - the ability for all participants in the community to see messages in the same format, including code blocks with syntax highlighting, images, video links, and web embeds

That excludes people with text interfaces.

I'm not sure about the delete other peoples messages, and have that deletion propagated, but having the possibility of deciding over own messages it's basic and desirable, in my opinion.

I've just used such a feature less than 2 hours ago, in Whatsapp. Published a secret in the wrong group, by mistake. That's the whole point of allowing editions or deletions of one's own contents: humans are fallible, and shit happens.

>I've just used such a feature less than 2 hours ago, in Whatsapp. Published a secret in the wrong group, by mistake.

By this time, it's too late, anybody could have seen it, copied it, etc.

Deleting it after the fact is security theater.

The "secret" (a link to another private whatsapp group to which not everybody should enter, just for easiness of organizational purposes in an event, so not much of a critical secret) was reportedly seen by around 5 people out of 200 in the group. No one of them bothered, if they did it would mean just a bit of explanation and taking them out of the new group. By all means, being able to quickly make a correction was not too late and was not security theater. Your position is that of "if we cannot solve 100% of a problem, there is no use to solving 95%" which is clearly a false dichotomy. There is value on editing or deleting messages after the fact of sending them.

Case in point, I just edited this message to change all "_" to "*" to make italics work. That's another use: fixing wrong assumptions about usage of technology itself.

>Your position is that of _if we cannot solve 100% of a problem, there is no use to solving 95%_ which is clearly a false dichotomy.

No, my position is that if 5% of a problem (5 out of 100 people seeing it) is equally catastrophic as 100%, then it makes no sense to differentiate, which is a very true dichotomy.

The fact that just 1 person that's not supposed to see it seeing it can do damage, makes the problem a binary and not a spectrum.

I agree for catastrophic mistakes. It doesn't mean the feature is rendered useless for the non catastrophic ones.

Which one occurs more often than the other, that's another question, but I'd argue that the later is more common, and there is no doubt that people knew, in the event they wrote a very catastrophic secret, the limitations of the edition/deletion of messages (as long as most people nowadays seem to know about screenshots being a thing)

The issue is that zapzupnz deletions to propagate. This can only be ensured in locked-down systems.

There's a difference between offering corrections and retractions that others may or may not accept and actually enforcing deletions. This is both socially and information-theoretically true.

All I said is that the deletions should be propagated. The presentation of this can only be ensured in locked-down systems, but the actual propagation is simple enough. Just as the server can send all users within a channel "so-and-so said this message", it can say "so-and-so deleted this message" — it can be left up to the client whether to actually remove it or perhaps just hide it, ready to be shown again with a click.

Obviously on Discord, one is tied to the official client's behaviour since the ToS discourages third party clients. However, for Slack, Mattermost, Matrix etc. clients, the possibilities widen up.

Ah, I read "deletion" as the actual effect, not the request for the action to be performed.

So this is not a secret anymore. The only reasonable solution for such a mistake is to revoke the exposed token. If it is not easy to do then it is negligence of WhatsApp UX team. Your "let's pretend you didn't receive this" deletion message may have failed to propagate to some or all of the recipients, including that one guy that likes to mess things up

Also with WhatsApp going through my notification demon on my desktop the secret would not actually be deleted ever.

(Same for tweets etc.)

That secret is still out there, it should be modified.

This is a false sense of security.

Is it DRM when a moderator deletes a post on a phpBB forum? Or does it only count when it's on Slack?

If a complete copy of all messages sent were on your computer and the administrator had the ability to delete this data from your computer whenever they want, I consider that to be an infringement on the control I expect of my own computer. On the other hand, the contents a phpBB forum (or even HN) are stored on someone else’s computer and no one has the ability to arbitrarily delete stuff that I’ve downloaded.

> an infringement on the control I expect of my own computer

How is it an infringement? The server saying 'so-and-so sent a message, here it is' is exactly no different to the server saying 'so-and-so deleted their message, get rid of it'.

You can always take logs

> On the other hand, the contents of a phpBB forum (or even HN) are stored on someone else's computer and nobody has the ability to arbitrarily delete stuff that I've downloaded

Yet, when you consult that forum, you're in the exact same position as you would be with Discord after someone has deleted a message — you cannot consult that content anymore unless you've explicitly backed it up (in the case of Discord, made your own log; in the case of a forum, downloaded or archived the relevant site elements).

> I find it pretentious that anybody could consider the following features "having fun while pretending to communicate"

straw-man argument. Nobody considers these things to be frivolous. I would consider slack's annoying gifs and discord's extensive emoji to be frivolous.

> the ability to modify one's own messages

Please, no. People editing their own messages later on is possibly the most annoying thing about slack and discord. Say something and move on, or append a message if you made a mistake.

> the ability for all participants in the community to see messages in the same format, including code blocks with syntax highlighting, images, video links, and web embeds

no thanks. what if I want to disable images, video links, and especially web embeds?

all -I- want from a client is a superset of markdown, like gfm, and code highlighting for most languages. and the ability to add syntax highlighting for other languages really easily.

all that IRC really needs is a few quality of life fixes like the history you mentioned. "collections of text channels" already exist... that's how IRC works. there's no reason for every single community to repeat similar sub channels.

> everything just working

I don't think I've ever had an issue with a web client not working.

> straw-man argument

Not at all a strawman argument. As I stated, there are a plethora of features in Slack, Discord, and its ilk that are most assuredly not "having fun while pretending to communicate". The whole point of my post is that one cannot so off-handedly dismiss an entire class of application.

If GP meant to be dismissive of GIFs and emoji, they can easily have said so. (That said, one can post standard Unicode emoji to IRC, and will anybody call that frivolous?)

> People editing their own messages later on is possibly the most annoying thing about slack and discord

I'm willing to imagine that some rather high percentage, perhaps in the 80s or 90s, is just people fixing spelling, incorrectly-entered Markdown formatting, or other kinds of minor reformatting.

I'll take this over people spamming the text channel with further edits (that may still contain other faults, necessitating more edits in further lines to come).

> what if I want to disable images, video links, and especially web embeds?

You can in Discord.

> "collections of text channels" already exist

No, they don't. Channels have no groupings with others within one IRC server. You can't guarantee that a given set of channels on a similar topic have the same owner, same rules, etc. Joining a channel also doesn't automatically join you to another set of channels within that channel's group.

The flexibility of channel groups is not replicated in IRC.

> I don't think I've ever had an issue with a web client not working

So you can use any web client and, with only entering your username and nickserv password, any web client (A) knows what channels to connect you to, (B) what to set as your nickname, (C) how to handle a nickname collision, (D) set up your IRC capabilities all without any further configuration on your part?

'cos that's what people expect, that's what "just working" means. No config every time I encounter a new machine, no having to run a bouncer or screen session on some server in some godforsaken data centre and thus limit myself to terminal-based clients just to keep my connection details consistent across sessions, etc.

> If GP meant to be dismissive of GIFs and emoji, they can easily have said so. (That said, one can post standard Unicode emoji to IRC, and will anybody call that frivolous?)

OP confirms. But that's the tip of the iceberg. Yes, you can use Unicode in IRC, and yes, people will kick you out if you "misuse" it - but perhaps I've been on weird channels.

> incorrectly-entered Markdown formatting, or other kinds of minor reformatting.

I don't know what you are talking about. Markdown in IRC? IRC was (one of) the electronic ersatz for verbal dialogue before VoIP. Chat messages shouldn't be longer than a tweet.

If you need formatting then you're writing a document, not chatting. There we agree you need another service for that. Something like Pastebin would probably be more suited.

However if you are writing something that people should remember or use as a reference, I'd suggest to use a CMS rather than a chat or IM or even email, because sooner or later you'll be sorry otherwise. Especially if your chat platform of choice keeps everything on servers that are not under your control and doesn't offer full client-side backup. Good communication starts with choosing the appropriate tool.

In my opinion it should be updated with the times. I find myself writing multiple lines quite often, especially if I'm answering a question. Note that this doesn't prevent anyone from sending single line messages like usual, without markdown.

Forums are a totally different medium and I'm not interested in them at all these days. In the Korean discord I'm in, I can ask a question and get a response very promptly because it's just a chat. Sometimes this leads to questions being repeated, but I'll take that over a traditional forum any day.

Slack gifs ARE annoying, I don't see how they're not. Discord emoji is fine. Anyway, my point was that the comment I replied to constructed a strawman. When IRC people criticize slack or discord (or call them "frivolous"), it's not because of quality of life improvements like chat history, ease of use, etc.

> Markdown in IRC?

No, Markdown in Slack, Discord, etc.

> Chat messages shouldn't be longer than a tweet

Says who? You?

You're not the arbiter of how people should choose to communicate. Aside from that, there are good situations on Discord and Slack where messages tend to be longer, such as announcements, lists of rules, when posting code blocks, giving detailed explanations, etc.

> If you need formatting then you're writing a document, not chatting

Again, says who? People have had formatting in instant chat for years, in AIM, ICQ, Yahoo, MSN, etc. People can use formatting to provide emphasis, to separate code blocks, etc.

Even IRC supports basic bold text blocks.

> There we agree you need another service for that

No, we don't agree. Why should you need an external service for that? Why send people out of the discussion to an external website, a needless interruption of the flow?

There may be times when that's appropriate, but a chat service, something that's inherently about conversations and keeping things in context, no longer needs to mandate this. There are no technical restrictions to this as there were in the 80s and 90s. If people want to share a snippet in the conversation, they should, and now can, do so.

Same goes for images, videos, etc.

> Good communication starts with choosing the appropriate tool

People have found the appropriate tool, have flocked to it in droves, and are quite satisfied.

It's only old-fashioned IRC-clinging fuddy-duds who think there's still any question about this. Everybody else is getting on quite productively and happily.

> a contacts list that travels across sessions, regardless of client

Tell me exactly how use slack, directly (without bridges and stuff) without using the official client.

Get your session key that's embedded in the HTML body after you log in. Be careful with this key since it has no expiry and can impersonate you as if you were connected via the default client, including undocumented API access. Find some application that can connect to the Slack RTM API and provide a chat TUI, using the session key you extracted.

I know there are a few out there, but can't personally recommend one.

https://github.com/42wim/matterircd for example You can use your favorite irc client to connect with the ircd to talk to slack (of course it has almost the same limited irc issues)

That's...appealing.

This is quite close to what I would write as a parody to prove my point.

If you have to fiddle with config files to use irc, you're doing something wrong. Every client I ever used shipped with a list of networks, you basically just click the one you want, get asked for your nickname, click a button, enter channel name, all set for next time.

But if you want a TUI client that involves editing config files, it’s an option. I like being able to make that decision for myself.

To be fair, it is "frivolous eye-candy”. But that doesnt change the fact that you are not going to reach the people which rank eye candy higher then functionality.

Much of the eye candy is functional, not frivolous anyway.

This is the false dichotomy.

Being able to apply slight styling to text is better than wrapping words in asterisks or underlines. Adding reactions and emojis is better than using punctuation to simulate it.

It's really common to confuse "what I'm used to" with "what's better" and I think that's especially happening here.

In what world being able to read offline messages is "frivolous eye-candy"?

Sounds like a functionality to me

edit: sounded a bit impolite. I was trying to point out, that just covering all needed functionalities doesnt mean anyone will use your product. Frivolous eye candy, ie the appearance is a key aspect for quite a few people. The issue is not that its dismissed as eye candy, but that being eye candy is an important point to look out for.

I cannot fathom how people think that communicating in something other than pure text is eye-candy. A picture is worth 1000 words as they say.

Why would you want to reach those people? Avoiding them sounds like a feature!

It's the same kind of question like "Why would you want to hire people that don't want to do our algorithm puzzles/don't want to call themselves coding rockstars/don't have the same interests outside work". It's restricting the people you interact with along more or less arbitrary lines that are not a reliable indicator of quality/usefulness.

People like to frame it as "if they can't even figure out IRC", but that's a straw man. Nearly everyone can "figure out IRC", the question is if they want to bother with it when there's alternative things they could do.

(and I say that as someone who by far prefers IRC over every other group chat system)

> If OSS wants to be widely used, it needs to take UI seriously, and not dismiss it as frivolous “eye-candy”.

More than this, if mass-market OSS wants to be widely used, it needs a mass marketing budget. Not many deep-pocketed stakeholders in a community united around non-profit work.

Slack also has a marketing department.