As an admin helping out the Go Slack workspace, which is about to cross 39,500 registered users, they would be ill-advised to go with Slack if moderation is one of their goals. Full disclosure: our Workspakce does have some sort of agreement with Slack, so our space isn't a free space (we have full history), and even then we aren't able to get them to provide support around moderation of users.
There is no mechanism to ignore a user, mute a user, or temporarily suspend a user if they need a timeout. The first two are completely impossible, while the latter today is manual / mostly possible using undocumented APIs and mechanizing of HTTP requests. Users reporting spam is done by them sending a message to an admin, or in the admin channel, and requires someone to manually intervene and moderate the message. So we effectively need to aim for follow-the-sun moderator coverage, which is a bit painful.
In terms of usability and accessibility, some of the things Slack does (e.g., threads) are not super-inclusive or accessible to users who use screen readers. Today, based on feedback I've gotten, IRC is still superior for users who rely on screen readers due to some form of visual impairment.
Whichever product they go with, it'd be nice if they provided an authenticated IRC gateway which would allow this class of user to have a better experience using the platform as they could use one of the text-based IRC clients that has served them well.
For everyone who is saying they hope Slack isn't the choice, I'm fairly confident with these issues today they won't pursue Slack. If anyone from Mozilla, or any other org, would like to discuss some of the challenges we've had using Slack as an open community I'm more than happy to schedule time. I'd like to help you provide the best experience and community for your users.
I can't fathom open source projects and communities using slack as a communication platform. I like slack, it's a great product for business, where you can pay $X for each user in your org.
However, OS and non-profit communities quickly run into the history issue. There is no way that some of the communities I'm part of on Slack could pay for all the users. For example, the "Maker's Kitchen" slack has 1500-2000 people.
How much information and knowledge is lost and questions re-asked?
As I mentioned, in our community we have some deal with Slack so that we are paid (up to a point) and have full message history retention. Search can also go through all of those messages too. This is extremely valuable, and is a selling point for Slack if you can somehow get on to a paid plan without breaking the bank.
But in my experience, many don't use the search anyhow. :P
I'll admit, I don't know the full details of the relationship we have with Slack as I'm just an admin and not an owner. It is paid for by someone, but I don't know how much we're paying per head or of it's a flat rate.
If people aren't using search, then message history retention isn't that important for you it seems. I would suggest that maybe your people are using email in situations where they'd like more permanence.
This is common, and Slack is treated more like a hallway conversation. Hallway conversations are enormously valuable, but if you want a record of something or if you want to make sure it reaches everyone, you use email instead.
It is to me personally, as I use it to find answers to questions I don't know the answer to. At a minimum, I can point them to someone who had a similar problem in case they solved it.
Yeah I feel the same as you. So much knowledge gets shared on Slack that searching the complete history is often really valuable.
I even went a step further and built a product that would generate FAQs from slack history and made it easy for people to add and categorize knowledge from Slack to provide answers to questions, metric, etc...
I would love to have open source communities use it for free if helped them manage supporting their communities easier.
It's https://landria.io. Would love to know if it would be useful for you.
I thought IRC didn’t have message history either? I’m not saying Slack is good for open-source communities, but it seems like “not having history” would be the status quo.
IRC doesn’t have its own message history but most servers publish archives. You’d still need your client to load up archives for when you were offline if you wanted to see missed messages online. Otherwise you would have to look at the archive separately.
Kubernetes also had (has?) pretty major issues with these, but a community member built some tools using what APIs they do have to make the moderation aspects easier at least: https://github.com/kubernetes-sigs/slack-infra
As I understand it, to support things like timed bans your only options are undocumented APIs which can change at any point in time. So while some things are documented and possible, not everything is and that's not the level of support we need.
To be clear: NOT recommending Slack. Just mentioning that we also have issues and some tooling has helped, the tools could use more docs but they're pretty simple and open source FWIW.
Still, installing those open source tools in the Go Slack and collaborating with Kubernetes over them seems better that just live with whatever Slack offers today.
As others have said, Slack is fine for businesses that can afford its extra features, and it's "good enough" for a small business with less need for search history and more of a "run anywhere" instant communication platform.
But I agree with the sentiment that it's not a good fit for open source projects. For that, an open source Slack-like tool like Mattermost or similar would be a better idea.
That’s the only one I mentioned that I haven’t used. I just figured it’s open source, so it’s more suitable than Slack or Hipchat. Thanks for the feedback, won’t be going out of my way to try Mattermost.
I think we need to be explicit, Slack isn't always conducive to the needs of open communities. Some of its features are extremely friendly to users, like having the possibility of full message history retention and mobile apps. But the former does require you be paid, and the latter is also possible with other solutions.
On the user side of things, I work at a large academic institution where I occasionally get unwanted contact (overly invasive, won’t stop messaging even when asked).
I totally get that at an office workspace, the solution here is HR. But this is a loosely federated place, and even in my own opinion the conduct doesn’t merit such a response. I just want to be able to mute people.
Slack's refusal to add a "block user" option is beyond frustrating. Short of the nuclear option of disabling the account, there is no way to prevent a bad actor from pestering you. Yet this condition seems to be a deliberate choice of Slack's.
True story: at a former employer, a colleague made an HR complaint that in reality was well founded due to abuse. At one point in the investigation, HR told the two people not to interact with each other directly, but for unavoidable work reasons they were still in the same team-related Slack channel.
A mute or ignore feature would have been great to lower the victim's anxiety level during that time due to HR's unhelpful handling of the situation. The victim's finances and general life circumstances did not make "just quit" a good resolution.
(Oh, and the end result: HR fired the victim, with some severance paid, and kept the abuser a while longer. The abuser eventually got fired but probably not due to this incident.)
I recently evaluated a number of options. I was surprised to realize discord has by far the best moderation / permission / access conctrol management. Plus unlimited webhook and boy support.
So it sounds like regarding moderation, slack is at best on par with irc. And while on orc you can pretty much script and automate anything you want to facilitate the moderation job, with slack you're at the mercy of having some documented or undocumented api call available? One step forwards and two steps back...
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.
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.
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 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.
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 ;)
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.
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.
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.
> 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
- 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 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.
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 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
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.
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.
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
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.
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.
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.
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)
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.
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.
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.
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.
It's not hugely surprising that Slack lacks spam/moderation tools. Their target market is companies, where "I'm your boss, please stop doing that" is usually sufficient!
I'm an admin on the Clojurians Slack workspace where we have about 15,000 members, of whom about 1,400 or so are considered "active" for Slack's purpose -- which is still an unaffordable amount for an open source community. Over the years since we created the Clojurians Slack, we've tried to create communities on a broad range of alternatives. None of the others have gained traction, unfortunately. I think Zulip is probably the best alternative and it offers a free option for open source projects with full history/searching, and that's probably been the most successful alternative so far. Clojure's community on IRC was in the hundreds. Slack very quickly became thousands. It surprised us. The fact that none of the alternatives have grown has also surprised us but people go where people go.
I used to think Discord was the clear winner in this space, providing good moderation tools (being a platform designed originally for gaming), with better scaling characteristics than Slack and having unlimited history, but the Apollo team's recent post on why they chose Spectrum changed my mind: https://blog.apollographql.com/goodbye-slack-hello-spectrum-...
TL;DR: being able to have posts & chats indexed by search engines and allowing users to read posts without signing in is a killer feature for open-source communities. Plus the product itself is open-source.
I use Discord all the time; it's a mess. Its permissions model is complex and hard to reason about, obvious UX decisions in Slack that make for a good experience aren't present in Discord. Like being able to click on someone's name and go to the dedicated DM view for them.
Discord is the one thing I dislike more than Slack, even if their backend tech is fucking stellar.
While their permission system takes some getting used to, once you understand how it works it's very easy and you really only need to setup up once. I also don't see it an issue not being able to click a user to go to DM. Not much more work right-clicking and selecting message, or any of the other options.
Seeing that the context menu that comes up has about 20 items, I can't personally agree.
Overall I hate using Discord and wish it was more like Slack in some ways. Better yet, take me back to the days of TeamSpeak when my Voice Chats had a Text Chat implicitly alongside it.
I feel like search engine indexing is a feature that should be covered by mailing lists or a forum, not chat. I don’t think that finding a years-old chat log provides nearly as much useful context for solving an issue as longer-form communication.
From what I’ve seen (with grains of salt and whatnot):
Chat is an inherently transient medium. Being a participant in the conversation can be important and you can’t really reference a conversation you had on May 6th 2007 and expect to have people willing to continue it with you. On the other hand, you can resurrect an email or forum thread if you weren’t there in the first place and expect that it will continue to be replied to.
Spectrum is good for lightweight communities but it is nowhere near the capabilities of something like Discord, which something as big as the Mozilla project needs.
>There is no mechanism to ignore a user, mute a user, or temporarily suspend a user if they need a timeout. The first two are completely impossible, while the latter today is manual / mostly possible using undocumented APIs and mechanizing of HTTP requests.
I've been using IRC for almost two decades now and I can't help but feel this is a good thing. A lot of big IRC channels have become very good at alienating members of their communities through excessive moderation - if you don't believe me spend some time on Freenode on any given day. Having to go through a few additional steps seems like it could benefit many communities.
Discord has aggressive security measures. I can't use it, because it won't let me access it from my desktop unless I give it a phone number. I guess it's decided I look like a headless browser or something.
Certainly I'd say discord is a poor fit for an organization allegedly dedicated to web freedoms, such as mozilla.
I'd suggest rocketchat or mattermost, personally. Well, to be honest I'd suggest IRC, but if that must be abandoned, rocketchat is pretty good.
I have another thread I commented on where I discuss Discord very briefly. Most times I used Discord I'm hella annoyed, Slack just has me slightly frustrated sometimes. To each their own, but the Discord UX doesn't do it for me.
That said, watching them migrate voice servers seamlessly between regions is fucking impressive, though. Kudos to them on that.
Discord works okay. For me, the only issue is not being allowed to use third party clients without being banned. I was hoping I could integrate it with tmux or Emacs like I was used to doing with IRC.
> We are not rolling our own. Whether we host it ourselves or pay for a service, we’re getting something off the shelf that best meets our needs.
I sincerely hope it’s not Slack and some restricted search archive platform. Moving away from IRC to a newer system could provide long lived archives to users. But if privacy is very important, then a “no archive” option would be fine (similar to IRC). Anything in between, like “search the last 10000 messages”, would be a disaster for active channels with many members.
> It needs to be accessible to the greater Mozilla community.
We are evaluating products, not protocols.
I’m sure whichever the chosen product is, it’s going to be based on HTTP to allow “schools, colleges or corporate networks” to be able to connect. It seems weird that we’re dumping everything on to HTTPS, and one day in the future there would be a world where only port 443 would be open and all the mess, and the holiness, would flow through it, and it alone. In the name of securing networks, we seem to have gone to an illusion of security by moving to one port for almost all communications.
> We aren’t picking an outlier; whatever stack we choose needs to be a modern, proven service that seems to have a solid provenance and a good life ahead of it. We’re not moving from one idiosyncratic outlier stack to another idiosyncratic outlier stack.
I still hope it doesn’t come down to Slack or Hipchat or some commercial offering. Maybe host a Matrix instance? Or Mattermost? Or Rocket.chat?
Everything being encapsulated in HTTPS is the result of waiting so long to be secure by default that the base network abstractions had ossified too much to realistically change.
TLS would have made sense as well but if you're already at that point you might as well bump up yet another abstraction layer because the programming ecosystem is bigger and it frees you from being tied to one security abstraction forever e.g. now you can use QUIC.
Matrix shows how thorough the switch to HTTP has become. Like with DoH, what makes Matrix most attractive is the ability to implement solutions using pre-existing web application stacks, like Node.js. It's a sort of path dependency where the easiest way to implement a simple solution starts with a very complex, mostly superfluous foundation.
The fact that port 80 and 443 are less likely to be blocked is a distant, secondary factor. Frankly, I've never been on a network that blocked other outbound ports. And I've definitely never seen a network where hosted services could only ever receive traffic on port 80 or 443. Rather, I think it's more (if not entirely) a matter of people justifying the use of web stacks to implement services which cry out for simpler solutions.
> Frankly, I've never been on a network that blocked other outbound ports.
That's just down to who you've worked for. I've worked for two companies, both well-known brands, both operating in the consumer space (nothing secret/shady), where most outbound ports were blocked.
In one case it certainly was possible to get them unblocked for access to specific hosts or endpoints but you'd have to go through an approval process that took about a week. I never had a request refused but it certainly could slow progress, although I got into the habit of trying to get all of us to anticipate what we might need and front-load such requests.
I have several (all government) clients who cannot access port 8080 from their office network. We now have a bunch of aELB rules that forward a specific path prefix to port 8080 internally. I have not yet been accused of intentionally circumventing their firewall. But I live in hope...
You could run IRC server on whichever port you like and many servers do, the biggest benefit of matrix is that it's decentralized and easy for non technical people to engage in, no need for znc bouncers and things like that.
As an IRC user since the early 90s (EFnet and freenode), I can say that it really feels like it is dying. There are still a few popular channels with helpful people, but the vast majority of channels are silent with no one but afk users logged into a seemingly forgotten ‘screen’ session. And of the channels that do have real people, those people often seem to be there for no reason other than to tell people to RTFM, play topic nazi to such an extreme level that apparently nothing is actually on topic, or just generally berate people for having the gall to say something in the channel. Ops are extremely touchy and seem willing to immediately kick people rather than have actual discussions about things that challenge any of their beliefs about a particular topic or how the channel is being run (any such challenge, no matter how genially presented, is perceived as combative and results in a swift kick).
The heyday has past. People moved on, had families and other responsibilities, with no time to sit idly chatting anymore. The newer generations are on various messenger apps, Slack, or Discord.
>those people often seem to be there for no reason other than to tell people to RTFM, play topic nazi to such an extreme level that apparently nothing is actually on topic, or just generally berate people for having the gall to say something in the channel. Ops are extremely touchy and seem willing to immediately kick people rather than have actual discussions about things that challenge any of their beliefs about a particular topic or how the channel is being run (any such challenge, no matter how genially presented, is perceived as combative and results in a swift kick).
Funny, it's been my experience that IRC culture was always like this, especially in the late 90s when I started using it.
There’s always been some of these elements, and RTFM has always been a prerequisite, however there were also other people who were not as strict so it was diluted. With the reasonable people gone, the harshness is now more obvious and keeps reasonable people away.
Came to say the same, I can hardly remember participating in a constructive conversation over IRC within the last 10-15 years. Not saying they don’t happen, just my experience has been the same as the parent posters.
Depends on the channel, Mozilla's IRC has channels (like #deeplearning) with helpful people ready to hold your hand through using and extending Mozilla TTS & Mozilla DeepSpeech.
Most channels of open source projects seem very constructive and helpful to this day. I also like lurking on #xkcd. There are still some low traffic channels of traditional communities (you know, those running on their own domain with something like phpbb) where I've known people for ages and still frequently have conversations about nothing and everything.
It's just never been that discoverable as a standalone medium, like connecting to a server and then finding a good channel. That just doesn't happen.
The network certainly has something to do with it. EFNet seems to be full of trolls and is hard to have a legitimate conversation in, while much of Freenode is so focused that it’s hard to have a natural conversation without being berated for being off-topic. Snoonet seems to strike a reasonable medium and has the nicest people I’ve met out of any IRC network.
> And of the channels that do have real people, those people often seem to be there for no reason other than to tell people to RTFM,
It depends a lot on the community. I started using IRC in ~2010 as a teenager and I don't remember ever seeing someone being told to RTFM (except ironically).
> play topic nazi to such an extreme level that apparently nothing is actually on topic,
I've seen some topic nazis, but in most channels, discussions can go very far away from the topic.
> or just generally berate people for having the gall to say something in the channel.
what?
> Ops are extremely touchy and seem willing to immediately kick people rather than
On most channels I'm in (mostly tech channels, freenode/oftc/mozilla), I don't even know who the ops are.
TheLounge is very very limited. I will always prefer weechat to everything, but if you want a webUI, glowing bear is alright.
Like you, I've been on IRC since the 90s. I find that support channels are great if your question to the group shows that you've actually exhausted your options and need help beyond what you can think to search. Often the documentation is perfect, and if there is something someone doesn't understand, asking specifically about that typically yields a positive response (at least in my experience.)
One issue I've always had with IRC is the Founder choosing bad ops for their channel -- often based more on time-spent in the channel than actual ability to resolve issues with troublesome users.
I've always op'd a few channels and have chosen some of these people -- the type that view the cinnamon bun / status as something special or powerful, rather than the janitorial job that it is. This really sets the tone for the channel and can destroy it in the long run. Bulk the on-topic nazis in here. It's toxic behavior and should be addressed by the ops.
Anyway, long story short -- IRC isn't like it was in the 90s-00s, but its still going strong. The support channels are not a good litmus test for IRC as a whole.
> play topic nazi to such an extreme level that apparently nothing is actually on topic
This is the same state of many subreddits on Reddit. Moderation should be limited to spam and blatant attacks on users. Let the voting system handle all the rest.
>And then everything ends up like the 'defaults', with memes and easy to vote up pictures utterly dominating.
I mod a good-sized sub all by myself, and I'm fairly militant about what gets through. The guidelines are clear and automod picks up a lot of the 'defaults' stuff -- but every so often something slips through and it gets so much karma.
A while ago I figured I'd just allow memes and stuff, assuming that this was what the community wanted, since these occasional posts were doing so well. I got mod mail asking if I was sick, noticed a bunch of comments saying 'this sub has gone to shit!' etc etc.
... so I went back to my militant ways, but about once every few weeks I let a meme or repost slip through if its decent quality.
Memes and all that have their place, but subs need to be heavily curated by the mods, or, like you said, they all become the same.
Thank you! I wonder if there is a way to see the % of votes from subreddit members vs others. Memes and similar sh*tposts can really ruin a subreddit in weeks.
The occasional memey or off-topic post is a lot of fun and key to having a community with its own culture instead of an interest group with the personality of a dictionary entry. The problem is that people see that was fun and naturally try to do more of it, but it's only fun in the first place because of the contrast, and the off-topic stuff is usually easier to produce so it can easily drown out the on-topic posts, killing the forum.
The "delete most memes" policy is weird, but works well where I've seen it.
Looking through Mozilla's IRC quote collection [0] also shows very little recent activity. Not sure if that's because their channels are less active nowadays, or just because fewer people are submitting new material.
I never see addressed the biggest reason (according to me) why IRC loses, so let's spell it out.
IRC isn't persistent (i.e. you can't read messages delivered while you were offline) unless you setup an IRC shell. This is technically difficult (much more so than dicking with nickservs and so, which is already a pain point). Hosting it is also not free. Count 5$/month on CloudOcean or some such.
https://www.irccloud.com/ is a great service that alleviates the pain, but now you're paying 5$/month and you just have IRC — you can't run other services on your server.
If you value 5$ or your time more than the idea of "fighting for freedom by using IRC", you just don't use IRC unless you're forced to. This is not unreasonable, so many people do that, and consequently, communities miss out on these people.
You want to save IRC? Make a free (as in free beer) clone of IRCCloud. Easy.
Once all the chat systems without persistence have disappeared, some new hip company will come along touting “no persistence” as a feature, maybe even a privacy feature.
But seriously, I don’t understand why persistence is such a huge deal to people. Chat is for transient chat - it is meant to be non-persistent just like verbal communication.
There are so many mechanisms for persistent messaging (forums, text messages, emaills, and everything in between), I don’t understand how an entire industry spawned from a concept we already had?
Why do people use chat services? They want responses. Getting responses is what Slack and Discord are optimized for and why they've gained adoption.
The chat services enable responses, by making it low friction, by giving the feel of being informal and real-time in a way that email and forums don't. They also enable asynchronous responses by being persistent, that your message won't go lost and unseen by a moment without network connectivity, unlike IRC. They also enable responses by being cross-platform and device-independent, unlike SMS. They also enable responses by centralizing account control of who participates, so users can join a ready-made group organized by an administrator, unlike say Facebook messaging.
Users seek maximal interaction. The Slack/Discord model achieves this by supporting both synchronous and asynchronous responses. The former requires an informal real-time interface, the latter requires persistence. That's what came together on these services that hadn't before.
Out of curiosity, when you log into slack/discord in the morning, do you scroll back through the log to see if there are any unanswered questions that you can answer?
I'm an admin in the Reactiflux server on Discord [0]. We currently show somewhere around 30K users who have joined, although that's _after_ having done a couple purges of inactive accounts over time.
I used to routinely go back through the day's discussions in #general and #need-help whenever I got home from work, and yes, reply to questions that had been asked 8-10 hours earlier. But, Reactiflux has become too high-volume for me to be able to do that.
That said, I still will scroll back in some of the lower-volume channels to see what came up. So yeah, having chat persistence is an incredibly nice feature, and I can't imagine doing without it.
This is exactly the functionality of forums, for example Stack Overflow (and many others before SO). I guess the only real advantage of Slack is that it's both real-time and persistent. That said, is that advantage really worth millions of dollars, or is it just clever marketing?
Yeah, there really is a significant difference in usage between forums and chat channels.
Chat channels give immediate and interactive feedback. When someone asks a question in Reactiflux, they frequently get an answer within minutes, if not seconds, and we can iterate on asking for details quickly if needed.
The downside is that multiple simultaneous conversations in the same channels quickly become hard to handle, questions can get missed if they're not answered right away, and we do see a lot of the same questions over and over.
I know the Spectrum folks have emphasized the searchability of their site as a major selling point, both from Google indexing pages and the ability to search for existing threads. I won't say they're completely wrong, but at the same time, my experience is that newbies in particular won't actually search for existing answers - they just want to ask and have someone answer directly.
Yes, because I provide support for my library in a discord channel.
I scroll back and check for reported bugs and any problems people had that weren't resolved by others.
"They should just ask on a forum/github/stackoverflow" you might say. Ok, but they won't, they'll just stop using my library instead.
Forums require too much risk. Spend 20 minutes crafting a question, never get a response. Github and Stackoverflow are far too complicated for the average user. What's an issue? What's a template? What's a minimal reproducible example? They just want to know what error code 501 means...
I know I hate it when I join IRC channels and have no context as to what anybody has been talking about, as there is no history to quickly go over. Even just having the past days history would help in this regard, at least for more active channels.
It's the same as just barging into a conversation a group of people are having. You don't want to just join and start talking about a completely different topic. So you join, and wait for a bit to get a feel for what they're talking about before piping in. But with IRC, sometimes it can take _days_ to get that amount of information, depending on how active the channel is. The same thing could easily be accomplished by being able to read the last 10 messages in the channel.
Then presumably you never did work over IRC. The fact that you can have discussions in asynchronous real time out in the open makes (made?) for a far superior developer experience compared to forums, text messages, emails, and everything in between, because everyone could _passively_ follow the conversations that were happening. IRC is the ship's "always on" walkie talkie: do you need it? No. Does it provide a layer of common knowledge that you never even stopped to think about made everyone feel like they knew what was going on even when they couldn't tell you what was going on, thus making everything run impressively smoothly? Absolutely.
And remember that IRC has been around since 1995, when the idea of separate protocols to do different things was common place. IRC has been dying a very, very slow death.
(and despite nostalgia: IRC was never big. Even the largest of IRC servers only had around a hundred thousand users. That might sound like a lot, but we're talking globally: the most popular IRC server had a fraction of the users that CompuServe did, and CompuServe was decidedly worse at being a chat system, even though that was the main reason you'd use it)
I was never an IRC user, mainly because I never really needed it. Everyone I wanted to talk to back in the day was on BBSes, later ICQ and later still AIM, and IRC just always seemed so desolate and took a lot of investigative work to find the right channel to find something interesting. I'm not really defending IRC, more than questioning the need for yet another chat application, with a distinct con of being centralized when we have all these other means of accomplishing the same thing
Right, and as someone who's used it extensively, I'm here to tell you that its value is not in being "a chat application". Its value is in being a _community_ platform, where everyone can see and hear everyone else. While private message has always been in the spec, the value of IRC has always been in offering people a place to establish common knowledge and culture _passively_ to whatever degree necessary for the channel or even server that happened in/on.
Simply by being in an IRC channel you become part of that, which is radically different from any of the other media you mention, where one has to actively go through the records (as it were) to get an idea of what's going on, and what the shared culture and body of knowledge is.
They really are very different media with a very different experience, and today the only experience that has managed to recreate the value that set IRC apart from other communication tools is Slack/Discord.
Minor nitpick: 1988 to 1993, depending on what you consider 'irc'. (1988 for irc1, 1993 for the standardization of ircII that still defines irc today, 1992 if you consider the efnet/undernet fork to be the birth of true irc).
I wonder how much work it would be to extend the IRC protocol and popular implementations to include some sort of persistence. It's such a shame that a simple, open, accessible protocol for communication is being lost simply because of this and that it's "too difficult".
Very simple - the server can push to the client when joining a channel. This would require the channel to be logged server-side and that the user authenticates with nickserv before joining channels. It does not need client-side changes so you could still use any client.
Yep. Easy. So I assume you already did this, what's the frontend website for us to start using?
(As a long time IRC user, I'd love a free irccloud with all the features of Slack and the freedom of IRC. However, setting that up scaled for "thousands of concurrent users" with normal, modern, administrator interfaces for all those tasks that the IRC RFC themselves left up to individual implementations is REALLY EFFING HARD, so no one has actually set up a service like that, to date)
I'm part of those who don't really value "fighting for freedom via using IRC" so I use Slack & Discord. I have no stakes in saving IRC.
Also, building and maintaining a free IRCCloud clone is worth much more of 5$/month of my time.
And seriously, it's not that hard. I know people who master the ins and out of much more complex server stacks as a hobby. A nice example is the implementation of World of Warcraft private servers. IRC is nowhere near as complex as that. I do concede that it's a long-term effort though. It's certainly not just a "weekend project".
Still as far as "saving things" go, this one is easy enough that a single person could build the tech on his free time and then you just need (a) patron(s) to pay for the infrastructure bill.
Chatting isn't about always being online and getting messages. Somebody else in the channel should be capable of responding to a request. That's the whole point of a community, IMO.
Need to make sure something important is captured from an IRC discussion? Put it on a wiki/mailing list. There's also things like meeting bots. Most communities I've seen, there's very little value in an IRC chat history for conversations other people had (eg, just stuff like 'help me with x').
At least for me, I participate in a lot of programming channels. I've saved a lot of stuff for later, that would otherwise be a pain to ask someone to answer it again. I log basically all of my irc chats because
1. storage is cheap
2. you never know when something could be useful later
Let's not pretend individual nerds in IRC chat recording history is anything remotely close to what google is doing.
It's a shame that IRC usage is dwindling especially in techie circles. However I can understand it if it doesn't work for them any more although in my opinion IRC has a lot of moderation tools available. In any case, the "problem", of sorts, is not abandoning IRC but what comes next. The web is choke full of proprietary communication protocols that cannot talk to each other and you have private entities acting as gateways to online communication. Instead on relying on protocols and let clients decide how they connect to the network you have users being herded into walled "communication" gardens. This goes beyond Slack or Discord or chat-app-of-the-month. Having a flagship open-source project behind a proprietary platform for communicating with the users and developers can't help but leave a sour taste in the mouth.
I use IRC quite heavily. Especially for cryptocurrencies and local hackerspace channels. They're all very active.
But I agree with the post, "irc is not fine", and never was fine if you want to communicate with "regular" people.
It doesn't have spam filters, easy GUI or easy registration process. You could build all of those on top of IRC, and I'm sure that some people did, but there's no "standard" and most people just can't be bothered.
As the post said, often "IRC traffic isn’t allowed past institutional firewalls".
Besides, when was there a time in the history of the internet that irc was used to communicate with laypersons? If that's Mozilla's goal, they're right to switch.
That said, irc is fine, or even the best, for some communities. Especially communities of internet-savvy people.
It's decentralized, open, easy to access and inclusive. Such communities rarely meet the need for spam filters, and each of their members possess a well-distilled taste for personalized tools for irc.
That's why cryptocurrencies or hackerspaces channles are great on irc. That's why #rust channel is fantastic.
I still didn't find any modern substitution as good as irc for those communities. And yes Matrix, I'm looking at you! You're just not there yet.
>But I agree with the post, "irc is not fine", and never was fine if you want to communicate with "regular" people.
That's cool. I don't want to communicate with regular people, I want to communicate with hackers. If I wanted to communicate with regular people I would use Twitter.
If they wanted to communicate with laypeople they'd offer support over the channels laypeople expect support nowadays, namely Facebook. Instead they are going to choose some middle ground that will displease everybody; they will botch it, as they like to do.
If you mean real-time chat, in my personal opinion, Discord is the best choice. Zulip is good, if you can deal with it being a bit weird. The other options are fine, but not great. You may have different opinions than me personally.
Sure, it may be a bad-faith question, but I think the point still stands. IRC, as an open communications protocol, will always, always, always be better than private companies with the potential to be controlled by anything. Richard Stallman would be rolling in his grave.
It's simply pathetic that the handlers of one of the most important parts of Mozilla unilaterally decided to move the community to a closed source service and Mozilla didn't have teeth to do anything about it.
I know there were/are a few blind people working on Mozilla's stuff and the move to anything that is not open source will make it much harder for them. There was a person[1] who had done significant work on the Rust compiler and said that he would have a much harder time doing it now, since the move to Discord and that he might not be able to participate in the community after the switch[2]. Proprietary solutions are a little bit better for the 80% of people, but way worse and/or unusable for the 1 to 5 percent, depending on how techy the community is. We have to realize that those solutions have big gains, but they also have huge tradeoffs. IRC inconveniences some people. Discord excludes some completely.
It's really frustrating to me how inaccessible Discord is. At its heart, Discord is text and voice chat, which you would think would be the easiest forms of communication to make accessible.
Due to a genetic condition I have that predisposes me to blindness I have preemptively installed NVDA on Windows and Orca on Linux, and the inability of either of these tools to deal with Discord the last time I tried is shameful.
Bryan Smart's reply to that Twitter thread depresses me.
>Don’t worry. They’ll totally fix Slack and Discord around the time everyone is using VRChat and VisualTeam. It’s always been this way. Accessibility is catchup work. The next big thing always destroys our gains.
The language at the end of the blog post "We are evaluating products, not protocols" and "We aren’t picking an outlier" almost guarantees we're looking at solutions as heavy as Slack and Discord which I would not have been able to run on my laptop back when I was involved in the switch to Firefox Quantum. It's challenging enough having to advocate for "niche" (my words) features and work out their implementations, but IRC was also necessary to keep track of which builds on what dates would introduce which breaking changes, since this information was published nowhere else, and also to minimally participate in decision meetings that ended up in video chats anyway. If they do move to a heavier, but closed, solution, I hope they also find ways to make contribution less reliant on chat.
For what it's worth, I thought Mozilla had a fairly decent wiki page for IRC[0]. I always believed a streamlined quickstart section, suggesting one or two clients at most, walking through steps to registration and configuring authentication with ghost killing, and how to get activity from when you were offline either via bouncer or just logs[1] would more than adequately address ease-of-use without rolling out a newer, modernized client. Even working from libraries wasn't an issue for me using web-based clients like Kiwi IRC.
I just want to say, for all it's worth, that the #rust channel on MozNet has been by far one of the most healthy and productive IRC channels that I've participated in. The channel is always active, and there is a constant presence of extremely qualified and patient folks in the chat (and often Rust core members as well). I hope that whatever they switch to will be able to foster a community as open and welcoming as their IRC.
I don't understand what moving to slack is going to give them, which is inevitably where this is going to lead (or a similar web-based chat).
IRC has the same tools for banning users as Slack, if not more powerful as you can ban ranges etc. You can require people to register with an email in the same way slack does, although I'd argue being anonymous and being able to talk without an account is one of IRC's best features.
I can't say I ever went on Mozilla's IRC, but I have spent almost 20 years on other IRCd's. Seeing it be replaced, just to be able to use rich messaging breaks my heart.
Which is incredibly easily to get around with a bouncer and shell company in eastern europe or pretty much anywhere. We're not talking state-actor anonymous, but anonymous enough.
> You can require people to register with an email in the same way slack does, although I'd argue being anonymous and being able to talk without an account is one of IRC's best features.
As someone from the “old” and free internet I agree, but there seems to be a new generation of users who seem to have the ability to perform censorship as a core requirement (although they prefer to call it “governance”).
It’s sad to see the direction they are pulling the internet, one of the few truly free platforms which has ever been created.
I seriously doubt that both harassment and spam is a much of a problem as Mozilla, or others make it out to be. That's not to say that it's not a huge issue for a subset of people and it should be dealt with, to some extend.
If someone want to harass you online, they will find a way, regardless of what governance or censorship you put in place.
Interesting. Do you have experience moderating a comparable community, or what leads you to believe that it's not as much of a problem as they make it out to be?
I'm sure it will always be possible to find a way to harass someone. But do you believe putting barriers in place has no effect on the amount of harassment that targets have to endure? What do you think of the computer security concept of "defense in depth"?
Couldn't you trivially defeat that by randomizing your IRC username? Blocking email addresses does literally nothing against email spam, why would chat be different?
More of what I was thinking was a killfile controlled by the user, uploaded to the server when updated, that would allow the server to filter messages. You could allow shared blocked lists and support wildcards with whitelist exceptions. In this way, you can block everyone and whitelist who you want, so changing your IRC user name does not help.
In most cases, unless the person connects from somewhere else, specifying a sufficiently wildcarded netmask for the host part also prevents the IRC nick change.
Matrix and Riot is good open source replacements for IRC.
With Matrix and Riot you get a modern interface yet can bridge out to IRC open source networks and channels!
I had a question for the Firefox UX team a few months ago and went to #ux on irc.mozilla.org. The channel was completely dead. Someone that wasn't from the UX team was still there and told me they all moved to a private Slack channel.
Irc unauthenticated? IRC has supported auth services since what 1995? There are also plenty of web irc gateways so I don't understand the reasoning to move to something more complicated for little gain, want history? Run ii in a tmux session and tail to a file, want to post images with a fancy GUI taking a gig or so of ram use slack.
They apparently want anyone to be able to easily connect and talk to developers, except for trolls, scammers, spammers etc. I'm not really sure what kind of authentication provides that, but they seem to have something in mind.
When I worked at Mozilla, "talking to a room full of bouncers" was a common joke on my team. In a fully distributed team (we were spread out across the northern hemisphere) this is a terrible way to work. You don't know who is online or whether you can contact them. There's no guarantee they'll get your message if you send them something urgent. Everything that's not "typing text in real time" is harder and worse (search, sharing files, sending long messages, mobile support, etc.) and everyone has to scrounge for their own tools to work around these insufficiencies. In a work environment, using a tool that only does part of what you need it to do is a crazy irresponsible use of resources.
IRC might be useful in some circumstances, but supporting team communication—especially for remote teams—is not one of those circumstances.
> You don't know who is online or whether you can contact them.
I've actually had this problem with most, if not all, IM/chat systems I've had to use for serious work. They have better UX design for indicating availability, but I can't think of one where it's consistently worked the way I expect it to. Some explicitly allow people to fake/hardcode their status; others have some mixture of caching/update issues and strange criteria for deciding whether a user is "active" or "present" such that the indicator isn't very reliable in practice.
> Some explicitly allow people to fake/hardcode their status
That's not an issue with the tech, it's an issue with the people. I'm not shooting off messages with no idea of whether they'll arrive, I'm at least trusting the person's intended availability. If they're just being an ass and marking themselves as perpetually unavailable, that's an issue I'd take up with their manager.
In my experience, modern systems like slack and discord (and even hipchat) work well enough with their availability indicators. Chat apps five years ago I would not trust as much.
On slack it shows whether someone is active or away. It also guarantees they'll get the message. You're not praying that you picked the right bouncer to direct your message at and that it's configured to let them know when they get back.
You can easily see if someone is active or not. Most clients even tell you that the user is away.
The other problem you describe is related to it being an open standard. If you had a custom slack client or server you also would not be able to make assumptions about how it works on the remote end.
If you're an organization like Mozilla that uses IRC for company business, you can just tell employees what they must support (with an or closed product).
If I'm reading this correctly, the main problems they have with IRC is that it's too "old"/obscure, and too open — simultaneously too difficult and too easy to access. Hard to control who gets in and what they say.
I haven't seen much spam or harassment on IRC, but I haven't been to Mozilla's server.
As for newbie accessibility, doesn't a web gateway solve that? You could change the font family from monospace to Lato and it's instantly 20 years more modern :)
> And when we’re talking about blind spots and invisible social access controls, of course, what we’re really talking about is privilege. “Working in the open”, in a world where computation was scarce and expensive, meant working in front of an audience that was lucky enough to go to university or college, whose parents could afford a computer at home, who lived somewhere with broadband or had one of the few jobs whose company opened low-numbered ports to the outside world; what it didn’t mean was doxxing, cyberstalking, botnets, gamergaters, weaponized social media tooling, carrier-grade targeted-harassment-as-a-service and state-actor psy-op/disinformation campaigns rolling by like bad weather. The relentless, grinding day-to-day malfeasance that’s the background noise of this grudgefuck of a zeitgeist we’re all stewing in just didn’t inform that worldview, because it didn’t exist.
> As for newbie accessibility, doesn't a web gateway solve that?
Until this week, Rust's Community page [1] linked to Mibbit, which allowed you to join IRC just by entering a username and pressing Enter.
Now there's only the Discord button, which works the same (besides an extra click to accept the ToU), and you get a popup and a red banner asking you to register.
> too easy to access. Hard to control who gets in and what they say.
I don't really get that for an org that runs their own IRC servers. Requiring external registration, rate limiting, content filtering, ... all are available options. Just because the majority(?) of IRC networks allows access freely doesn't mean you have to. I'm not sure what other systems would add in this regard an IRC server can't do.
I suspect the amount of spam and harassment on MozNet hasn't actually changed over time, or given Firefox's decline may have even got lower (as fewer people care about Mozilla anymore). No evidence was provided that times have actually changed w.r.t. spam and harassment even though this appeared to be the primary motivation to shut down IRC.
Rather, I suspect Mozilla's increasingly sensitive SF bubble-immersed culture has created an environment in which ever more mundane disagreement and conversation is relabelled as "harassment" and what they want is a system that allows for much more controlled speech. Seems a part of the general zeitgeist of the Valley in which techies are concluding free speech is harmful and they should control what's said.
Personally I dislike this trend towards a plurality of chat "services" and "apps." Now each project I interact with has their own chat service. I have to maintain accounts on all of them and install several applications to interact with each. It's a pain to manage.
Not to mention that most of these services use Electron-based chat clients which exclude a bunch of people who cannot afford the kinds of machines required to use them or they have to suffer a poor experience on lower-end hardware. It also excludes people who use accessibility software or automation that doesn't integrate with web-based clients.
The user experience on IRC scales better. Anyone can write a rich, easy-to-use client or server. If you happen to be a programmer you can write your own tools to manage your own user experience. The drift from casual user to power user isn't stopped by a walled garden of a tightly-controlled user experience that doesn't integrate with anything.
Spam can be difficult to stop on IRC compared to modern webchat applications. From lacking things like javascript, captchas, cdns, and so on, to having a distributed network architecture and fewer ways to verify users.
> having a distributed network architecture and fewer ways to verify users
You have exactly as many ways to verify users as are implemented in your NickServ, and pretty much every snazzy web-y proprietary chat platform has a "distributed network architecture" as well.
IRC has plenty of real problems, but your particular list of arguments seems completely irrelevant.
NickServ is not part of IRC. It's just a bot that people wrote to overcome one of the key shortcomings of IRC, and is used at the discretion of individual server administrators. IRC itself has literally no way to verify users, and more importantly no _opinion_ on how you should verify them.
Sure, people have written bots/services that have become part of some server packages' standing offering (chanserv, nickserv, opserv, etc.) but there's no spec for them, every server's implemention has (sometimes wildly) different command sets, and as effectively text-scroll CLI, they don't actually make things all that much easier. They're a chore to use. And I say that as an IRCop.
IRC as a platform is insufficient in today's world, so if you're going to spend a lot of time either finding -- or more likely, making -- services to take care of all the administrative tasks that IRC itself does not cover, you might as well just go one step further and go "you know what? IRC isn't sacred, if we're spending time and money on trying to make it usable in 2019, then how we instead spend that same time and money on finding a good solution to the problem we're having, rather than sticking with IRC for no good reason".
The post says the new system will enforce authentication, and hints at dealing with bots and spam accounts. But it’s not going to be easy without inconveniencing users to some extent (or a greater extent than now).
Generally speaking, systems that add registration onto irc tend to make it even harder to use than it already is. In order to make it better you basically have to make it at best act strangely with existing clients, or at worst make it completely incompatible with them.
You sound like you have absolutely no idea. You are greeted by NickServ on connecting with an unregistered nick, asking you to register with your email by sending a standard /msg. You open the email and click the link. I remember doing this for FreeNode at the age of 13. It’s fine.
Then you close your laptop and reopen it and you have to reconnect. Oh, you want it to automatically reconnect? No problem, you can automate identifying yourself to NickServ with a simple command like /NETWORK ADD -autosendcmd "/^msg nickserv ident pass;wait 2000" ExampleNet
Oh, a ghost session stopped you connecting as YourName and now you're YourName2 ? No problem, NickServ can kill your ghost session so you can get your registered nick back. Oh, you want to do that automatically? No problem, just download this script - a mere 10 lines of perl - and put it into your irssi autorun directory.
Easy, as you say. Anyone who disagrees has absolutely no idea :)
Bullshit objections. I cannot remember the last time I had a ghost session that I needed to have killed. NickServ password integration comes by default even in Emacs’s ERC.
I've been on irc of various flavors for 25 years now. I've seen every problem nickserv system can manifest and I've seen it cause a lot of problems for users less technical than me.
It's nice that you've never had a problem with it. Doesn't mean it's easy or perfect or that no one does.
The typical ways to combat spam are also the ones most toxic for privacy and anonymity. On discord, the chat service that Rust migrates from IRC, I had to enter captchas quite often in order to log in to my existing account. Simply because I cleared all my cookies and had a different IP address. I rather have the little amounts of IRC spam than having to give them my phone number (EDIT: I've heard from someone who logged in to discord using a VPN who now has to enter one even on logins outside of VPNs). Abandoning IRC seems to be against Mozilla values.
The solution to a social problem can be social in nature.
If you apply this to the OP blog post you can see that the desire to get away from IRC to "safer" products comes from the desire to deal with the social problem in a social way, but in a hidden way:
The technical solution will supposedely make it easier to apply the social solutions, i.e. the barrier of entry for undesired participants will be higher.
An undesired participant can be someone who questions Mozilla on a fundamental level (i.e. on the topic of meritocracy, privacy, inclusion, activism, etc.)
The proposed solution is reverting to a "safe space", i.e. something that promises to automatically protect against undesired participants, because Mozilla has long ago decided that it does not tolerate being questioned on a fundamental level.
This ultimately results in a reclusive filter bubble, where a significant part of the audience is no longer allowed to exist.
Since Mozilla does not seem to want to invest in moderating these spaces in a democratic and open way, which is very costly (but human relationships are always costly), the proposed solution is to build a fence between "us" und "them".
It can put registration and private messages, etc, under their control.
They they can raise their anti-spam bar arbitrarily high to block alt registrations and enforce bans. Sight of all PMs could be used for anti-harrassment too, but don't know if they'd do that.
Accessibility, especially from bandwidth efficient light weight software or text only devices is at odds with blocking automated spam.
If you make it much harder for anyone with unusual software to connect, you make it harder for spam (and also a lot more legitimate users than spammers, but those don't count because they don't cause issues for operators).
Realising that I am at a point where I don't reflect the majority of their user base, how did we get to the point that registering via anything that's not a fancy web interface is considered too hard for inexperienced users?
I'm relatively certain that wasn't considered a problem back when I got into IRC and there were more active networks and channels out there. You for whatever reason logged on and were often greeted by messages or even a bot that helped through the sign-up process. Even most GUI clients contained relatively straightforward ways to automate the authentication steps afterwards as well. Again realizing that I'm now in the "snarky old grump" position, discord and slack often feel like a step in the wrong direction. On the one hand it's nice that these platforms include rich media, message archiving/replay, and technically inept users (although the latter would have worked fine with bouncers/webapps back in the day), on the other hand it's just moving my personal communication to yet another corporate silo with weird monetisation.
Not trying to imply that IRC would represent something more convenient messaging wise but did we really have to move in the completely different direction there just to integrate a few solutions and add monetisation?
There's really a need for IM interop. These fragmented islands stall the network effect (Metcalfe's law) that is needed to sustain and grow communities.
I guess the best thing for the current situatio would be a headless service that would connect to your IM identities, and buffer messages, from many different IM identities and protocols. You would then have intermittedly connected web or terminal or mobile apps as its clients. Does something like this exist?
this is what IRC ... does. The xmpp standard and ecosystem of clients/servers has also provided this for a decade plus.
If something 'modern' is required, Matrix protocol and its ecosystem is a contender. Also look into the world of ActivityPub federated applications, which cover everything from replacing Twitter to blogging.
My personal setup is to use bitlbee or libpurple to connect to every major chat network that exists today, bridged to my irc client via znc. This provides a consistent presence, status, and ui across desktop/mobile, push notifications, filtering, and behavior under my control, all with chat client that doesn't take up 1GB+ of memory with phone-home telemetry and useless emoji
I think bridges are not a good enough level of integration. You really need to have your personal connection to your IRC servers.
(Unless the matrix IRC bridge connects to the IRC server with a server-to-server type connection and can thus address messages from/to virtual users on the IRC protocol level. But that would need a lot of coordination and authorizations from IRC server administrators, which brings in so much friction that it probably kills the idea.)
edit: it seems possible that the matrix irc bridge will make a new client irc connection per bridged user, which sounds like a better idea. hard to make out from the docs though.
This is precisely what happens. The matrix.org bridge has approximately 25k open client connections to freenode. It would probably be a good idea to switch it to server-server connections to save resources, but afaict nobody has experimented with that yet. If you've ever seen users with an [m] at the end of their names, that's the default name for bridged matrix users.
Freenode works for other open source projects. Mozilla might even be able to direct a little resources and governance influence their way. (If Freenode didn't work out, it was worth a try, and an easy move from irc.mozilla.org.)
Reading the comments, it amuses me that those who support Linux fail to realize that IRC is the microkernel (i.e. Minix) approach in messaging. Want authentication/security/archiving/etc.? Layer things of variable quality on top, and hope there aren't any holes on them!
This is a good watershed moment for FOSS as a whole and I hope Mozilla decide to fork Mattermost or something similar and expand it to suit their needs over using Slack if that's the direction they head.
Something federated and encrypted like Matrix/Riot would be fun. Having something that's federated would be lovely to see other members of the FOSS community start to come together over time.
but there is a lot of problems with those rich text/react/Electron thick apps can be "painful" tho
As you are considering multiple alternative stacks, may I suggest Mattermost? Runs decently across all major client OSes, supports Slack-style hooks and thanks to multi-team capability can also be used to further the development of other OSS projects.
It is! This is one of the things where they can be principled instead of pragmatic because their browser share will not diminish due to this decision (unlike the inclusion of DRM).
The danger of giving up on IRC and going with a hosted corporate product is the chilling effects on free speech by being at the whims and mercurial mercy of corporate interests. They ought to stay with a self-hosted product that cannot be shutdown by whichever government or corporation decides to ban or restrict speech, thereby ceding what should've been public commons to being under the thumb of a particular government or corporation, and what they deem acceptable, not the community/community leaders deciding. I suggest hosting it somewhere like Iceland.
> Our mission is to ensure the Internet is a global public resource, open and accessible to all. An Internet that truly puts people first, where individuals can shape their own experience and are empowered, safe and independent.
You could levy this complaint if they actually end up picking Slack (or something similarly proprietary like Discord), but that seems quite premature. I'll miss moznet as much as anyone, but there's no denying that IRC has been left in the dust this past decade or more.
It seems that by left in the dust, you mean "remained lightweight and simple". The popular alternatives so far don't seem to have any clients I find pleasant to use, and are rather strongly discouraging anyone from writing third party clients.
You could say that about everything Mozilla has done in the last 10 years. They continue on because it's as much about changing people's priorities as enabling them.
If they then choose out of pragmatism to behave in ways contrary to their stated principles, people will justifiably call them out for hypocrisy.
This elitism is a big part of why younger users* such as myself have never gotten much use/utility from IRC and hence exacerbates its growing irrelevance compared to alternative tools.
*Think XMPP GTalk etc. which were IMO superior in many ways to Slack or MS Teams
Please Mozilla! Use an open alternative like Matrix/Riot or even better - BUILD one of your own if you think Matrix doesn't cut it. A foundational OSS company depending on a closed source product and closed protocol for such a fundamental need such as communication is simply wrong.
Off of the main topic, but this blog is basically unreadable to my form of colour-blindness. The link colour is unreadable against the page background, and the right nav is so low in contrast I can't read any of it without using text selection to artificially improve the contrast.
Looks like I am too late to this party. I just recently started visiting the mozilla ircd. There are lots of channels and very little way of navigating around. I was trying to figure out who to talk to about network support or if such a channel existed and no one had an answer. People come in asking support questions but no one has an idea of which channels to best ask in. #firefox, #introduction and #newbie are 3 channels doing the same thing and the questions just get split off. If they can't maintain their ircd, maybe just register a project on freenode who seems to be able to handle roughly 80k people just fine.
Edit: Just checked, freenode has a #firefox, not sure how official or how maintained it is.
Many things mention about other services are still possible with IRC; in some cases by the client side and in some cases by the server side. Server side logging is possible (and I have implemented this once) with IRC. Still, you can make it available with multiple protocols, and you can alter an implementation of a IRC server even if you do not have it available with other protocols too. IRC is also easy to use without any special software.
I currently have a NNTP server set up, but not IRC or any other kind of chat system (but if I do set one up, it will almost certainly be IRC).
Are Riot and Matrix compatible with irc clients? If so, wouldn't that mostly solve the problem? You have a way to phase out legacy clients and time to work the kinks out of an open solution.
Mozilla could be interested in the greatest new chat product from the getstream.io folks. It looks like not an outlier, being used by PH, unsplash, and other great websites.
I’m more than a little surprised nobody has chimed in advocating Openfire, which is Apache 2.0, standards based (XMPP et. al.), extensible, and also has some pretty nice browser clients out there (e.g. conversejs).
> We’ve come to the conclusion that for all IRC’s utility, it’s irresponsible of us to ask our people – employees, volunteers, partners or anyone else – to work in an environment that we can’t make sure is healthy, safe and productive.
I don't know about healthy or productive, but I am fairly certain that IRC is safe.
What worries me is that 'safe' has become a bit of a euphemism to mean 'unchallenging,' and what this really means is that the organisation which booted Brendan Eich really wants to unperson anyone who blasphemes this week's orthodoxies.
> ‘safe' has become a bit of a euphemism to mean 'unchallenging
I doubt the concerns are about people discussing Rust vs C++. And, this being Mozilla’s semi-internal technical discussions, even the most intellectual, data-backed hot takes on the culture wars de jour are probably out of place: getting DMs like “here are twenty proven statistics girls are bad at math” because you happen to use a female handle is still harassment, even if (hypothetically) true.
You're not wrong, even if it is an unpopular opinion. It's really sad to me as an early internet user. Their side projects have all seemed to fail, and Firefox has never been further behind. I don't see them as being solvent in as little as a few years.
That's too harsh IMO. FF is working absolutely great on my desktops, phone, and as dev browser. And Rust seems extremely popular with a vocal minority on HN at least. But yeah, I'm concerned as well - Mozilla should focus on producing a good browser rather than pouring energy into side projects such as Rust and especially WASM which do not contribute to that goal.
Idk about firefox, but MDN web docs is somehow the only online reference for js that's usable (other than the ecmascript specification which isn't for quick learning so much as a deep dive into technical details).
I want to believe that, and even tried to go all Firefox for the previous two weeks. I will say they have good Sync, which nobody outside of Chrome had achieved at all. The desktop browser is mostly OK, no real complaints. On mobile, however, Firefox is noticeably slower than any of the usual blink based browsers, and most importantly to me, uses way more battery life. I love PL things and am glad Rust exists, but from the outside it feels like a wasted effort, for now.
You speak as if FF was a niche product that is a sacrifice to use. There are markets such as Germany, that were always more seceptical of IE/Chrome where FF is still in second place at around 25% and recently rising again while Chrome has fallen back below 50%.
Chrome is definitely the dominant browser, FF is far from irrelevant.
I also echo the content of the sibling comment: on mobile u block origin is really a God send.
That's what I'd been trying. But I've found that Brave and even Opera (issues aside) do it better, and at a fraction of battery life. On my phone battery is king, so I really wish that part were fixed.
I experience the exact opposite on mobile, because it's possible to enable tracking protection which makes 99% of websites I visit more usable, performant, and battery efficient.
There is no mechanism to ignore a user, mute a user, or temporarily suspend a user if they need a timeout. The first two are completely impossible, while the latter today is manual / mostly possible using undocumented APIs and mechanizing of HTTP requests. Users reporting spam is done by them sending a message to an admin, or in the admin channel, and requires someone to manually intervene and moderate the message. So we effectively need to aim for follow-the-sun moderator coverage, which is a bit painful.
In terms of usability and accessibility, some of the things Slack does (e.g., threads) are not super-inclusive or accessible to users who use screen readers. Today, based on feedback I've gotten, IRC is still superior for users who rely on screen readers due to some form of visual impairment.
Whichever product they go with, it'd be nice if they provided an authenticated IRC gateway which would allow this class of user to have a better experience using the platform as they could use one of the text-based IRC clients that has served them well.
For everyone who is saying they hope Slack isn't the choice, I'm fairly confident with these issues today they won't pursue Slack. If anyone from Mozilla, or any other org, would like to discuss some of the challenges we've had using Slack as an open community I'm more than happy to schedule time. I'd like to help you provide the best experience and community for your users.