I regularly speak to people like that, who just plain refuse (are unable?) to even see the difference between a chat like slack (or telegram, or mattermost, or or or...) where I can post images/videos inline, use proper markup etc, and a combination of IRC and email. "But you can just send images by mail!" they shout. Yes, you can. But the user experience will be a different one. And it doesn't even matter that I personally prefer the slack-like UX. Many other people seem to prefer it too, that's what matters. For anyone who's only mildly technical, setting up IRC is only a small hurdle, but it's one of many.

IMHO, if you want people to use anything else but slack, sticking your head in the sand and screaming "you can do all of that in IRC" won't get you anywhere and is equivalent to complaining about the very nature of humanity. It might feel good to scream out your weltschmerz, but it won't change anything.

I'm 39. I've been in technology in a professional capacity for 22 years, longer now than perhaps a few folks on HN have been alive. I wrote my first computer programs over 30 years ago, started online with local BBSs and then eWorld and then the internet.

I've seen a lot of stuff come and go. The tech industry as a whole has, over the last decade, adopted an especially frenzied pace that looks an awful lot like someone lost in the woods, freaking out, running in different directions trying to figure out where they've been and where they're supposed to be going.

There's nobody I can wag a finger at and say, "see, you didn't learn the last time 'round", because with a constant influx of new people, there's always a big group of folks that will adopt the latest thing because it's the latest thing, and have no memory of the last 30 years of latest things, and haven't been stung before when the latest thing fizzles out and takes a chunk of your time or infrastructure investment along with it.

Slack had advantages, sure. But it's hardly the first time that some service has come along and offered advantages over the tired old thing -- all except for a public, common protocol -- and then decided to take their ball and go home and to hell with everyone else. My staid desire for things being built on open protocols and available to people who want to self-host it doesn't come from some hardnosed ideology, it comes from years of, "oh no, this shit again."

Unfortunately, comments like yours tend to dismissively shout down the comments from the been-there-done-that folks, and so we're locked in a particularly self-defeating Eternal September that's costing the tech industry an incalculable amount of money.

In my more cynical moments, I wonder if a cadre of old farts oughtta start getting together and giving the less experienced folks the advice they want to hear, just to see how long it takes them to catch on: "building infrastructure out of walled gardens is a good idea, because they are commercial businesses and will be able to offer you more features than the slow-moving open source alternatives that haven't changed much in a long time".

This starts off strong, but then ...

>I'm 39. I've been in technology in a professional capacity for 22 years, longer now than perhaps a few folks on HN have been alive. I wrote my first computer programs over 30 years ago, started online with local BBSs and then eWorld and then the internet.

If I were typing this in slack, this is where the first :facepalm: emoji would appear.

This is the mentality that caused the now-semi-famous HN post in the early days of dropbox, arguing that it was useless because with a combination of [ simple CLI tools that nontechnical people have never even heard of ], you could create the "same" functionality.

Say it with me: Being so simple that utterly nontechnical people can use (edit: not just 'use', but 'deploy and administer') IS important functionality. That's what made Dropbox, and it's what's made Slack. You don't have to be an IT pro to deploy it successfully. You don't have to be a programmer. You just click half a dozen buttons, all of which are helpfully color coded so that your unwillingness to read any text on the screen won't be an obstacle.

Yes, there are things you lose when you "build infrastructure out of walled gardens" -- but the reason some people prefer cathedrals vs bazaars is that they often have much lower barriers to entry, and for many people that is a worthwhile tradeoff.

> the reason some people prefer cathedrals vs bazaars is that they often have much lower barriers to entry

There's nothing inherit about these "cathedrals" that require them to be walled gardens. Slack could have been an open protocol, but they decided not to be.

But would you say that they're _not_ investing in the product? They're improving on search, their API, adding new integrations with Github, etc. Those might not be the things that matter the most to you or other HN users, but they are investments in the product.

Have you used their client?

nit: inherent.

That's a strawman - no one said dropbox was useless to everyone: this is not about how simple it is to replicate the functionality, but who controls the data. The point gp was raising is that surrendering control your data to a 3rd party company has costs most people do not consider until it's too late - and this happens time and again ("oh no, this shit again"). How many stories have you read about downtime, account bans/freezes, and companies winding down or sold with little or no notice and no way to retrieve your data? Is it a worthy tradeoff for a shiny UI?

But, they handled it well and they've never screwed over their users and they have partially resolved the long-standing file transfer problem (https://xkcd.com/949/).

So I still have those concerns, but overall it's a great service and I've recommended it to a few folks over the years.

It helps also that there are some open alternatives on the scene now, so if you make Dropbox some critical part of your infrastructure, it's feasible to switch to something else if Dropbox suddenly decides they want to focus only on the smartphone market.

Slack had the ease-of-use and feature advantages -- which I acknowledged -- but it was too young and there were no open alternatives that matched it feature-for-feature. That made it dangerous to rely on too much. i.e., I'd still use it, but I wouldn't make it the de facto communication system for a company.

So yes, a bunch of "old farts" are a good a necessary corrective in our hype-driven environment. I agree with the assessment that slack is just another walled garden and comes with all the problems those bring. I even agree with the "open protocol, optionally self-hosted" conclusion. I just don't like the conclusion (not explicitely stated by you, but definitely by others) that that open protocol should be IRC and email, and that the UI for them needs to be pure text.

Put a bit shorter: the people have chosen between $SLACK over $OLD_STUFF, so if you want to use something open and still sway them then you'll have to change what's on offer vs slack.

Converse.js looks like a prime example of doing just that, as does e.g. conversations. I'd much rather we get our shit together and build jabber into something usable and beautiful than go back to IRC and email.

I work with a guy like that. I've got a lot of respect for him, but yes, his approach to things causes a lot of headaches for other techs in the company. (He likes to send config files by email ... inline, after gzipping and base64-ing them.)

There's a middleground. If more people tried harder to rely on software they could truly own, vs SaaS, it would force more companies to release open source APIs and libraries and all but the crankiest old farts would shut up.

I like things to be easy too, but not so much when it bites me in the ass later.

Your suggestion for extending jabber seems reasonable.

Year of the Linux desktop never happened, KDE semantic desktop never happened, Python in Chrome never happened, Self never took off, Lisp never took off, we're still writing coffee like we did in the 90s. Nothing happened as much as we hoped it would and we have to just go with what we've got.

This year I'm dropping Linux at gone and going to Windows, after 15 years.

Kinda funny since I feel like windows is taking more and more weird turns since windows 8 regarding UX, UI consistence etc. From win 95 to win 7 it mostly felt like consistent evolution, but now it seems they tried to modernize different parts of the OS over night and none of the designers and devs involved were allowed to talk to each other.

I think the "fuck it I'm old, don't care anymore, just want it to work and look nice" goto solution is still the Mac, even in 2018, even after all those recent os x mess ups (I'm old, don't care, etc., get it?)

I think there's a simpler explanation: people are trying to find new business models. The old model of individuals paying tens or hundreds of dollars for software is slowly dying, and it's on full display in the iOS app store where even $5 is perceived to be a lot to charge for an app. So we need new models. The rise of SaaS is tied to that shift. in-app purchases and related psychological shenanigans are related to that shift.

The SV elders, like Peter Thiel of Palantir, now more than ever seem to favor rent-seeking business models and started selecting for those businesses 5 years ago. To course-correct, someone in technology will have to discover a new business model. I'm personally betting that we'll see a backlash and new models wherein people pay so there is no chance of data harvesting (going back from SaaS to standalone software)

I don't believe there is a dichotomy between IRC and Slack. In fact, Rocket Chat and Mattermost show that locally hosted platforms can be developed openly and serve a similar purpose.

    What has been will be again,
    what has been done will be done again;
    there is nothing new under the sun.

The truth is that no closed platform will ever reach the universality that email has. The prevalence of various chat platforms looks like a race to replace sms. At the current rate, there may be no winners, and only losers.

I think he was talking about HN users who argue that IRC does everything slack does.

He's definitely honing in on a group of people who should support federated solutions and instead evangelized the opposite. Ironically there's a similar frustration with using the proprietary GitHub service rather than open source git sites like GitLab

That's the right answer, I'm very skeptical of people saying "this can be done in XMPP" but when it comes to the actual implementation it falls short

Edit: also note the author updated the article and Emoji Reactions are still not supported in XMPP but are in development

My understanding is that many of IRCCloud's Slack-like features are based on the open IRCv3 standard. If this standard ever takes off (fingers crossed...), IRCCloud will have a lot less vendor lock-in than Slack does.

Hard to imagine it will for Slack's audience. Slack is serving the case for the non-technical folk extraordinarily well right now. A significant amount of their user base doesn't care about standards or IRC channels. They just want a consistent, well-designed product that does the things they need it to for work. They've never opened a terminal in their life and they don't need the terminal-irc-gateway that this recent change has killed off.

But many IT departments require on-premise hosting, which Slack doesn't offer. Users don't care about open standards, but maybe their sysadmins do. If IRCv3 can capture this audience, it has a chance to co-exist with Slack.

Less and less IT departments do that now, since so many things move to the cloud. When you have all your stuff in Gmail and Google Docs already, having Slack is a no-brainer.

In the meantime people will chose other platforms that provide better and more consistent experiences.

[1] https://gultsch.de/xmpp_2016.html

E-mail is about as terrible as IRC and yet it just won't die.

At least with email you're able to send messages to those on different "networks".

https://riot.im/

https://matrix.org/

Did we read the same article? This article had nothing do do with IRC knee-jerk reactionaries.

The author's main point is that Slack results in a walled garden and information silo'ing of our conversations.

The author then went on to provide a potential antidote to that problem by discussing a javascript project they been working on.

This is not what the article says. The article says clearly that everyone knows we want these fancy UIs in open chat apps. But the problem is funding. You need to pay 10+ developers, each costing between $100k and $200k (50-100 without tax) for 1-3 years to get such a nifty UI and after that you still need 1-3 devs each year to keep up with all the changes in the IT world. Someone needs to PAY that to get such a nifty UI.

The article also argues correctly that you are currently paying for it by giving away your data which is worth a lot more than a few 100k USD/year. And all you get is a more nifty UI. Wow.

And instead of understanding that you are exploited you complain about how stupid the people are that fight for protection of your values. That is REALLY stupid. The same level a child complaining about needing to go to bed early than the parents while the loud and colorful ads try to keep the child in front of the TV until 2 am or longer.

Start acting like a grown up.

I challenge you to do it better. Ah, screw that. I don't think you can, the way you talk. I challenge you to do something much simper: Read an RFC and try to provide interview style non-compiling code to implement it, then write a single blog post explaining what you did, applying a correct and reasonable free license to your source code and your blog post. That's something an untalented hobby programmer can do if he puts his mind to it.

Still, he is stil "working on it". While Slack has already "delivered".

It is childish to say that whatever feature Slack has is "simply" something that can "just" be added to XMPP.

To me, the author's complaint of how Slack rips users of is the same as customer who complains when it takes month to "just" add a feature.

He himself hasn't even done it. He planned to do it, anybody can plan to do things. Anyone can be working on something that will change the world. Only few delivers. He complain about funding, while he is adding feature that he claimed was "simple".

Why does simple feature needs funding? And if Slack is ripping people of on feature that can simply be added on XMPP, then put your house on loan, create better XMPP client and earns millions of dollars. You don't need funding. That's what being adult is.

What if they do see the difference and don't see the value in it? This is worth considering.

> where I can post images/videos inline, use proper markup etc

I don't want someone else putting inline videos or markup into my feed. In IRC people post links, most of which I happily ignore at very low cost because they're not important to anything.

That is of course your personal choice, no arguing with it. I'm thinking of projects where communicating with/about videos and images is an integral part of the work. Think image processing for example. In that context a message of the kind "Hey, I tried this new method, look what I got as a result [image]" can make tons of sense.

If you don't need images, you don't have to use them. If the person on the other end of the chat insists on sending them anyway, why are you talking to them? :P

That’s absolutely ok, as long as they understand that and that at some point the value is in network effects too

We'd likely still need a client wrapper on top of it all.

I think ideally such a client could be implemented as a plugin to an extensible terminal emulator, which might help to keep the project small and prevent Jabberification.

There are quite a few IRC clients that do this automatically, fwiw.

"..just plain refuse (are unable?) to even see the difference between a chat like slack. ...the user experience will be a different one."

Underlying this is (unusually) a way some technical people think, and the way most bureaucracies think. Bureaucracies will often "checklist" requirements, see that it does all the things "users have identified as important," use cases they think these apply to and go on that information alone. They only consider stuff that is tangible & legible.

By that checklist method email, whatsapp, Twitter, slack are IRC and such are essentially the same. Some may tick a.minor box that the other does not, but basically they all get messages from A to B (sometimes to B, C & D).

It's even worse in this case, because slack is social software and the conventions people form as users are very impactful on the UX. This compounds differences.

When Dropbox was originally announced in a "Show HN" someone said:

   You can already build such a system yourself quite trivially by getting an FTP account, mounting it locally with curlftpfs, and then using SVN or CVS on the mounted filesystem.

Work had a private irc server that required all sorts of client certificates to join, forget non-technical people -- it wasn't very good for technical people either!

For the record, I don't like Slack very much. I just disagree that IRC or IRCCloud are acceptable alternatives.

On spot. People are lured in by hype and forget the long-term consequences. Always chose “open” by design, never by charity.

As they say: Use it or lose it.

It's designed with termination in mind.

Given that, “moderation nightmare” is not really a concern for the target audience since if your company needs moderation in its work chat, you have much bigger problems.

[1] https://slack.com/

The company I currently work for was very hesitant of adopting it, and they only did the moment our sales people started asking for it. And as a productivity tool it's great, but there is obviously a lock-in.

Additionally the traditional mailing lists are full of "please can I have an invite to the Slack workspace" spam

I suppose it'd be better to build a slack clone based on xmpp.

If Slack dies for any of the above reasons, that won't cause people's need for a solution to disappear. I imagine Mattermost would survive just fine. If Mattermost dies, it will be because something came along that's better, similar to how I started out with ICQ, then jumped to MSN Messenger, and now I'm on Whatsapp, WeChat, Kakao Talk, Slack, and Mattermost. Same for Slack. If Slack dies because of better competition, perhaps we'll shift to that away from Mattermost. Who knows?

Gah, how is it possible that the number of chat clients I use keeps growing?

edit: typo

Any caveats, gotchas or hidden complexities to be aware of?

Should be quite trivial to build also, and cheap enough to run as a bit of charity if projects pay for their own storage.

The two I regularly encounter (which shared storage fixes) is either moving to a different device (or trying to remember which ones have which bits of history on) and also integrating new team members.

The latter is especially important if you're doing anything technical/support related; if you've had 2 days of discussions and want to add someone else in, they need the history, not for you to try and cherry pick the important bits of the last few hours to then fail to get them upto speed.

Slack might cut it off, but they gain nothing by doing it.

There's a lot to like in Discord, and it rapidly became the go to client for all my gaming related friends and activities, but it suffers from the same root pitfalls that Slack always has. It will inevitably run out of VC money (or whatever they're spending now) at some point and start wanting to actually turn a profit.

I sure do hope this is sarcasm. Surely you do know this can go away at any time.

The problem with better chat is that it's better, so you spend more time on it.

I see the hosted version is down, though.

Slack recognizes, unfortunately before most of it's customers, that the history is one of the most important assets of a company -- it is the shared institutional knowledge, the thousands of hard-won lessons of all the things that can go wrong that are now fixed, and how they were fixed. This institutional knowledge is not only in the heads of the workers, but also in the papers, and many would need, or at least benefit from, a lookup of the details to re-use that knowledge.

This institutional knowledge is a key competitive advantage of almost every company.

This business model of capturing it and rent-seeking on selling it back to them is a devil's bargain.

"Here's this really slick UI for free, only costs a bit later... nevermind that we'll own the soul of your company and you'll need to pay us tribute in perpetuity..."

It turns out that people don't necessarily want lots of records of everything everywhere.

https://riot.im/

https://matrix.org/

Register matrix.org accounts there. There's a web client, desktop clients and mobile clients (called Riot.im). It's open source and federated. And, there are IRC bridges!

You don't have to host your own server.

https://movim.eu/ is another option (has a fancy web client, android & linux client and of course supports any XMPP client)

What I do dislike though is, as Slack is invite only (the software is designed for "Teams" in workplaces, not public forums) you have to explicitly request access from the admins and this is often via the mailing lists.

The disadvantage is that it would require one to create an account on another server instead of just using one's existing email account for communication.

As for explaining and availability, I believe the vast majority of people would use search engine to figure out what steps are involved once something like that is mentioned.

It is unbelievably painful to build integrations that cater to the regular client (users want forms, buttons, dropdowns, etc) that have clean fallbacks for text-only clients (at best 1% of your users). The real reason they're dropping support is because it will make it easier for developers to build in their ecosystem. That's it.

That said, we shouldn't let Slack off easy - there are many basic issues that seem to plague Slack and Slack alone (ex. I can't believe this is an issue, but it seems nearly every message I try to send through iOS rich notifications fails to send). We should demand better, but an IRC or XMPP gateway is not the fight to pick.

P.S. If you're in high school, you should join our relatively active Slack community at https://slack.hackclub.com - started as an IRC community and switched when our members started demanding a decent mobile client.

Open-source project communities should not be using Slack, if for no reason other than the 10k message limit and the fact that it's annoying to be present in multiple Slacks. I prefer IRC or Gitter for those communities, as they're better designed around the flow of "drop in, drop out" than Slack.

The more developers you hire, the higher the chance you'll start collecting people with obscure (but usually reasonably easy to satisfy) tool preferences. You know, the guy who changes his IDE to emacs key bindings, the guy who does all his e-mail using mutt when everyone else uses gmail, the girl who uses a Dvorak keyboard layout, the guy who insists he works best on a 1024x768 screen, and so on. Having tried a variety of industry tools and thought about about how you work best is usually a good sign[1].

Their favourite tools aren't my favourite tools, but they work for me so if they're not happy, I'm not happy.

The bait and switch is we adopted a tool that would keep IRC users happy, and it dropped IRC support.

[1] Although I keep my settings conservative, as it's hard for others to pair program or assist you with problems if they can't operate your computer

____________________

(thanks to http://highscalability.com/blog/2018/3/16/stuff-the-internet... for finding this comment)

Probably a great way to reduce friction when introduced.

could.

At any rate, that doesn't change the fact that it probably could have been implemented in XMPP.

As one of /those/ people still using IRC, I would personally have been totally fine continuing to use the IRC gateway without these features.

Would have been useful if their announcement included some of their data for reaching the conclusion, like "95% of channels use emoji reactions in more than 5% of their messages". The announcement, as it was, didn't read very well to me.

Obviously, this could be done differently. But it's easy to do it like this and come to depend on it.

I can’t think of any way that emoji reactions would be mission critical unless they are part of an API that can be used for automated execution of tasks. But maybe that sort of thing does exist?

Now if it was :4677: it'd be a different story - without some support it'd be hard to understand the constant identifiers.

/shrug

I've updated the article to clarify.

EDIT> Thanks for the downvote! Always fun when disagreeing with the echo chamber causes a loss in Internet points.

It doesn't have the 10 000 messages limit, it's very light (~100 KB) and fast:

https://eul.im

I recently started working on it full-time, so I expect a stable release to be out this month.

I 100% agree with you. I want this product to make money so that I can devote my full time to it.

The basic functionality will always be free without ads and tracking. But there will also be a very affordable ($1-2/mo) premium plan. I haven't yet decided what it's going to have. Most likely an ability to add more than 5 accounts or multiple accounts on the same platform (e.g. 3 Slack profiles).

Examples:

- Conversations, the Android XMPP client, is GPL and sold on Google Play: https://play.google.com/store/apps/details?id=eu.siacs.conve... - There is also a paid hosted XMPP service on conversations.im.

- I have a paid+OSS app for amateur radio geolocation on Google Play myself. You can download the APK from the homepage or just directly buy it for some bucks.

- X-Chat, the OSS IRC client has a paid Windows version: http://xchat.org/windows/

You could OSS your app under whatever license you want, and still provide paid builds for any platform you want.

I don't want to charge a lot for a chat client, but these prices are not final. I know that charging too little is a mistake.

FYI, I have nothing against closed source projects, but every discussion about eul.im seems to include the promise of open sourcing the project, which I'm sure is a great marketing ploy.

By building a closed-source client?

Cool project; it's really impressive and I'd love to use once it gets stable, but don't you think your claim is a bit incompatible with your method?

What I meant is I'm building an alternative client that gives people a lot more freedom. For example, you can use XMPP as your primary messenger, and still communicate with your teammates via Slack.

You can also have access to all your history and a much, much better instant search.

In the future, an IRC/XMPP gateway will be built in as well.

I might not be using the best words, so I'll give examples: Dolphin, the GameCube/Wii emulator did not release it's source code until the program's structure was mature enough to start adding thirth party code without disrupting the project's core codebase.

I'll be following this for sure <3

Wrapping up the Linux GUI bit will only take a couple of days.

If it supports some important features like file uploading, pinning and seeing pinned threads, etc. to reach Slack feature parity I'll surely take a shot.

Are you using QT for cross-platform compatibility or some other toolkit?

It's all native.

Pinning is supported, just temporarily disabled. File support is not great right now. Only inline images are supported.

But the goal is of course to have full feature parity and more, so follow the development :)

A lot is going to be done by the end of March.

Not on Ubuntu/Arch/etc... :)

> You have macOS 10.12.6. The application requires macOS 10.13 or later.

Run it from Terminal for now:

~/Downloads/eul.app/Contents/MacOS/eul

I'll fix this in v0.31.

The Facebook/Twitter analogy is flawed, because those are ad-supported businesses, so the company has a strong financial interest in having users on its own/primary platform, where it can deliver ads. I think that's not the case with Slack (?). But even there, I think the incentive to not support N protocols is not to get the +0.1% revenue from IRC/XMPP users, it's velocity/simplicity in product development, which is worth more money in the long term.

Disclaimer: I worked for FB previously, on Workplace, which is a direct competitor to Slack.

Disclaimer: I hate threads in slack

When you already have too many channels, and then they give you the ability to have too many threads.

I feel like they do a worse job at the supposed value add of being able to archive and later refer to a topic of conversation than channels simply because they are so light weight and proliferate so many of them, potentially.

Plus it's really jarring to be pulled into a bunch of threads.

Slack segregates by interests and social group, and bundles that with strict gatekeeping. There is no way for people to remix that to suit their own preferences. You can only fragment existing communities more.

I would love a slack multiclient where I can put channels I care about side by side, regardless of origin, and keep the rest out of sight. Instead now everyone has their own #random and #offtopic and so on. Cruising between Slacks and Discords is like navigating a hall of mirrors. If there is disagreement, the only solution is complete schism.

As much as I'd like to live in a world where open protocols and federated services evolve as quickly and turn out as well as proprietary solutions, that's apparently not the world I'm living in. Email, as much as I love it, is basically stagnant. IRC existed long before Slack, and if it had been truly successful, Slack would never have existed because there would not have been a market niche. And having recently written a bunch of XMPP code to talk to my vacuum [1], I was entirely underwhelmed. Whereas Slack is a product I use daily because it just works, and works well.

[1] http://github.com/wpietri/sucks

https://joinmastodon.org/

How it works Anyone can run a server of Mastodon. Each server hosts individual user accounts, the content they produce, and the content they subscribe to.

Each user account has a globally unique name (e.g. @user@example.com), consisting of the local username (@user), and the domain name of the server it is on (example.com).

Users can follow each other, regardless of where they’re hosted — when a local user follows a user from a different server, the server subscribes to that user’s updates for the first time.

Only downside of course is that if you selfhost alone, your federated timeline will be a bit empty, I do recommend either finding a community or starting one to get a bit more activity (Mastodon is essentially geared towards a sort of "community neighborhood" decentralization, where only one in a few hundred or thousand users needs to run a server, on average)

But this is a very simple alternative, distributed "Twitter" for hackers: https://github.com/buckket/twtxt#twtxt

As to spoofing, we've got to move beyond humans memorizing unicode strings or profile pictures as a means of identity validation. Its shambolic enough that twitter users constanly change their display string, obscuring the twitter handle, but even without that problem, how many people send bitcoin/ethereum to @eloon_musk?

I don't think it needs a solution, administrators of instances have to solve this, first by asking to offending instance to ban the user, mute the user and if the instance doesn't do anything about repeated abuse, mute the instance.

IIRC, for quite a while Slack even allowed two people in the same channel to have identical display names.

- Resource hogging - Buggy iOS app (especially on iPhone X) - Missing accessibility features - Lack of native app

They've taken $0.75bn in funding over 10 rounds and still suffer from some _basic_ issues.

- Mentions: Many times I've tried to mention someone but Slack goes and picks the wrong person. If I'm typing `@johnd`, then it should be fairly evident that I'm trying to mention `@johndoe`; don't make me go through that UI when you should have enough info already.

- Buggy snippets: Why do I have to go through a slow UI just to paste some code, when triple-backtick should be enough?

- Triple-backtick: No code highlighting. And just try to copy its content; you'll be surprised when your clipboard looks as if passed through an `s/\n/\n\n/g` filter.

- Scroll up: Scrolling up many pages above causes some weird jumps.

---

Incidentally, the Discord people got all these things right.

But this is different. Slack is a business and they’re making a business decision. I’ve never heard them imply that IRC would be a core part of their business. The vast majority of their user base has never even heard of IRC. It doesn’t make sense for them to spend money to support a feature used by 0.5% of their users.

If IRC support is so important, build a business that supports IRC and get people to pay for it.

Until then, can we stop acting like the mean boy on the playground stole our lunch?

https://twitter.com/ralphm/status/971461404900372480

Why? Facebook, google, slack are not using XMPP internally for chat products, because of technical reasons. They dropped XMPP gateway for mix of technical and strategic reasons. Instead of trying to be a warrior for technical correctness, XMPP foundation should rather seek feedback and try to make sure that developers integrating with XMPP will do everything correctly as easy as possible. Otherwise, more and more projects would be dropping XMPP support.

Additionally I had pointed that their statements on XMPP security were factually wrong. No useful response or changes were made.

That all said, I really like a bunch of things about Slack and have repeatedly pointed out in discussions in the XMPP community that there is a lot to be learned from Slack in terms of features (and how they work technically), UI consistency, and usability. As JC points out, this is surprisingly hard to achieve in open source projects. Even harder to pull off for a very diverse community around a set of protocols, rather than a single software product.

There are also things in Slack that I think would be a lot better if they were modelled after recent protocol proposals in XMPP. For example we are working on something called MIX, an evolution on group chat, based on Publish-Subscribe. This allows for orthogonal streams of information bound to a channel, besides just chat and presence, like merge request notifications, Twitter mentions, etc. that could be displayed in a side-bar or ticker, instead of (annoyingly) interleaved with chat messages.

I would have welcomed Slack interacting with the community, but they didn't.

XMPP works great and I've used it at several employers. There's no technical reasons to avoid it; it really is all about lock-in and corporate planning.

I've watched Ralph struggle for years against corporate asshats. It's a real tragedy that all these companies don't participate in open standards. We shouldn't have ever expected good things from Slack.

I was talking about implementation of Facebook messenger, or Google hangout (which does not use XMPP), not what is used internally for communication.

Also, at Facebook, messenger is most used product internally. IRC is still used, but not that much (depends on org, infra devs use IRC more than product devs). But IRC is still essential, in case of emergencies (where you don't want to use your own product, as it may be down).

I like the attitude of telling the truth. Compare to Torvalds.

Care to elaborate?

Eve Online just abandoned their own in game chat server and replaced it with ejabberd.