Candidates for Mozilla's IRC Successor | Hacker News Reader

Candidates for Mozilla's IRC Successor

exple.tive.org

182 pointsnature211 comments

I have full faith that, if I had left a computer running, in the corner of my home, with an IRC client open, it would have been able to maintain a connection to Freenode (not continuously, but just work) for fifteen or more years.

Personally I don't think IRC will ever be replaced. Well, it will, but it'll happen when my generation dies and gets fully replaced with the New Shiny.

I _hope_ that some sort of real, proper standard, that doesn't endlessly reinvent itself, that isn't subject to some for-profit bollocks, that on a very basic level, has like, a standard, has _clients_ (not just one wanky proprietary web frontend) that just sits and gets the job done like TCP, comes out of all of this.

Meanwhile, I'm fairly sure IRC will still be there in another fifteen.

Hell, at this point, IRC has been a constant in my life for longer than everything other than family. It actually feels like a friend. A portal to another quirky world, just as it did all those years ago.

I think it's almost two decades now since I first logged in. My my. The years are short, indeed.

I started reading up Ruma sources with the intent to start contributing when I'm done with my current work (and when async lands in stable). Hopefully it (and maybe Dendrite) will be able to provide your 15 years of uptime on the client side in the future.

Oh, yeah. A little longer than that, here

My freenode nick was registered in 2005, and I know that's the "new" registration since I accidentally confused the nickserv RELEASE and DROP commands once, and had to re-register the nick I had just mistakenly unregistered. It had a few years of history prior to 2005, but I don't know the details anymore.

And prior to Freenode, I was on a few other networks going back to '94 or so. But moving networks meant it wasn't a "constant" in terms of being the same environment, just the same interface.

We're not the only ones who feel that IRC will be around until we're gone... https://xkcd.com/1782/

Die? No, but it is slowly degrading. More and more the people in my old freenode chatrooms are idle or simply leaving. We've gotten so used to phone notifications and a persistent history, that IRC has fallen behind purely from a convenience factor.

It's rock solid in what it does, I have zero doubt about that or your 15 year claim. But even if the protocol works, if the user base isn't being added to it will die eventually.

> if the user base isn't being added to it will die eventually.

Which is, sadly, a lost cause. We had a simple, reliable, open, decentralized base that simply did not adopt to the needs of a changing userbase of the internet enough. Non-technical users have expectations that are incompatible with the text only format and they prefer platforms that feel more like their other social media tools. Technical users don't fix that and get riled up about nonsense instead, like non-TLS connections and other points that were addressed a decade ago, alongside people that just prefer a more decentralized system.

It feels like xkcd #927 is also relevant [0]. The open source world in chat/social platforms often looks like Googlers looking for a promotion instead of addressing real needs and most efforts seem to be drowning in irrelevance. Even technically sensible projects like Matrix, who's going to use that? Not the instagram crowd that's for sure, heck, many technically inclined people cannot be bothered with IRC when the alternative is convenient. I'd be really surprised if we see a widely adopted open messenger in 10 years, it's more likely that people just settle on a new random walled garden every 3-5 years.

[0] https://xkcd.com/927/

> We've gotten so used to phone notifications and a persistent history, that IRC has fallen behind purely from a convenience factor.

I have that with a bouncer (znc) and a plugin. I've not used it, but it is my understanding that IRCCloud does this too. Problem is that there aren't many easily usable options for this apart from IRCCloud and even IRCCloud itself isn't all that well marketed.

Always seemed kind of weird how while IRC is full with FOSS people who are willing to use their time on various projects they're not getting paid for, most of whom also seem to worry about IRC dying out, nobody is really doing anything about it. A lot of the conveniences we miss could mostly be solved by making modern clients that are actually good.

Quassel is being actively worked on and solves a lot of the woes for me.

I've been using it for... around nine years. It used to have a lot of performance issues, notably around synchronising initial state/backlog fetch on first connection to the core/daemon, but those were eventually fixed.

It works very well now, and the Android client is pretty great too, but there are still some gaps. Mainly, the surrounding ecosystem is quite sparse, e.g.: - There is basically only a single web client for it (node-based, which is a con from my perspective) - There are only a handful of semi-functional log searching/browsing utilities around

I think free (spyvertising supported) and free or steeply discounted (operating at a VC-backed loss) commercial offerings both being so common dampens enthusiasm to work on and demand for open source software, especially the user-facing stuff. Earlier on in computing history (into the mid '00s, at least) such things were much less common.

I think it also dampens the same for traditional paid software in a lot of areas, incidentally.

IRCv3 is still moving forward and gaining momentum.

Started in 2016 and still has no major IRC networks support it.

You can have both notifications and a persistent history with the majority of IRC clients. Many public channels keep logs, even. If someone pings me (hilight), then I get an urgency hint. Most window managers handle urgency hints. I use openbox + xterm + irssi. I do get notified if someone pings me, and I can also add any arbitrary words for which I would get notified. With a small Perl script I could use notify-send if I wanted (it probably already exists).

If you are really referring to phone notifications, well, you can use an IRC client on your phone, then you would get notifications on your phone. I use irssi even on my Android phone.

Let us not forget that there is the other side of the story: many people report that they have been enjoying life more without those phone notifications.

I love IRC. I have been using IRC ever since I was 11. It made me a more technical person. I find that IRC is not that easily accessible to the majority, which is a good thing, because of this, the conversations tend to be of higher quality, and technical in most channels. I would also like to add that IRC is the reason I understand English, and a zillion other things. :)

Persistent history including things that happened when you weren't connected. Obviously logging is easy, this isn't about client logs.

With phone notifications, you not only need to work for things that happened while not connected, it's bad form to require a permanent connection on android and you can't do it at all on an iphone.

We have https://thelounge.chat/ running.

I don't miss anything.

Yeah, there is https://www.irccloud.com/ as well, and probably many other alternatives.

Perhaps what you need is a bouncer?

It's doable but it's tricky, requires a very stable place to put the bouncer, and it makes things vastly more complicated than being pointed to the closest client or web interface and logging in instantly.

> We've gotten so used to phone notifications and a persistent history, that IRC has fallen behind purely from a convenience factor.

I noticed myself using IRC less for this reason. I'd always run weechat on servers so I had the history but never thought to look for notifications these days.

I signed up for IRCCloud and it's been nothing but excellent so far. I can even connect weechat to it like a BNC.

I feel like Matrix is basically the "real standard" here that supports a lot more than IRC. The question for me is about how easy it is to build a client for that (IRC is stupid easy, of course).

Ideally you should be able to build a Matrix client in something like a Python REPL and like 20 lines of code with an `input` loop at the end. I don't know if that's the case at the moment.

Ooooh... sounds like a fun challenge :D I've typed this out straight into the HN input box so it almost certainly doesn't work and will be full of typos and escaping bugs, but for illustrative purposes: here's what a ~8 line Matrix client for basic bi-directional chat in a given room could look like (complete with login) in almost-bash, with deps only on curl and jq:

    USERNAME='@whoever:matrix.org'; SERVER='https://matrix.org'; ROOM='#test:matrix.org'
    read -s -p "Password for $USERNAME:" PASSWORD
    TOKEN=`curl -X POST $SERVER/_matrix/client/r0/login --data "{ 'type': 'm.login.password', 'login': '$USERNAME', 'password': '$PASSWORD' }" | jq .access_token`
    ROOM_ID=`curl $SERVER/_matrix/client/r0/directory/room/$ROOM | jq .room_id`; curl "$SERVER/_matrix/client/r0/join/$ROOM_ID?access_token=$TOKEN"
    (while true; do SYNC=`curl -s $SERVER/_matrix/client/r0/sync?access_token=$TOKEN&timeout=30000&since=$SINCE`
     echo $SYNC | jq ".rooms.join.$ROOM_ID.timeline"
     SINCE=`echo $SYNC | jq .next_batch`; done) &
    while true; do read -p "<$USERNAME> " INPUT; `curl -s -X POST $SERVER/_matrix/client/r0/rooms/$ROOM_ID/m.room.message?access_token=$TOKEN --data "{ 'body': '$INPUT', 'msgtype': 'm.text'}"`; done

Spread out a bit more with comments:

    # set your matrix ID & server URL, and the room you want to chat in:
    USERNAME='@whoever:matrix.org'
    SERVER='https://matrix.org'
    ROOM='#test:matrix.org'

    # prompt for a password; log in and grab an access_token
    read -s -p "Password for $USERNAME:" PASSWORD
    TOKEN=`curl -X POST $SERVER/_matrix/client/r0/login --data "{ 'type': 'm.login.password', 'login': '$USERNAME', 'password': '$PASSWORD' }" | jq .access_token`

    # resolve the room alias (#test:matrix.org) to a room ID (!vfFxDRtZSSdspfTSEr:matrix.org)
    ROOM_ID=`curl $SERVER/_matrix/client/r0/directory/room/$ROOM | jq .room_id`

    # check that you're joined to the room (redundant if you know you're already there)
    curl "$SERVER/_matrix/client/r0/join/$ROOM_ID?access_token=$TOKEN"

    # set a background loop running to receive messages, and use jq to filter out the
    # messages for the room you care about from the sync response.  For now we print them
    # as JSON pretty-printed by jq, but that's not too bad.
    (while true;
        do SYNC=`curl -s $SERVER/_matrix/client/r0/sync?access_token=$TOKEN&timeout=30000&since=$SINCE`
        echo $SYNC | jq ".rooms.join.$ROOM_ID.timeline"
        SINCE=`echo $SYNC | jq .next_batch`
    done) &

    # set a foreground loop running to prompt for your own messages and send them
    # into the room as plaintext.
    while true;
        do read -p "<$USERNAME> " INPUT;
        `curl -s -X POST $SERVER/_matrix/client/r0/rooms/$ROOM_ID/m.room.message?access_token=$TOKEN --data "{ 'body': '$INPUT', 'msgtype': 'm.text'}"`
    done

If I have time I'll actually try running & debugging this to be usable and edit the post (but got to run into a meeting now :( ).

Needless to say, this'd be much prettier on Python - and you'd prolly want to use a nice SDK like https://github.com/poljar/matrix-nio (see https://matrix.org/blog/2019/07/03/usage-of-matrix-nio/) so you get things like E2E Encryption for free. But doing it in plain bash hopefully gives more of an idea.

Wow, definitely wasn’t expecting this! Very cool

I think it’s important to not be “using a library” since the test case is hopefully that the protocol is easy enough to get something barebones with even super baseline tools. Your bash script obviously matches this requirement

My reference here is the excellent Haskell Wiki “Build tour own IRC bot”. Really captures the simplicity of the protocol

https://wiki.haskell.org/Roll_your_own_IRC_bot

Nice! I tried this though and it asks me for a password (unsure if for creating an account or logging in to existing one, code suggests for login) and I tried both blank and random one, but get `Unrecognized request` as a response for the first request.

This seems to indicate it's missing a register step, and then it fails to be as simple as IRC where you just set nickname and connect to a server. Sometimes the server asks you to identify yourself, but that's up to the server, not the protocol.

yeah, sorry, i put a login stage in there but not a registration step (which is a bit more fiddly as registration typically requires solving a captcha to prevent spam). so you'd need to register via riot.im or some other client first.

That said, Matrix also supports guest accounts (which are quite locked down to prevent abuse, but would work for this example) - so the /login request could be replaced by calling /register with type=guest which would then do what you want.

edit: it would look something like this (7 lines now!):

    SERVER='https://matrix.org'; ROOM='#test:matrix.org'
    TOKEN=`curl -X POST $SERVER/_matrix/client/r0/register --data "{ 'kind': 'guest' }" | jq .access_token`
    ROOM_ID=`curl $SERVER/_matrix/client/r0/directory/room/$ROOM | jq .room_id`; curl "$SERVER/_matrix/client/r0/join/$ROOM_ID?access_token=$TOKEN"
    (while true; do SYNC=`curl -s $SERVER/_matrix/client/r0/sync?access_token=$TOKEN&timeout=30000&since=$SINCE`
     echo $SYNC | jq ".rooms.join.$ROOM_ID.timeline"
     SINCE=`echo $SYNC | jq .next_batch`; done) &
    while true; do read -p "> " INPUT; `curl -s -X POST $SERVER/_matrix/client/r0/rooms/$ROOM_ID/m.room.message?access_token=$TOKEN --data "{ 'body': '$INPUT', 'msgtype': 'm.text'}"`; done

Too late to edit the original post, but thanks to anoa for fixing up my crappy bash there's a version that actually works now at https://github.com/ara4n/random/blob/master/bashtrix.sh. The uglinesses are mainly bash's fault rather than matrix's ;P

comedy punchline; turns out that people are actually using this monstrosity in the wild:

> I used bashtrix for about 4 hours this morning. Why, you ask? I didn't have the bandwidth, latency or reliability to use Riot. I ended up using bashtrix on one of my servers through mosh...

> Could have done with scroll back (the screen fills up with 'null' and '[]' – the latter, I started to recognise as marking read receipts and/or perhaps presence) but shrank the font size down and made the most of it :p. Worked Rather well considering

Nice work! I've actually been working on writing something like this for a while now.

Do take a look at https://gitlab.com/darnir/matrix-shell-suite

It's a basic matrix client written in pure POSIX sh.

IRC is probably peak in its niche. Simple design, cheap to run, cruftless. Anything else added really lowers its value.

IRC is a pretty awful standard though. It works, through immense hacking effort but as (utterly under-) specified, it's a nightmare.

IRCv3 tries to fix a lot of those concerns and provides a lot of features long due. If you have any specific concerns not yet addressed by IRCv3 I'd start talking about it in the issue tracker.

I am hoping they go with Matrix, least then I will be able to have the choice of having a client appropriate to my needs.

I do prefer my chat client to not be a part of my browser. That way I can close my browser, start my browser and chat client on login ie from i3/sway etc. A tab in a browser runs the risk of getting closed.

I love using weechat (weechat.org) and have used it for decades. The Matrix plugin for Weechat is really well done https://github.com/poljar/weechat-matrix

Other people who want to use Riot can if they want at the end of the day I think matrix is probably the best option as it will cater for many people's needs.

> client to not be a part of my browser.

But that should also be an option too. Matrix could be great to integrate with for both private and public web communities , and that would incentivize people to create more homeservers. There is currently a lack of such solutions for communities and matrix could fill that gap. It's just sad that we have to end up sending people to sign up to discord .

weechat-matrix even supports single sign on login (as of yesterday: https://github.com/poljar/weechat-matrix/commit/1a846d61ae07...) so it should work nicely with Mozilla's IAM SSO: https://wiki.mozilla.org/IAM/Frequently_asked_questions

You really don't want Matrix. One year of Matrix to IRC bridge cost me about 30GB in Postgresql database to hold the state/logs of everything.

It was less than 500MB of plaintext irssi logs.

Did you figure out what's with the 60x bloat? Badly denormalized and storing tons of metadata? Storing images/video?

badly denormalised; every state change stored a snapshot of all the state in the room. so everytime someone joined a room it snapshotted the state of everyone else in the room. it has now been improved massively, and there is scope for further fixes. sorry that the GP got bit by it.

This too keeps improving

I've been on Freenode since my tweens. Maybe the long term thing is overlay protocols, to solve the issues with directly connecting to IRC on mobile, and with shelling into a client on the same.

It's great to see 3/4 of the options are open source! Whatever happens, I really hope the community get behind the open source options and don't let more things get eaten up by commercial silos cough slack cough.

I'm partial towards Matrix/Riot.im - the progress made on those projects is awesome and they really have a highly usable product, with bonuses such as e2e encryption and federation.

There's a fair bit of weight getting behind Matrix too, with the french government starting to use it for internal communication.

Yea! My next prospective smartphone is doubling down on Matrix: https://matrix.org/blog/2017/08/24/the-librem-5-from-purism-...

> they really have a highly usable product

Setting up a Matrix server is a lot harder than you might think, especially when you start talking about federation and identity management.

The mxisd[1] project has recently disbanded due to what I believe to be philosophical differences with the Matrix maintainers vision of identity management.

I like a lot of things about Riot/Synapse, but I would suggest you try setting up your own Matrix server if you haven't yet. It's not what I would call highly usable.

Mind you, I have only tried setting up the reference implementation (Synapse/Riot). I would be interested in seeing a write-up/comparison done by Mozilla as part of these trials.

[1] https://github.com/kamax-matrix/mxisd

I've actually had the opposite experience - it was easy enough to download/set up, and then it was just a matter of getting the letsencrypt daemon on the box to manage certs.

That said, I went in with pretty low expectations since it's a reference implementation - I think one of the great advantages of the open-source protocol is that anyone can design/build their own implementations with better UX on the sysadmin side. There are already projects in the works written in golang/rust, and I'm sure if the protocol takes off other languages will follow.

I do agree that the identity server piece is weird. I didn't set one of these up, so I haven't really looked into it (I don't have any 3rd party IDs connected to my matrix username, which from my cursory research is what the identity servers are for) but the philosophy behind them seems to go against the federation narrative the rest of the protocol is designed around. If anyone has done more research into this part of the protocol I'd love to be corrected on this point.

> is that anyone can design/build their own implementations with better UX

That's a common fallacy. Nobody is going to do for free this crucial work for a protocol that is practically unused. Teams should focus more on a strong implementation so the protocol gains ground

It was pretty straight forward to install/set up? There are some requirements to be able to federate, namely having a domain and associated certs for encryption, but otherwise nothing stood out as overtly obtuse/difficult.

You have to either make a venv for a binary or just install a package, then reverse proxy 2 ports from your http daemon, and finally also hook things up to your Postgres database. After all that it's just a matter of configuring your homeserver's config (which is large, but you can easily get support via the community for any poorly documented options)

The documentation could definitely be improved, though.

If you don't mind Docker, I success this ansible playbook: https://github.com/spantaleev/matrix-docker-ansible-deploy

Great documentation and sane defaults. I have only 6 lines of custom config.

there’s a successor fork to that identity server over at https://github.com/ma1uta/ma1sd which is being well maintained :)

sorry that setting up a homeserver was hard; we’ve been doing a lot of work recently to improve this (eg https://github.com/matrix-org/synapse-config-generator/tree/... is a graphical installer which should be released very shortly).

This looks good. Will this become part of matrix in the future (also, does it work /stable?)?

the config generator will ship in synapse by default in the near future. its first release is due tomorrow.

ma1sd is considered stable and works afaik, and is already part of the matrix ecosystem.

Thanks, I was not aware of ma1sd. I saw Gridepo but it seems to solve different problems.

I felt as though getting Matrix 95% up and running was relatively straight-forward, but I spent far too long trying to configure self-registration, email verification and domain whitelisting through mxisd that I gave up. These don't seem like uncommon scenarios for organisations wishing to run their own Matrix instance.

In contrast, a Mattermost instance that supported self-registration and domain whitelisting was up and running in almost no time.

The config generator will be a welcome addition. I will probably revisit Matrix some time in the future.

This is really frustrating. I was hoping I could replace ZNC with Matrix plus my own IRC bridge. Yes I know about Matrix's bridge.

You certainly can for individual use. My experience was more about setting up an enterprise-grade server with identity management.

Yeah that sucks. I wanted to integrate matrix to our community but no, it would be a bad decision at this time

Interesting. Yeah I've set up a synapse server and maintained a small instance for a while in the past. I didn't find it overly difficult, and I hear they've made usability improvements since then. I didn't try anything advanced with identity management though (and don't know much about it apart from the fact that it's not decentralized yet).

I actually switched my whole family to a private Matrix server after the Hangouts retirement announcement. It's got some rough edges (especially identity management) but it works well enough overall and it was the best option of all the chat apps I looked at.

Until Matrix/Riot resolves their problem of having a centralized identity server[0] I wouldn't recommend it.

[0]:https://gist.github.com/maxidorius/5736fd09c9194b7a6dc03b6b8...

Yeah that's true, if you wanted a private server a la mattermost/riot/slack, it wouldn't be ideal. However, I feel it's a decent tradeoff at present for what it's aiming for.

Matrix does not require a centralized identity server (which exists only for optionally discovering users on Matrix based on their email/phone numbers).

The linked gist is loudly complaining (amongst other things) that Riot's default config points at a centralised one by default.

We've already fixed this (https://github.com/vector-im/riot-web/issues/10553) by simply removing the concept of default identity servers entirely and instead prompting the user to select on demand whichever one they want to use, if they actually try to look up a user based on email/phone. It should be released in Riot 1.4 (on Web, and equivalent ones on mobile etc) in the coming weeks.

You can see our response to that original gist at https://matrix.org/blog/2019/06/30/tightening-up-privacy-in-..., and you can track progress over at https://vector-im.github.io/feature-dashboard/#/plan?label=p... (which has a cache from yesterday published at https://matrix.org/~matthew/privacy-sprint.html).

> I really hope the community get behind the open source options and don't let more things get eaten up by commercial silos cough slack cough.

Don't forget Slack also bans people who they think are from sanctioned countries:

https://www.theverge.com/2018/12/20/18150129/slack-iran-deac...

I would like to see a neutral platform be chosen to be honest.

Yeah wow that too. :O

> I would like to see a neutral platform be chosen to be honest.

Exactly, and if one of the FLOSS options are chosen, Mozilla could self-host and not need to rely on any third party.

Really excited to see Discord rejected. Watching Discord take over open source and free culture communities has been disheartening to say the least.

I've never heard of this but I'm not particularly in the field... Can you expand?

Rust is moving from irc to discord as a result of mozilla sunsetting their irc server. I know one datapoint is not a trend, but it's a high profile datapoint.

Rust has already moved to discord, but it's subject to evaluation and might as well change.

I doubt it'll change. The Rust team simply don't care about privacy.

They've been knowingly and willingly violating the GDPR since it came in to force despite constant reminders of that fact.

> They've been knowingly and willingly violating the GDPR

That's quite the inflamatory statement to throw out there without at least providing a source or two.

I'm guessing they are talking about this issue which has been open for a disturbingly long time: https://github.com/rust-lang/crates.io/issues/955

It seems to be grinding through to a conclusion. Google analytics has already been removed (2018).

Activity only started after the ICO made contact with them as a result of my complaint.

(I also have issues with how slow the ICO are at investigating, but that's a different story)

This is not accurate. I can agree that the process has been slow and frustrating, but that’s for us as well. We would have much preferred to have this all sorted a long time ago.

I won’t be able to say more than that, but I can’t stand by suggesting that we don’t care about this issue. I’ve been personally advocating for these things longer than that issue has been open.

If you've been personally advocating against the inertia of your team for a long time, I think that lends weight to the idea that "we" (the team) don't care about the issue so much. You do, but not the team you're part of.

That could be the case but the inertia doesn’t come from the team.

IPs and the account data you give them. And the complaint is not the collection, just that there's no listing that lets you know they collect IPs.

Seems extremely minor. I'm very far from disturbed.

Minor sure, but it's still illegal.

fwiw, the Embedded Rust Working Group moved to matrix: https://rust-embedded.github.io/blog/newsletter-18/

Conversly, I'm surpised that Slack made the list for similar reasons. I would've thought the would definitely want an open-source solution.

You must really dislike GitHub then.

I can't speak for the OP of this thread, but I agree with them and yes, I really dislike GitHub, too.

I can more or less easily get my data out of github (I can host a repo elsewhere, write a script to scrape the issues, etc.) I don't like using the non-git parts of it for much (ie why write a wiki when you can just make a repo full of markdown files?) Discord is a whole other level of walled garden. It's a black hole of information, and that information isn't owned by you. Discoverability is nonexistent.

> why write a wiki when you can just make a repo full of markdown files?

fyi: github wikis are just a repo full of markdown files. you can clone down your wiki, make changes, write commits, etc.

Except it is using Gollum, which isn't all that great. I think the only positive is tab integration. I prefer the GitHub or GitLab Pages approach.

Backup scripts also exist for Discord. You can also export your data. It really isn't much different than GitHub in that aspect.

Discord changed the communications of an entire generation, removed ideal low priority messaging and replaced it with a vulnerable and bloated service that now offers to sell you games and track your every move. Everything on Discord is unencrypted by design.

I think people are moving to discord as a stop-gap because they place user experience above everything else.

There's a lot of alternatives, but until they provide a good user experience, I don't see a point in purposefully making peoples' lives suck.

I'm confident that alternative's to discord will get better with time, but they're really not there yet.

I'm sad to see Zulip excluded from the list. It solves the #1 issue with large group chats - proper threading.

Nothing worse than waking up to a 1000 message backlog you have to sort through to filter out the information relevant to you. Except for Slack, all of their other choices have very poor threading.

They said they had trouble to get it working behind IAM, but Zulip is just a Django application. Surely there's a Django authenticator for Mozilla IAM? I would be very happy to help set it up.

> but Zulip is just a Django application.

Yet again:

> The installer expects Zulip to be the only thing running on the system; it will install system packages with apt (like nginx, postgresql, and redis) and configure them for its own use. We strongly recommend using either a fresh machine instance in a cloud provider, a fresh VM, or a dedicated machine. If you decide to disregard our advice and use a server that hosts other services, we can’t support you, but we do have some notes on issues you’ll encounter.

Mozilla is large enough that they could go over to the Zulip developers and ask nicely for what they need, and stand a good chance of getting it.

Even if it's just for a PoC with a 1/5th chance of being actually selected in the end?

What does PoC mean in this context?

Proof of Concept.

I'm going to guess 'Proof of Concept'

Zulip is open source, and the community is both large and very active. So at least they can open a github issue explaining the problem. And if they want to use the tool, they can just submit PRs like everybody else.

I lead the Zulip project, and we would definitely have been excited to do the work to make Zulip available. Unfortunately, they didn't contact us.

After seeing this blog post, I emailed the OP yesterday offering to add whatever they need to evaluate Zulip (which sounds like is just SAML authentication work that's was already on our near-term roadmap). He replied that they're too late in their evaluation process to consider Zulip :(. I really wish they'd thought to get in touch with us about this concern.

So why is that a problem ? I expect Mozilla IAM to handle VMs just fine.

Right, our recommendation is to run Zulip on a dedicated VM or container, which I'm sure is how Mozilla will install any self-hosted chat software.

For context, the background for that advice is that most folks who want Zulip to share with other systems are running a cheap "shared hosting" server with 5 different apps on it and without root access. Before we added that advice, more than 50% of requests for help installing Zulip were problems specific to that type of environment where the user wasn't going to succeed in any case (e.g. because they had an insufficient RAM quota from their hosting provider anyway).

There are reasonable use cases that would benefit from our investing in making this possible, but container technology is convenient enough in 2019 that it doesn't feel worth it over other high-value investments in making Zulip accessible to a wider audience.

It's $7 per user per month unless you are a favored open source project that they want to bless.

Unless I'm reading the pricing info[1] incorrectly, it seems like the free plan wouldn't be even close to being usable for a project of more than 2 people...

[1]: https://zulipchat.com/plans/

Our plans page reads:

"Zulip Cloud Standard is free for open source projects and affiliated institutions."

which I thought was unambiguous that our paid plan is free for open source projects.

The intent of our pricing model is to charge businesses $80/employee/year for use by full-time staff. If you're a business that can afford to hire people, you can definitely afford $80/employee/year (under <0.1% of that employee's all-in cost to the company) for a productivity tool. Our pricing is free for open source projects and highly discounted or free for situations where the users aren't full-time staff (e.g. education).

If there's something we could do to be more clear in our pricing page, I'd love to hear it.

Yeah, it's not clear to me. Do the limitations of the Free tier still apply to open-source projects?

It may help to just add a third box up top for Open Source or something. I didn't think that there would be a totally different tier listed below in the FAQs.

I lead the Zulip project, and am also super sad about this. There's a very active Zulip in the Rust community (https://rust-lang.zulipchat.com), and we love the great feedback we've gotten from them.

The "IAM problem" is apparently that Mozilla's IAM is based on SAML, which Zulip doesn't have native support for today. There are two possible technical solutions:

* One could use https://zulip.readthedocs.io/en/latest/production/authentica... with https://github.com/Uninett/mod_auth_mellon to integrate SAML authentication for Zulip without any code changes.

* One could add native support for it, using our `python-social-auth` integration. Generally adding an authentication provider supported by `python-social-auth` takes about 50 lines of mostly boilerplate code plus some tests -- not a big effort.

As I mentioned elsewhere in the thread, I sent OP an email yesterday offering for the Zulip core team to do any work required for Mozilla to evaluate Zulip over the next week so they can evaluate Zulip. He replied that it's too late to revisit their decision :(.

For other folks involved in open source projects, you should absolutely consider Zulip! We provide our paid plan completely free to open source projects, can import history from Slack and other tools, and are actively prioritizing features specifically for open source communities (like the ability to search the complete history of all public streams even as a user who just joined).

Open source projects that have switched consistently tell us that Zulip's topic-based threading is a way better model for a distributed community with a lot of volunteers than Slack/IRC/Gitter/etc., making it easier for maintainers to manage the community and helping more new contributors stick around. A few links:

* https://zulipchat.com/for/open-source/

* https://www.recurse.com/blog/112-how-rc-uses-zulip

Maybe Mozilla can put its weight behind Matrix and create a decent client that grandparents can use.

Integrate it into Thunderbird Chat... when I used it for gtalk/XMPP it was completely acceptable for basic use.

thunderbird has a primordial matrix plugin already, but it’s very much a proof of concept. there are plans to make it much more :)

I didn't know about the matrix plugin for Thunderbird chat! Now THIS would be awesome! Beyond the regular, dedicated clients for matrix, this type of partnership/integration is what Mozilla and (other FOSS) folks outside the matrix/riot org. should try and advocate for. Sure, this brings increased usage of matrix clients, platforms, but could also bring more eyes to the overall matrix project - continuing a virtuous cycle!

Why are they even considering Slack which is a proprietary IM service? Come on, they are Mozilla. Matrix which is federated and is proposed like a "better XMPP" is more like it.

Why should federation play into anything here? This is specifically something for people to talk to each other under the auspices of Mozilla's work efforts.

Non federated IMs are a major problem. So using them means proliferating this issue, instead of fixing it. It's not solved, because major players refuse to solve it even though they can. When Mozilla uses stuff like that, it gives them endorsement.

Write the server you wish you had, in Rust. Everyone will help. It will be great. Open source all the way.

If I'm not mistaken, there's a fully functional Matrix server written in Rust already (for example): https://github.com/ruma/ruma

Implementing a protocol in Rust is one thing, the choice in protocol is another. I for one hope they choose a standard that's backed by the OSS community (not slack), so we can all have fun with Rust implementations in peace.

It's not fully functional yet, would love to see more contributors hack on it though.

GNOME also has a Matrix client written in Rust: https://gitlab.gnome.org/GNOME/fractal

I think there are three problems here: first is that the new generation of developers that Mozilla is trying to attract are not used to systems which do not persistently store data in an API-accessible database backend.

Second that there is a perception of plain text as an antiquated medium of communication (and yet we persistently reinvent markdown as a way of simplifying rich text).

Third and most importantly, the issue is not that IRC is old or is missing features, it is that IRC encodes a specific model for running a communication network (hubs, leafs, operators, etc). When we try and replace IRC with a system like Matrix we are giving up the old model of "owned" nodes and the decentralised nature of it to instead bow to a centralised model where certain people wield absolute power. Is this really the right way? what if I want to write a bot to perform some unusual administrative function? do I have keep updating it every time the API changes? that's why IRC is good, I don't need to do that.

Huh? Matrix isn't a centralised model at all, quite the contrary. If anything, it's less centralised than IRC.

Excited to see what the results of their Matrix PoC. I have been a big fan of Matrix for a while.

Why move away from IRC at all? If it ain't broken why "fix" it.

For a lot of people IRC is "broken" when compared to modern alternatives.

I personally really dislike using IRC. I am in several IRC channels because some open source projects I use and upstream code to are on IRC. I dislike it very much.

Why?

No persistent presence, no true source-of-truth logging, bad authentiation - I mean, there's really nothing good about IRC unless you have a fetish for late '90s tech.

I would say a reasonable number of people consider the first two points to be features.

Late 90’s? More like late 80’s. I think my first IRC session was in 1991.

I’m making allowance for the way the protocol evolved a bit

Understood. I do prefer the simplicity of the IRC protocol... especially compared to say a monstrosity like XMPP / Jabber.

Isn't the authentication fine now? SSL?

It supports encryption but navigating what your client supports vs what the server supports is sufficiently finnicky that it can easily eat 5-10 minutes trying to set up, vs. plaintext which is easy. If someone non-technical had to get in, I'm not sure they could figure out enabling encryption on IRC in e.g. Pidgin which I've found to be a great client.

Everything you dislike about IRC is precisely what I like.

Nothing like firing up google to search for where you might find the chat for the server you happened to connect to so you can see what you missed while you were away or disconnected while waiting for someone in a different timezone to respond.

If you leave a room then you are no longer inside and you can't know what people inside were talking about while you weren't inside. As it should be.

There should probably be a distinction between "conference" and "room", where one is logged and one is not, but it can be argued that logging is an expected feature and access is a matter of the room being private or not. IRC doesn't work like this and many users are not exactly happy, which is why so many run their clients just for logging.

That makes tons of sense for rooms where you're in one or two at a time and have to be actively paying attention.

When it's intentionally simple to sit in 50 rooms 95% of the time, it's pretty stupid for a disconnection to make you lose out on random chunks, or for you to miss events because you wanted to turn off your computer.

When you intend to be always in a room, and the only roadblock is the inconveniences of modern tech, the logical state of "inside a room" should be decoupled from "has an active TCP connection". So sure you'd miss what people talk about if you left, but a disruption to your TCP connection would not trigger leaving.

The only reason why you want to get history is FOMO. A staple in modern software engagement.

Or you're trying to have an asynchronous conversation with someone and don't want to switch to email.

Or you're trying to have a normal conversation on a phone connection, or a flaky connection. Or switch to your phone in the middle.

Or you want to link something to a group of friends and you only want to send one message.

There are still old country bumpkin types with rotary phones..

There was lots of arguments about this in this thread: https://news.ycombinator.com/item?id=20324675

Because it's very not not broken, and here's the reasons why: http://exple.tive.org/blarg/2019/04/26/synchronous-text/

At some point you have to stop saying IRC is not broken.

You keep justifying it. If it weren't broken, you wouldn't spend all that time justifying it.

And what point is that. I haven't even started saying it, but I guess I'll start now. IRC is not broken. I've never tried to justify it so I guess that proves it.

IRC is a perfectly functional, crank-started horseless carriage. You can still drive places and gas up easily enough, but I’d still rather drive a Tesla.

My experiences as an infrequent IRC user over many years:

- hmm, I have to download a client? maybe I can access a web interface?

- okay, I have this connection string/url

- how do I join a channel?

- how do I set my nickname? is this persistent?

- oh someone else is using my name? is this for the channel or the server??

- what's the etiquette of this particular channel? (I realize this is probably the case for any chat, but it seems like etiquette is much more vaunted in IRC)

vs. zulip

- enter url in browser

- login with my github credentials

.... that's it

Requiring a browser and requiring social media credentials are both misfeatures in my book. Browsers are excellent tools.. for spying on users. And for as benign as github in particular may seem, we shouldn't be replacing standard internet protocols with products that promote and further normalize the expectation that people have a social media account.

> Requiring a browser

You realize we’re talking about Mozilla, right?

> requiring social media

They’re explicitly choosing between social media platforms...

My point is that any social media platform is not an acceptable IRC requirement, nor is requiring a social media account an acceptable requirement for any IRC requirement.

And Mozilla, more than perhaps anybody else, should be aware that web browsers facilitate surveillance of users.

IRC is a social media platform. The fact that it predates Github by two decades doesn’t mean it’s not social media. I don’t know know what you’re actually opposed to. A blanket disapproval of “social media” isn’t particularly meaningful, so there’s nothing of substance in your complaint to respond to.

I have no idea why you think browsers are a tool to facilitate surveillance to a greater extent than dedicated clients. If a nation state or corporation can compromise your browser, they can realistically compromise your entire OS.

I think you know exactly what I'm referring to and are trying to drag the conversation into the weeds of vocabulary pedantry. I am of course talking about internet companies who turn user data into an asset. The facebooks, twitters, linkedins (same owner as github) etc of the world. You know that's what I'm talking about. Freenode is a far cry from facebook.

>I have no idea why you think browsers are a tool to facilitate surveillance to a greater extent than dedicated clients.

Because that's simply factually the case? IRC networks do not give my IRC client proprietary tracking scripts to run. With an IRC client if any third party code execution occurs, it's due to an exploit in the client. On the other hand with web browsers, servers sending malicious scripts for the browser to run is par for the course.

Typical modern web browsers (even Mozilla's own) are total disasters, particularly in their default configuration. Why the hell aren't they shipping with resist-fingerprinting turned on by default? Because it would mildly inconvenience some users, and despite all their good intentions and positive words, they still prioritize user perception of convenience over privacy.

Considering the fact that they disqualified several options for not working with Mozilla IAM, I doubt they'll be requiring social media login.

Nothing prevents a nearly identical frontend to IRC.

Would love to see one.

requiring a single commercial entity like github is a really bad idea. Sure it'll be fine for a few years but when github goes belly up or gets bought and the new CEO cuts all extraneous projects, then you're hosed.

You realize they're owned by Microsoft yes?

That's counting on Microsoft taking good care of GitHub and maintaining its goodwill.

It might or might not be well managed in the years to come. Case in point, Skype. It was "the" tool to use for office communication. Hardly anyone I know uses Skype nowadays.

Skype is still pretty big in the enterprise chat space.

Sadly yes, because big businesses with insufficient concern for maintaining openness on the internet keep choosing siloed proprietary communication services, just because they're "more polished".

cough Mozilla cough Slack cough

These are all advantages to me.

I admit, I never used zulip -- I don't like using chat from the browser, so I generally stick to things that I can connect to from chat clients.

- What does it replace channels with?

- How does it keep my github account separate from the identity I'm using in chat?

- How does it avoid etiquette in channels?

- Does it let me ignore or mute annoying people?

- Is it possible to easily archive communication for posterity?

Zulip uses three classes of communication: Streams which are like IRC channels; each stream has named threads (users are encouraged to reuse or start new ones as appropriate); and private messages can be 1:1 or multiparty.

Zulip doesn't do anything with github other than the regex-based integration -- you can create links more easily, that's it.

Nothing avoids etiquette or enforces etiquette except people.

Muting can be applied to people or named threads.

Zulip defaults to full archiving of everything, and making it searchable as well.

> Nothing avoids etiquette or enforces etiquette except people.

So why is it listed as an IRC specific problem?

> Zulip defaults to full archiving of everything, and making it searchable as well.

I have IRC logs from dead networks dating from over 15 years ago, and I still sometimes look things up in them. I don't want to trust Zulip to survive 15 years.

> I don't want to trust Zulip to survive 15 years.

You don't need to, we have an official tool that generates an HTML archive: https://github.com/zulip/zulip_archive. We recently adopted it from the great folks at the Lean Prover community, but we have plans to make it a lot nicer over the next couple months.

That said, one of Zulip's central technical design principles is to invest in making a codebase that is easy to understand, well-documented, and readable, with the goal of ensuring Zulip is able to thrive for the next 15 years and beyond.

I've been meaning to write a series of blog posts on the topic, but check out the 150K words of mostly Zulip developer-facing documentation on our ReadTheDocs:

https://zulip.readthedocs.io/en/latest/overview/readme.html

> Nothing avoids etiquette or enforces etiquette except people.

So why is it listed as an IRC specific problem?

> Zulip defaults to full archiving of everything, and making it searchable as well.

I have IRC logs from dead networks dating from over 15 years ago, and I still sometimes look things up in them. I don't want to trust Zulip to survive 15 years.

> Zulip doesn't do anything with github other than the regex-based integration

I see. The parent poster implied that there's no need to pick a username, and that he logs in with GitHub. That implied that it used your GitHub account name, since I don't see another way to enforce unique names.

Zulip uses your full name as the primary identifier facing other users. Depending on the organization's configuration, a user's email address may or may not be available as well, but we just need your name (and auto-generated user ID) to display messages.

https://zulipchat.com/help/restrict-visibility-of-email-addr...

> hmm, I have to download a client? maybe I can access a web interface?

irccloud.com

> okay, I have this connection string/url

No? What clients are you using that don't have an exhaustive network list in them?

> how do I join a channel?

The same way you do in Slack and other alternatives: you look at the channel list

> how do I set my nickname? ...

A good client, such as IRC Cloud, makes setting your nick name easy. Don't be lazy. Learn to use tools.

> ... is this persistent?

Yes, if you register it, and it's easier to register an IRC nickname than it is an account on virtually every other platform - no email/verification required.

> oh someone else is using my name? is this for the channel or the server??

lol?

> what's the etiquette of this particular channel?

That's an actual, serious reason you're put off from IRC?

Based on my infrequent use of IRC, I am not interested in investing in learning the tools - which by the way change quite a bit over a few decades.

On the other hand, the same usage pattern with other chat apps such as Zulip/Slack/Mattermost and others requires no specialized knowledge.

irccloud.com looks great, except for the fact that you have to pay if you don't want to be kicked off after 2 hours of inactivity.

> irccloud.com looks great, except for the fact that you have to pay

Yes, people need to eat. Sorry about that.

"I have a question and there are a few people about so I'll ask it....(10 mins later)... ok no-one's answered... no-one's said anything, in fact. I hope they can see me. Oh well, I'll just browse away from this tab/close the IRC client and just reconnect later on or tomorrow and see if there's an answer. I'll just reconnect and scroll back up and see all the history I missed. It'll be fine... (next day)...Uh...where's my history?"

IRC might be considered broken in a number of ways, but I find that every proposed replacement is broken in much more severe ways.

Lately I've been thinking about how amazingly successful IRC has been. I mean, it survived the "web" and smartphones as long as it did.

Up until slack appeared on the scene. I was a heavy IRCer from '96 to '13, and then switched almost immediately to slack.

Slack sucks in a lot of ways but it happens to hit the sweet point of convenience. It allows me to be a purely 'casual' chatter, I can close and open slack anytime. I don't have to keep irssi running in a screen in the background. I don't have to have a bouncer.

Anyways I think that if a new version of IRC came out with extra convenience for the pure 'casual' user, then we'd all go back to IRC.

> I don't have to have a bouncer.

By some odd twist of fate, WSL is what enables my IRC use. My only 24/7 PC is my HTPC/Plex server, which I also run ZNC on via WSL.

> It allows me to be a purely 'casual' chatter, I can close and open slack anytime. I don't have to keep irssi running in a screen in the background. I don't have to have a bouncer.

What's the barrier to a SaaS IRC solution like irccloud?

I paid for IRCCloud for 2 years (I think)

* General instability - I got plenty of notifications that the connection to Freenode had been dropped

* A couple of channels outright banned me for connecting from an IRCCloud host.

Not everyone Mozilla hires is from a super technical background (ex: even though I now am a pentester, I actually did a UX research internship, wasn't hired to do software engineering at all). I wish they'd kept it around though, let the community die a natural death: slowly bleeding out as zoomers share memes in signal groups.

The young peeps like their icons and colors and gifs. Old people are always dying off and young people who turn into old people tend to bring their toys along with them, so I forsee something like slack/discord but OSS taking over in the next 10 years, at least in programming circles.

Please, having an usable, secure IRC setup is quite annoying, nothing to do with "icons and colors and gifs" (but difficulty at viewing that content in IRC clients could be counted as a negative). Also, some of the most active channels on a few IRC networks are primarily ~20-30yo people, maybe there are older-people channels but I suspect there's a few barriers at getting access to those.

I think the reason they are moving is that it is broken for them. IRC is fine if you are over forty and have been using IRC for the last few decades. I.e. it is not fine for most developers who are around 30 and have probably never encountered it professionally. The demographics of software development are such that people over forty are out numbered by an order of magnitude by younger people. There just aren't a lot of them.

I am over forty, I have used IRC professionally, and have not encountered it with any regularity in the last decade (that is to say exactly 0 times in the last six years). I can understand it's a non starter for younger developers as it is an unusable mess compared to other stuff they use. I suspect that part of the reason Mozilla is switching is that they realized people in their community were working around it already.

The real thing people should be asking about IRC is why attempts to fix, improve, or modernize it consistently get rejected by IRC users. It has not kept up and it isn't for a lack of trying. There have been many attempts to keep it alive and they all keep failing. E.g. slack had an IRC gateway for a while and this proved so unpopular that removing it was barely noticed by anyone. It was there but mostly unloved by IRC users. People voted with their feet by not using it. Now it's gone because apparently it was an unimportant/redundant/irrelevant feature with no commercial value whatsoever for Slack.

People want interactive web forums that offer notifications and offer thread/channel history from an accessible front end.

The statement I just made sounds like an absurd product but they exist. The weird part is everyone is trying to build it completely in javascript.

For what it's worth, I'm in my 20s and love IRC. I do also use matrix and xmpp, but they aren't as fast and comfortable. I love how irc logs work. I have everything stored locally and can search it very quickly with grep. I'm always frustrated with the search of other things, both for being slow and for not finding what I know is there.

Stuff like multi-line posts and markdown are nice, but none of that is worth all the good stuff you lose from irc.

- not invented here

- difficult to monetize

- designed only as a communications medium, not a social medium

- doesn't work like other phone apps

- does not support multimedia or cat ears

The previous post explains why IRC is ‘broken’, so to speak. http://exple.tive.org/blarg/2019/05/14/the-next-part-of-the-...

Clicked on this thinking Mozilla were backing a new, more secure and usable version of a protocol _like_ IRC, and disappointed with the reality.

They can make it a reality by backing the Matrix.org protocol, or even Ruma, the Rust implementation.

Interesting. Any good resources on Matrix? How has adoption been going until now?

France and KDE are probably the two most well known adopters rn last time I heard. https://matrix.org explains the protocol, and if you join the MatrixHQ room (#matrix:matrix.org) you can ask all you want, lots of people around to answer, and even Matthew (project lead) is often on there too.

Adoption is going pretty well - from matrix.org we see around 10M mxids out there, of which around 5M are on the matrix.org server. Many of these on the matrix.org server are bridged from other systems (Slack, IRC, etc), but 3.5M are native to Matrix. It's hard to guess how big the wider network is because there are many folks who don't phone home or federate actively with matrix.org.

Slack, really?

There should be a petition to get them to use ( and thus improve) an open source one, maybe matrix or even rocketchat.

Keybase Chat would make a solid choice as well. *I work for Keybase, but chose to work here because I love the mission / product.

Keybase chat doesn't have a server client available. It is nothing like IRC.

Actually there's a bot available https://github.com/keybase/bot-sshca in addition to the regular CLI API keybase has.

What does this have to do with keybase chat?

The link I posted is basically a headless server client, was that not what you asked for?

I love Keybase. I wish it was fully open source though. And that group chats weren't slow as sin.

Yeah, it has some usability concerns, not yet at the level of Slack for large group work or onboarding speed, but I've found it very good for smaller groups of people and the rest of the features they've built on it are very cool and useful (at least for me).

My choice would be Keybase, or at least something that uses Keybase as its back-end in some way.

Just want to say that I adore Keybase. I think it needs a password manager like bitwarden/lastpass/1password, but a lot of the features are compelling to me. I really hope it gets widespread adoption because the app and the company deserve it, in my opinion.

Man, i sure hope they go the route of matrix! Between the French government and Mozilla both potentially using matrix, would send a great and strong signal to the world, that matrix can work for everyone! Fingers crossed!

If the author of this blog post reads this:

Based on your earlier article, you mentioned the issue of spam. Slack is even worse than IRC for spam controls, I've seen spammers be hugely disruptive when the admins aren't around. It could be partially solved with bots, but that doesn't stop PM spam.

I looked at the docs for mattermost, riot.im, and rocket.chat.

Seems like rocket.chat has the best docs and lots of fine-grained control about permissions and also has rate limiting. Mattermost also has rate limiting (but API level only?) but their docs are horrible. Riot.im doesn't seem to have any controls.

Matrix/Riot has a lot of anti-abuse stuff fwiw - https://matrix.org/docs/guides/moderation has more details, and we're about to launch a shared blacklist feature in addition.

Adoption of IRCv3 by someone like Mozilla could be the push it needs.

10 bucks on Slack

https://youtu.be/xJ2XUNvbJtg

Mirror: https://web.archive.org/web/20190912012052/https://exple.tiv...

It's interesting to me that no-one here mentions Mattermost. Is it not in widespread use?

I've read somewhere that matrix server uses too much RAM due to bad design.

Personally I'd prefer XMPP.

It's not a bad design, it's just the reference implementation is python based, and, well, a reference implementation; so they don't do too much for optimisations and focus instead on readability.

When Matrix as a protocol settles more, we'll start seeing optimised versions of the server, I'm certain of it.

dendrite, the next-gen server written in go, made good progress this summer thanks to GSoC, but contributions are always welcome

The current reference implementation, Synapse (Python) seems to take up around 2GB of RAM, Dendrite (Golang) rn uses up to 100MB according to Matthew (project lead). Note that Dendrite is still a WIP. Currently I don't think anyone is too sure about how Ruma (Rust) would perform as it is still very early in development.

I'm surprised jabber wasn't even mentioned in the "also ran" section.

Could you share more about why you are surprised?

thinking out loud here, but has anyone built a solution on top of IRC, effectively "extending" it?

to me (i'm not a developer, so pardon me while i speak out of turn here) it would make a lot of sense to take the solid, well known foundation of IRC and build upon it, instead of reinventing the wheel over and over again, no?

It's probably not a good example but that is what Twitch did, you can connect to their video channels with standard IRC clients (without the added "features" like paid subscription picture "emotes").

Why does IRC need a successor?

That is answered here: http://exple.tive.org/blarg/2019/05/14/the-next-part-of-the-...

Why the hell they have slack and not discord eludes me.

You're right. Neither of them are good candidates.

As per the article: "Discord’s terms of service, particularly with respect to the rights they assert over participants’ data, are expansive and very grabby, effectively giving them unlimited rights to do anything they want with anything we put into their service. Coupling that with their active hostility towards interoperability and alternative clients has disqualified them as a community platform."

They even made customizing the Discord client in any way against the ToS. The hostility toward interop is the one thing I really dislike about them. They do so much else well.

Reply on news.ycombinator.com