The problem is that XMPP and Matrix are protocols, not products.

Element (the primary Matrix software) definitely has Slack and Discord in its sights.

I don't think there are any serious "self-hosted Slack-like" contenders that are XMPP-based right now. You can piece components together (yay, standards!) and I did exactly this for the IETF's XMPP deployment recently. But it's far from being a cohesive easy-to-deploy product. Simply because nobody is building that right now. It takes time and resources and there's no money in it.[1]

People who do set out to build Slack clones (projects like Mattermost and Rocket Chat) and earn money don't have features such as federation on their priority list and don't build on top of Matrix/XMPP. They roll their own custom protocols and as far as I can see they are fairly content with that decision.

[1] There's even less money it, but nevertheless I am currently working on such a self-hostable "package" for XMPP. However rather than focusing on the team chat use-case (Slack/etc.) I'm focusing on personal messaging (WhatsApp/etc.): https://snikket.org/ if you're interested. It's possible I will broaden the scope one day.

EDIT: typo

It's largely overlooked that the success of Slack & MS Teams is partly due to the cybercrime portal that email has become. IOW, you don't get phished in your org's Slack chats. To prevent phishing, any chat service will suffice; an open protocol isn't necessary, as you don't intend to engage with ppl outside your org.

The essential problem IMO is how to replace SMTP. No one has proposed and implemented an alternative, to my knowledge. So I decided to[1]. The current draft omits federation (although I wouldn't rule it out in all cases yet).

[1] https://github.com/networkimprov/mnm/blob/master/Protocol.md

No, EMail has fundamentally bad UX for a lot of use case slack and similar are used for.

> problem IMO is how to replace SMTP.

Sadly SMTP is probably one of the parts of Mail which have aged best. Enforcing the usage of some (currently by design optional) features wrt. authentication and similar at the cost of backwards compatibility and you have all you need from the delivery protocol.

BUT:

- IMAP and similar is much worse.

- Mail bodies are a big mess it's always fascinating for me that mail interoperability works at all in practice (again you can clean it up a lot, theoretically, but backwards compatibility would be gone).

- DMARC, DKIM and SPIF which handle mail authenticity have a lot of rough corners and again for backward compatibility are optional. Again it's not to hard to improve on but would brake backwards compatibility.

The main reason mail still matters is because it's backwards compatibility, not just with older software but also with new software still using old patterns because of the (relative to the gain) insane amount of work you need to put into all kinds of mail related components. But then exactly that backwards compatibility is what.

(Yes, I have read the "Why TMTP?" link and I have written software for many parts around mail including SMTP, and mail encoding. The idea that SMTP is at the root of the problem seems to me very strange. Especially given that like I mentioned literally every other part of mail is worse then SMTP by multiple degrees...)

EDIT: Just to prevent misunderstandings one core feature of mail is the separation of mail delivery and mail authenticity, in the sense that you don't need the mailman to prove the authenticity of a mail. At most the legal/correct/authentic delivery.

> No, EMail has fundamentally bad UX for a lot of use case slack and similar are used for.

The opposite is also true.

By "replace SMTP" I mean the whole email protocol stack, not only SMTP. I'm not proposing to replace it for all situations overnight; of course SMTP etc will be used for decades.

TMTP also covers most IMAP/POP use cases. And it allows short, plain-text messages (see Ping) to make first contact with others -- necessary when that server has less restrictive membership requirements.

Authenticity is a double-edged sword. For certain confidential content, you want the recipient to know that it originated with the sender, but you don't want anyone else to know that in the event the content is leaked or stolen.

I believe the extinction of email for person-to-person & app-to-person correspondence is a foregone conclusion, due principally to phishing. The question is what should we do now, and the answer is clearly not chatrooms (which are of course useful in certain circumstances).

Email is not a chat system, and chat systems are unsuitable for asynchronous long-form threadful discussions. There is some overlap, but combined they form a spectrum of communication modes so wide that it can‘t be covered by a single UI.

I would argue that email is not suitable for asynchronous long-form threadful discussions. The limitation that email has is that if you're not part of that conversation from the beginning, you'll have to piece it together from previous quoted material.

One email like protocol that properly handles this is NNTP.

True regarding the late-comer aspect, although it is less of an issue when using mailing lists with an archive. In the past, when lacking an archive I also just asked another participant to send me the earlier discussion in mbox format, which was easily accomplished with the unix MUAs of the time.

Regarding the actual modes of discussion I was thinking of though, usenet and email are mostly the same.

> I was thinking of though, usenet and email are mostly the same.

For the most part, they are and many readers support both protocols (or at least they did in the past). The nice thing about NNTP is that it doesn't require maintaining a separate archive or having someone send you an mbox file to import. Just subscribing to the appropriate groups was sufficient (depending on the article retention policy).

I agree with both of you, and TMTP supports adding people to a thread after it starts (see PostNotify).

I'm not finding much about TMTP or postnotify with a search through Google. Could you link to some resources?

I've only just begun publicizing it, after getting the client & server implementations to a point where folks can evaluate them.

Protocol: https://github.com/networkimprov/mnm/blob/master/Protocol.md

Why TMTP? https://mnmnotmail.org/rationale.html

Follow: https://twitter.com/mnmnotmail

Why would you replace it? Will not disabling all public un-authenticated submissions on your mail server suffice? You can also prevent delivery to outside world (and error out on submission so that users are notified) if you really like. Result will be your own private mail server.

And you can keep using all the normal MUA's on desktop and mobile.

Changing your SMTP server configuration that way would break things, so the question is whether to set up a new, company-internal SMTP server, and give your employees new addresses there. But that won't quickly stop the phishing, because your ppl still need to get email via the public network from clients and suppliers.

Setting up a new server isn't easy unless you hire an outside service provider, and if you're willing to do that, Slack et al offer a nicer UX than the well known email/webmail clients.

Orgs with sufficient IT resources commonly do run internal SMTP servers.

I meant that as a suggestion compared to designing a new protocol.

Yes I'm old enough to remember when organizations had email but it was internal-only. Probably less for security reasons at the time than that they simply didn't have an internet provider. There were also mainframe-based email systems that were internal to that network.

You're making some fundamental assumptions about federation that I think are completely wrong. Are you telling me that you never need to communicate with anyone outside of your organization? How do you intend to receive invoices? How will you communicate with outside vendors? Sorry, but you need some text-based way of communicating with people and email is the best way, that's why it's survived so long despite being problematic. If you have internal, asynchronous chat, why would you need internal email?

Sorry my dude, but business runs on email. Saying lets get rid of it is as naïve as saying lets get rid of Excel. It's just not going to happen.

There are two ways to communicate with ppl outside your org without federation (this is covered on the website):

1) Set up a second TMTP service where customers and/or suppliers can create accounts, along with employees who need to interact with them.

2) Have some employees join a third-party service which is open to all involved in your field. There is a risk of phishing in this case, but:

. a) anyone you haven't previously contacted is limited to short, plain-text communications to you (see Ping in protocol), and

. b) such third-party services would typically charge a fee to members and impose a small cost per-ping, and

. c) you know that you're dealing with unknown entities with possibly malicious intent.

TMTP clients support active logins to accounts on any number of TMTP servers, just as browsers support multiple active connections to websites.

> To prevent phishing, any chat service will suffice; an open protocol isn't necessary, as you don't intend to engage with ppl outside your org.

The same could be accomplished with email if you only allow connections to the SMTP and IMAP server from within the corporate network. That is, nothing external can connect to those servers, which is fine if it's only used for internal communication.

I used to work in anti spam and we would call these FUSSPs.

https://www.rhyolite.com/anti-spam/you-might-be.html

TL;DR: Thousands of brilliant minds have tried to fix email for decades, and realized it can't be done!

Ahem, I'm trying to bury email, not save it -- not unlike Slack :-)

XMPP is supported by a large number of clients, but running a server and getting everyone on clients with comparable featuresets is a nightmare. It’s a cluster of disparate standards, and it’s overwhelming. I’m sure it’s doable if you have the time to invest, but it’s not straightforward if you’ve never done it before.

Matrix is pretty straightforward on the server side of things, but the client UX is invariably mediocre. Vector—the official client—exemplifies everything that is wrong with Electron apps. Slow, clunky, poor UI, poor platform integration. With the default home server, it can take seconds for a message to go through. At least it’s far more customizable than Slack; it has an option for everything, which, as a power user, I quite like.

I haven’t tried Mattermost, but it looks like some of the important features aren’t FOSS, at which point it’s just another Slack as far as I’m concerned. I’ll gladly pay for support, but for SSO? Meh, might as well stick with Slack; at least everyone and their dog knows how to use it. (This is, of course, an opinion that stems partially from ignorance; I haven’t actually tried Mattermost, and if I do, I might fall in love with it. But my time is limited, and I can only evaluate so many products in a day.)

Not that Slack is much better here: their threading system has so many UI/UX issues. Ever had a thread with hundreds of messages? For your own sanity, I hope you haven’t. Ever tried to send an image to a thread from iOS? It’s possible, but only by pasting the image into the text field; the normal attachment button isn’t available, and Share buttons in other apps can’t send to threads. And, of course, the recent uptime issues.

Element (formerly Riot/Vector), has improved loads over the years, and the default matrix.org average send time is around 100ms these days rather than multiple seconds: https://matrix.org/blog/2020/11/03/how-we-fixed-synapses-sca... has details. I suspect you (and the parent) may be running off stale data.

That said, Element could certainly use less RAM, irrespective of Electron - and http://hydrogen.element.io is our project to experiment with minimum-footprint Matrix clients (it uses ~100x less RAM than Element).

> it uses ~100x less RAM than Element

Wow – congrats!!

What have been the most important architectural decisions to achieve this?

Rather than storing state from the server in the JS heap, new state gets stored immediately in indexeddb transactionally and is pulled out strictly on demand. So, my account (which is admittedly large, with around 3000 rooms and 350K users visible) uses 1.4GB of JS heap on Element/Web, and 14MB on Hydrogen. It's also lightning fast, as you might expect given it's not having to wade around shuffling gigabytes of javascript heap around the place.

I've wanted to try something like this (on a smaller scale), but haven't had time. It's good to hear of an implementation that reflects my expectations. How long did it take you to migrate over?

it’s a entirely new codebase; probably best way to visualise progress is to look at the contributor graphs at https://github.com/vector-im/hydrogen-web

Cool, thanks for sharing!

It has, and I’ve been using it since its early days. I still use it. It’s still terrible, just slightly less terrible. And, no, messages don’t consistently send in 100ms on the default home server; there are regularly disruptions that cause significant delays, sometimes as much as 10-20sec. That’s a big problem for a federated chat platform.

Edit 1: I want to love it; the design is everything I could ever hope for in a chat platform. I even tried to contribute to Vector, but it was such a mess that I eventually gave up.

Edit 2:

> That said, Element could certainly use less RAM, irrespective of Electron - and http://hydrogen.element.io is our project to experiment with minimum-footprint Matrix clients (it uses ~100x less RAM than Element).

I'm not sure why this is a priority. Techies complain about RAM usage a lot, but if we have to choose between performance+power and a small memory footprint, we're going to choose the former almost every time. Take Telegram, for example: they have a bunch of native clients that perform amazingly well, although they do gobble RAM. Most of my technical friends use it as their primary social platform. It's not without issues, but it's really hard to go from something like Telegram Desktop or the Swift-based macOS Telegram client to Vector. And those clients aren't made by large teams--most (all?) first-party Telegram clients are each maintained by a single developer, if I'm not mistaken.

It's weird that you're calling it Vector when it's now called Element and it was called Riot for years before that.

The constant rebranding and confusion over Matrix/Vector/Riot/Element is another point of pain for me. It’s incredibly difficult to communicate unambiguously about Matrix with people who haven’t been following it for years.

Does Element refer to the ecosystem as a whole, including EMS? The primary client? The core federation? It’s not obvious from a casual visit to element.io. I suppose if I said “Element web app,” that would be fairly clear, but I’m still in the habit of saying “Vector” from the days of Riot.

Everything related to the company formerly known as New Vector is now called Element. The company is Element, the official clients are called Element (with suffixes Web, Desktop, Android, iOS) and yes, EMS is Element Matrix Services. This rebranding was done specifically due to the confusion brought on by the many previous names. More info here: https://element.io/previously-riot

The protocol is still called Matrix.

Yes, I actually like the change—I think they finally got it right this time. (The Riot rebranding was a mess.) However, it’s still frustrating when trying to communicate with people who aren’t following Matrix-related news. In my circle of friends, “Vector” remains more widely understood than “Element Web,” so that’s what I’ve been using.

Anyway, my point stands: Element Web/Desktop feels fairly unresponsive compared to something like Telegram Desktop. It looks so much nicer now, the UI layout is great, and it’s far more powerful than Telegram—yet, I can’t help but feel like I’m swimming through molasses even when dealing with moderately-sized groups. Try clicking around on different groups rapidly; you’ll likely find that you have to wait several seconds for the UI to update.

>XMPP is supported by a large number of clients, but running a server and getting everyone on clients with comparable featuresets is a nightmare.

XMPP is, well, extensible. If things don't match in the clients then that particular feature just doesn't work. These days all the clients pretty much try to match the feature set of Conversations. That applies to the servers as well. There is a server tester for that:

* https://compliance.conversations.im/

So the tooling is pretty good these days.

The great thing about XMPP is that basic messaging always works. That stuff is just too simple not to.

I recently finally found someone to try Element with and the experience has been great so far. (Except for the need to go through Google's captcha at some point.)

It even sent a 20 Mo MP4 like a champ, while Conversations sometimes chokes on not that high resolution photographs...

I can only offer my own personal experience: Matrix has been working well for me for a couple years now. However, I probably have a more narrow use case than you're thinking of.

I run a small homeserver and use it to communicate with a group of about 20 friends. Most of them aren't "technical" people. We use it mostly for chatting and image/video sharing. We never use live calling (audio or video).

There have been a few bugs in the mobile apps, but for the most part, everything has been working fine.

The biggest issue is the UX. It's not as polished as the big players.

This is actually the use case I've been trying to get to for some time. Unfortunately, I need it to "just work" to get my non-techy friends interested, otherwise they'll go right back to Discord.

Like I said, it's close, I just don't think it's there yet.

I'd say it's almost in "just works" territory for everyone except the person who has to actually administer the homeserver (me). I absorb a lot of the complexity for my friends.

The only thing that's a little cumbersome is requiring them to enter a custom server URL when the register/log in for the first time.

For competing with Discord, it seems like it would benefit from a more robust free offering to compete with Discord. Being able to create a free Discord server is great, and it is incredibly capable for most communities that don't need the fancy perks of Discord Nitro etc.

> The free Discord plan provides virtually all the core functionality of the platform with very few limitations. Free users get unlimited message history, screen sharing, unlimited server storage, up to eight users in a video call, and as many as 5,000 concurrent (i.e., online at the same time) users.

For a lot of small communities that aren't focused around commerce of any kind, Discord's free offering blows Element Matrix Services out the water. It's a non starter. If I could create a server with feature parity to Discord's free server, any new community I'd create I would definitely jump on EMS in a heartbeat, and I'd start trying to recreate communities currently within Discord, to be on EMS.

So like a very normal progression for Discord servers is that some niche sub-community wants to gather, and so they create a free server, and people join and there's all kinds of rich content that gets posted and curated and great discussions and then as it gets bigger, people running the community or people who want to support the community will boost the server with Discord Nitro for additional features like more slots for custom emojis (I can't communicate enough how important of a feature this is to Discord's success, even though it seems like minor window dressing).

That kind of model is what would justify a server starting to shell out money every month for EMS. I would note that Discord's pricing for this kind of level of community is tiered and not a per-user thing. You unlock more features based on how many users are paying for Nitro, going up a tier based on breakpoints of 2/15/30 Nitro Boosts per month. It doesn't cost more to have a tier 3 server if you gain more users. This is a big deal for fostering growth and unseating incumbent social networks (which is what Discord and Slack are).

Just some thoughts. I really want stuff like Element/Matrix to succeed!

Actually that’s the same with slack, each slack server has a unique url too.

    and use it to communicate with a group of about 20
    friends. Most of them aren't "technical" people. 

I'm insanely curious about the human side of things here. How did you get them to buy into this idea in the first place? That sounds like quite an achievement.

The non-technical folks in my life generally struggle with paths of least resistance (iMessage, etc) and it's hard to imagine getting them onto some alternative platform/protocol.

It did take some persuading. I think the main reason I was able to pull it off was ironically because they're not that technical. I bet most of my friends don't even know what Slack or Discord is. That's not to say they're dumb or anything - they just don't spend as much time online as one would think.

Previously, we were mostly using group texts or Snapchat/Instagram to communicate, so the biggest selling point was the fact that we can share full quality pictures and videos between iOS and Android people.

This is awesome. I have always wanted to self-host a Matrix instance as well, but I imagine it's going to be very hard to convince them to move over, from Telegram. Is there a blog post that I can read about homeserver setup? I am keen on seeing how easy it was, and keen on seeing what level of technical and financial resources you had to invest to get going.

That's interesting. Thank you for sharing that!

For my part, I don't have buy in yet (Because I'm not convinced Matrix is ready) but I think I could get it. I have 7 or 8 friends who do not use Discord except to talk with me and a few other friends that I know can be convinced to at least start using Element next to Discord. Once I feel like my homeserver is in a state that I can invite these non-technical people in, I'll be in the same place.

You bring up a good point, however, which is that we _could_ use open source, non-centralized alternatives for many of the online products we consume, but we choose not to, and so we increasingly become slaves to corporations that actively seek to narrow our choices. Another example of this is the push from big sites like Reddit to use their apps rather than just use a browser - it’s not about functionality, it’s about destroying the free and open web.

> You bring up a good point, however, which is that we _could_ use open source, non-centralized alternatives for many of the online products we consume, but we choose not to, and so we increasingly become slaves to corporations that actively seek to narrow our choices.

That doesn't happen for no reason. The vast majority of open source products I've used have terrible usability. I simply don't want to use them. I don't want to be beholden to corporations and walled gardens, but for me, the existing alternatives are worse in too many ways.

Or, or... and bear with me here... or, packaged click-button solutions with paid (contractually obligated) dedicated product support is a better use of our short time, more often than not.

That only works if you only need to use Slack alone or whatever. The moment you have to use more of these annoying services at once and manage N different stupid client apps for Y different platforms (desktop/mobile), the lack of open/shared protocol becomes a major issue. Let alone if you want to use them on emerging mobile OSes that are not a hellhole of data thievery.

>support is a better use of our short time, more often than not

Not when it's down.

Which open source solutions never go down?

Everything goes down. But it looks like huge complicated distributed services shared by huge amounts of people, that are continuously updated and developed, and are constantly trying to attract more users/load, seem to go down more than a simple service on a simple server.

No hard data though. My mail server only ever went down when I upgraded the server and didn't check that everything was still working right away, or similar maintenance induced incidents. It never went down by itself.

Such systems only ever go down unpredictably on HW issues, or when overloaded/out of resources. Neither is very likely, because you're not trying to grow your service in any sense similar to VC backed enterprises. Most of the time it has constant very low load and resource use. And you can simply stop introducing changes to the system if you need more stability for some time. (stop updating, for example)

The one solution with PLANED downtime.

Facebook and other vendors killed XMPP, we lived in a non federated world in Enterprise and consumer. No interest of companies to change this

XMPP killed XMPP. Its just not very good. It doesn't work well between different clients and servers. The protocol is a horribly overcomplicated mess of overlapping, partially supported extensions for basic functionality. And it doesn't work at all with low power mobile delivery. (It was invented before the iphone.)

There might have been political reasons why google dropped XMPP, but it would also make sense as a purely technical decision.

> And it doesn't work at all with low power mobile delivery. (It was invented before the iphone.)

This is plain untrue. Yes it was invented a long time ago, but thanks to the extensibility it has evolved over time just as the way people use it has changed. This evolution is a healthy and necessary part of an open ecosystem.

I know it frustrates people that modern features don't work in stagnated clients such as Pidgin and Adium, but modern clients support all the things you would expect.

Servers and mobile clients have supported mobile-friendly traffic and connection optimisations for many many years now.

> There might have been political reasons why google dropped XMPP, but it would also make sense as a purely technical decision.

Google contributed extensions to XMPP, the same way they contribute to other internet standards. I think they were quite comfortable with this. The XMPP-based Google Talk was their longest-running messaging solution after all...

> And it doesn't work at all with low power mobile delivery.

What makes you think so? If Conversations was draining my battery, I would have noticed by now, I'm pretty sure that Facebook Messenger is worse in this aspect...

Maybe things have changed - certainly when I looked at it a few years ago (around the time that google stopped supporting it) my understanding was that xmpp had no push notification support. The app in the phone had to either poll or explicitly hold open a TCP connection. (Which is problematic when the app is backgrounded.)

Has this been fixed in XMPP?

Yes, XMPP has had push notification support for years. It's the only way can work on mobile these days.

> It was invented before the iphone

That's true for email also. So that's not an evidence for anything lacking in xmpp. The plain fact is that Google killed it due to their greed.

I was recently forced to use Facebook Messenger (thanks God it's soon over), and I'm hating it : it's slow on mobile, even worse on PC, where it regularly makes my whole OS hang requiring a reboot.

Scrolling back is atrociously slow, and it doesn't even seem to have a search feature !

I'd take XMPP alternatives like Conversations, Jitsi, Pidgin any day ! (And Element of course.)

XMPP is hardly killed. There are tens of thousands of XMPP servers out there with over a hundred public servers. There are lots of client implementations. Even the really bad implementations manage basic messaging.

Spam killed xmpp

I remember using clients like pidgin with all my accounts it was a great experience. Now I need to have like 100 apps

BS

The only thing "killed" XMPP was that proprietary made money, XMPP didn't.

Apart from that, it's alive and well. See Conversations for android, Prosody for server.

What are you talking about ?? You need to confirm each other before communicating on XMPP, spam can't get through that !

I can hardly see those as alternatives to Slack. Maybe https://mattermost.com/ is what you were thinking about?

Matrix with Element (Riot) as the front-end is pretty close. It does what slack does, it's just not very good. XMPP is arguable. It can be a Slack alternative, if you stitch enough other servers on top of it. Personally, I don't think XMPP will ever be more than chat, but some of its adherents believe differently.

Mattermost is certainly not what I meant. That's just trading one Slack for another.

This thread is about a Slack outage, which you have no control over. Mattermost and similar software is self-hosted, which of course doesn't mean you're getting 100% uptime, but you have (more) control over it.

In practice self hosted usually translates to more downtime and slower performance when it works. Unless your org has more expertise running a chat service than Microsoft or slack, your self hosted alternative is always going to suck more.

Did you try self-hosting and it lead to more downtime and slower performance?

From my experience, when I self-host stuff it's a lot faster (more server resources) and never had any downtime (server doesn't simply go down for no reason).

I haven't tried it personally. But my employer hosts an on-prem Github instance and it is just terrible. So many downtimes, long times before anybody gets around to repair it, general performance issues, maintenance windows for upgrades, etc. Just a huge pain. I've seen this sort of problem with the old Exchange on-prem services too.

IRC may be out these days, but at least deploying a small IRC server for the own team is really not that much effort anymore and doesn't incur that much ongoing maintenance work either.

RocketChat works pretty well for simple team comms. I have no idea if it can do XMPP and/or Matrix.

I suggested RocketChat when the outage was announced and HN community downvoted it quite heavily. I'm not sure why. [0]

We ended making the switch and committed to Discord. We're now looking at Rocket.chat as a backup in case Discord goes down. But Slack is now completely out of the picture for our team.

[0] https://news.ycombinator.com/item?id=25633047

Just curious - why not use Matternost as a backup? (disclosure: I work at Mattermost, but really just want to know what you think)

I’ve advocated for an idea where Mattermost is to be used as a “bunker” where it is hosted on a raspberry Pi (or somewhere else) and acts as a digital bunker if your critical infrastructure (slack, teams, exchange?) is compromised somehow.

Not OP. Good idea. I thought it's integrated into GitLab (on premise omnibus), but I still haven't fiddled with it, but enabled something in the config file, but nothing happened.

I know it's a tough spot, but if it were usable from GitLab with zero config that would be great for fallback.

@pas: Mattermost is indeed integrated with GitLab Omnibus.

To enable Mattermost, you can add the Mattermost external URL in the config file, and run `sudo gitlab-ctl reconfigure`. I'm wondering if that's something you've tried? https://docs.gitlab.com/omnibus/gitlab-mattermost/#getting-s...

Thanks for your reply! I gave it another try, and it works now beautifully :o (Possibly last time I tried it, there was no LetsEncrypt integration and the external URL setup was more involved?)

Interesting! I never looked into it, but now I will!

My experience with RocketChat is that it works quite well on the surface, but after using it for some time, some very annoying bugs emerge:

* You get notifications for channels for which you have suppressed those notifications

* Some channels are marked as having new notifications, when they haven't

* Notifications for new messages in threads you are involved in are quite hard to find (horrible UX)

* Some UX choices are very confusing (you get a column of options related to notifications, and for some, the left option is the one leading to more notifications, for some the right option)

* There are some overlapping features that lead to inconsistent usage (channels vs. discussions vs. threads)

* Threads are hard to read, because follow-ups in threads are shown in a smaller font size. You cannot increase the font size at all in the desktop application

.... and so on.

Also, I tried to submit some bugs, but for that I'd need to have some information which only the admins have that run this instance, and in the end it was too much effort to get all that information together, so I didn't even bother.

I agree, it's still got a long way to go. I'm saying it's still a perfectly viable alternative to Slack. Fast, simple, works. (At least this is my perception/impression. I wanted to evaluate Slack alternatives for some time, but haven't got the time for it yet. So I was surprised when I got an invite to one of our client's rocket.chat instance and things worked pretty well.)

I'm in a slack workspace that is constantly notifying me of a thread, but I can't make it read. Maybe it has something to do with the free messages limit. So the message is there, but cannot be accessed. Annoying as hell. I thought about submitting the bug to Slack, but then just let it go, and probably we'll just move to Signal or something.

I've heard lots of good about Zulip - haven't tried it myself yet though

Have you tried http://quill.chat/ ? Younger startup (invite-only) but very slick.

Looks like a great start. The TODO list is most of the stuff I'd want that push it over the edge of even suggesting to our company to replace Slack.

But I signed up and will keep it on my radar as it matures.

Thanks for sharing! They definitely nailed the marketing page, I’ll keep in my list of products to follow up on :)

If the benefit we are looking for is better up time, that will not happen. The main benefit is going to be knowing why the system is down, and the eta to being up again.

That takes care of the software and protocol side of things, true, but does it give more reliable and predictable uptime? That's the main thing here; while there are plenty of software alternatives to Slack, their product is not just the software but also the hardware, servers, and scaling. You can get a Slack instance from 10 to >10K members without ever having to worry about your hardware, or how much hours your staff needs to spend on maintaining said hardware. And when there is inevitably downtime, you and your staff don't have to scramble to get it back up - with this outage, it's a shrug, it's down, it'll be back soon probably, I'm going to do some work or do something else. Extended toilet / lunch break.

> self-hosted

How often is Slack/Discord down? I mean it's not perfect, but I really honestly don't think I could match their uptime by self-hosting, as well as more on-call rotations for something that's not core product.

I very much prefer that for something that isn't core product, if it goes down I need to do exactly nothing for it to come back up, and that the engineers at Slack will be starting to work on it likely before I even realize it's down.

This is a tale SaaS vendors (which have strong presence in online tech communities like HN because they are software companies) sold very well, and it's probably true for many small startups, but for medium sized companies managing their own platform for something like Slack is completely doable and you will not have those big downtimes compared to Slack. Sure, you have to dedicate time and resources to it, and obviously is not "core business" although a chat platform is a pretty important component in an online company.

I would be surprised if you couldn't match or exceed slacks uptime running whatever alternative you want (IRC, mattermost, rocketchat, etc.) on a random dedicated server.

Hardware is quite reliable these days. And updates can be scheduled to be at a convenient time for the team.

Yes, but what if you're taking a few days off to backpack in the wilderness with no signal while it goes down? Who deals with the downtime?

If you are the only technical person on your team then it's of course not ideal and would require some further thought into making things redundant. But even that is easy enough to do with IRC (setup two servers, link the irc servers together, single DNS record that points to both servers - job done).

If there are other people on the team that have _some_ technical skills then they can fix it..

IRC lacks quite a few features compared to other solutions, but the reduced complexity does bring very low operational complexity.

IRC will be incredibly hard to use for non-technical people on your team. Mobile clients for IRC look like crap, and have horrible-looking ad bars. No integration with Google Drive, Github, or other things.

It's just not a business-friendly tool.

I'm an engineer and personally I'm fine with IRC, I'm just trying to be realistic here.

Is it really though? If I take a look at a random modern IRC desktop client - how is it more difficult to setup than say your email program? The amount of information needed on setup is about the same: server, username, password (in fact email can get a bit more confusing in big corporate email setups with differing imap and smtp servers, etc.)

Also there are plenty of modern web clients for IRC, such as https://thelounge.chat/ or https://kiwiirc.com/ (which is supposed to work on mobile too).

> your email program

Reality check: Most people don't use email programs anymore.

Also how do you get IRC to sync all conversation data, history, between your several desktops and phones, how do you send files, make calls, and thread conversations?

But clearly no one is saying that email is too hard to use and we should just use $something_else (or are they?).

And you are starting to move goalposts here.. first it was uptime, then it was operations and now it's features...

And what about those web based IRC solutions? They are even easier to use than slack, have combined history, file sharing, etc.

They are moving the goalposts because there are several and ultimately very many reasons why IRC won't work, they just didn't bother to think of all the reasons and list them at once.

Ultimately there is only one reason that matters: The person in charge of deciding what communication channel to use likes Slack/Teams/IRC/whatever.

Add to that the SaaS propaganda that hosting literally anything yourself is just too hard (it really isn't). Or this notion people are just too stupid to deal with anything more than the simplest possible web interface - Really? what do those people even do? Stare at Notepad all day? Of course not. They stare at various complicated software packages ranging from CAD, $spreadsheet abominations, SAP to various Adobe software packages. Sprinkle in a bit of hype for the latest new thing and presto.. </rant>

> Reality check: Most people don't use email programs anymore.

Guess you are not in enterprise.

I'd bet hard money that within epsilon of anyone using a desktop email client in 2020, and thus having one to set up in the first place...is in an organization with access to Microsoft Teams.

Who deals with the downtime if any other on-premises system goes down?

If you are running networks and software on site, and they are business-critical, you have people and a plan for this. Or you don't, and suffer the consequences.

There will always be more downtime on Slack/Discord. There are more users, more updates. Slack/Discord is a giant distributed system with nodes all around the world. An IRC/XMPP server on one machine that 100 people use is not going to crash unless intentionally.

People really over estimate the difficulty of running self-hosted systems with great uptime.

When self hosting you can get away with simpler systems that ends up being more stable and have higher up times for lower effort.

The reason you see cloud providers having issues is not because the thing is difficult, but because doing anything at huge scale ends up being difficult.

> it's not perfect, but I really honestly don't think I could match their uptime by self-hosting

This is such a common misconception. The services I self-host was configured by me, if anything goes down (which they very rarely do), I know the exact cause and have it fixed in minutes. When some company's cloud service goes down I'm completely at their mercy. I also spend very little time on maintaining these services, just security updates, which are mostly automated.

Bottom line, maintaining and self-hosting services that has 1 or a few users is much less complex than services with millions of users. Hence, my uptime is better than Google's, Amazon's, and Azure's, etc.

Yep, I've stopped recommending Matrix because

1. There is virtually zero user-facing documentation. Need to know how to backup keys, verify another user, or what E2EE means? Ask your server operator. Basically the onus is on operators to document this stuff for their users. Except the stuff we're documenting is hard even for server operators, and especially challenging to document in a way that both nontechnical and technical users can understand.

2. Because this stuff is challenging even for more technically minded users to understand, it leads to a kind of burnout for interested non-technical users where they learn all they can about some feature and how it works at a high level from out of date random blogs, try to use the (complex, multi-step) feature, but then something won't work, and it isn't be clear whether it was because the user did something wrong or because the clients or server implementations are broken

3. Issues where core functionality is broken (e.g. two mutually verified users on my homeserver haven't been able to talk to each other in months -- see [1], [2], [3]) languish for months with zero response from maintainers.

4. While core functionality is both broken and undocumented, the maintainers announce rabbit hole features that no one asked for and seem very much like distractions, like their recently-announced microblogging view/client[4]

In short the Element maintainers have shown little interest in making the platform accessible to the people who need its differentiating features the most, and have prioritized the "mad science"/technical aspect of their platform at the expense of the human element (end-users and operators).

It'd be cool if Element used their resources to hire some UX folks and community advocates whose sole focus is addressing the horrid accessibility of their platform. I think most users would rather see that than further "mad science".

[1] https://github.com/vector-im/element-ios/issues/3762

[2] https://github.com/vector-im/element-ios/issues/3572

[3] https://github.com/vector-im/element-ios/issues/3393

[4] https://matrix.org/blog/2020/12/18/introducing-cerulean

Have you submitted the requested bug reports?

Also, it seems the FAQ answers several of your points: https://element.io/help

Yep, I have, although funnily enough it turns out that the rage shake feature was the only way to submit a bug report with diagnostics from a client (as of a couple of months ago anyway) and that feature itself was broken for one of my users (who has since churned).

That FAQ is a great start, but it's not sufficient for non-technical users. It's not easily searchable, it doesn't provide screenshots, and it doesn't go into enough detail for each item (e.g. describing what can go wrong + troubleshooting).

Thanks for pointing it out though

This is disturbingly good summary. I remember Matrix being presented as less bloated compared to XMPP... sure.

it's trivial and essentially free (<$5) to run an IRC server supporting tens of thousands of users.

it also doesn't take gigs of memory on client devices.

There is also Mattermost which is literally like Slack, but self-hosted.

Remember when Facebook messenger was xmpp based? Lol.

Also Google Talk.