13 ms·

I'd like to take this moment to mention self-hosted, open source, and federated alternatives like XMPP and Matrix. I'd like to, but unfortunately I don't feel

I'd like to take this moment to mention self-hosted, open source, and federated alternatives like XMPP and Matrix. I'd like to, but unfortunately I don't feel like I can in good faith. Matrix is woefully immature, and suffers from a lot of issues, but I think is closer to being a functional Slack/Discord alternative. XMPP is much more mature, and works very well for chat, but doesn't have a nice package that does all the Slack stuff--at least not that I'm aware of. I'd love to be proven wrong there. I know it can be done, but if it can't be deployed quickly by an already overstressed team member, what chance does it have?

pachico 6y ago
I can hardly see those as alternatives to Slack. Maybe https://mattermost.com/ https://mattermost.com/ is what you were thinking about?
- thesuitonym 6y ago
  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.
  - PhilippGille 6y ago
    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.
    - perryizgr8 6y ago
      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.
      - XCSme 6y ago
        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).
        perryizgr8 6y ago
        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.
pas 6y ago
RocketChat works pretty well for simple team comms. I have no idea if it can do XMPP and/or Matrix.
- rexreed 6y ago
  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 https://news.ycombinator.com/item?id=25633047
  - win_ini 6y ago
    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.
    - pas 6y ago
      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.
      - jasonblais 6y ago
        @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-started https://docs.gitlab.com/omnibus/gitlab-mattermost/#getting-s...
zenexer 6y ago
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.
- Arathorn 6y ago
  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-scalability/ 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 http://hydrogen.element.io is our project to experiment with minimum-footprint Matrix clients (it uses ~100x less RAM than Element).
  - zenexer 6y ago
    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 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.
welterde 6y ago
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.
Unklejoe 6y ago
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.
- thesuitonym 6y ago
  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.
  - Unklejoe 6y ago
    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.
    - etherealG 6y ago
      Actually that’s the same with slack, each slack server has a unique url too.
    - will_pseudonym 6y ago
      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!
projectileboy 6y ago
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.
- ende 6y ago
  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.
  - nix23 6y ago
    >support is a better use of our short time, more often than not Not when it's down.
    - thewebcount 6y ago
      Which open source solutions never go down?
      - nix23 6y ago
        The one solution with PLANED downtime.
      - megous 6y ago
        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)
dheera 6y ago
> 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.
- darkwater 6y ago
  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.
- welterde 6y ago
  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.
  - dheera 6y ago
    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?
    - welterde 6y ago
      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.
spicyramen 6y ago
Facebook and other vendors killed XMPP, we lived in a non federated world in Enterprise and consumer. No interest of companies to change this
- lallysingh 6y ago
  Spam killed xmpp
  - spicyramen 6y ago
    I remember using clients like pidgin with all my accounts it was a great experience. Now I need to have like 100 apps
  - pmlnr 6y ago
    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.
  - BlueTemplar 6y ago
    What are you talking about ?? You need to confirm each other before communicating on XMPP, spam can't get through that !
- josephg 6y ago
  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.
  - BlueTemplar 6y ago
    > 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...
MattJ100 6y ago
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/ https://snikket.org/ if you're interested. It's possible I will broaden the scope one day. EDIT: typo
- networkimprov 6y ago
  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 https://github.com/networkimprov/mnm/blob/master/Protocol.md
  - megous 6y ago
    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.
halukakin 6y ago
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.
rattray 6y ago
Have you tried http://quill.chat/ http://quill.chat/ ? Younger startup (invite-only) but very slick.
- corytheboyd 6y ago
  Thanks for sharing! They definitely nailed the marketing page, I’ll keep in my list of products to follow up on :)
- dmix 6y ago
  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.
m12k 6y ago
I've heard lots of good about Zulip - haven't tried it myself yet though
vector_spaces 6y ago
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 https://github.com/vector-im/element-ios/issues/3762 [2] https://github.com/vector-im/element-ios/issues/3572 https://github.com/vector-im/element-ios/issues/3572 [3] https://github.com/vector-im/element-ios/issues/3393 https://github.com/vector-im/element-ios/issues/3393 [4] https://matrix.org/blog/2020/12/18/introducing-cerulean https://matrix.org/blog/2020/12/18/introducing-cerulean
- pmlnr 6y ago
  This is disturbingly good summary. I remember Matrix being presented as less bloated compared to XMPP... sure.
- erikbye 6y ago
mnky9800n 6y ago
Remember when Facebook messenger was xmpp based? Lol.
- sizeofchar 6y ago
  Also Google Talk.
zelly 6y ago
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.
johnisgood 6y ago
There is also Mattermost which is literally like Slack, but self-hosted.
Cthulhu_ 6y ago
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.

pachico 6y ago

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

thesuitonym 6y ago
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.
- PhilippGille 6y ago
  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.
  - perryizgr8 6y ago
    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.
    - XCSme 6y ago
      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).
      - perryizgr8 6y ago
        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.

pas 6y ago

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

rexreed 6y ago
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 https://news.ycombinator.com/item?id=25633047
- win_ini 6y ago
  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.
  - pas 6y ago
    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.
    - jasonblais 6y ago
      @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-started https://docs.gitlab.com/omnibus/gitlab-mattermost/#getting-s...

zenexer 6y ago

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.

Arathorn 6y ago
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-scalability/ 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 http://hydrogen.element.io is our project to experiment with minimum-footprint Matrix clients (it uses ~100x less RAM than Element).
- zenexer 6y ago
  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 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.

welterde 6y ago

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.

Unklejoe 6y ago

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.

thesuitonym 6y ago
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.
- Unklejoe 6y ago
  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.
  - etherealG 6y ago
    Actually that’s the same with slack, each slack server has a unique url too.
  - will_pseudonym 6y ago
    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!

projectileboy 6y ago

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.

ende 6y ago
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.
- nix23 6y ago
  >support is a better use of our short time, more often than not Not when it's down.
  - thewebcount 6y ago
    Which open source solutions never go down?
    - nix23 6y ago
      The one solution with PLANED downtime.
    - megous 6y ago
      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)

dheera 6y ago

> 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.

darkwater 6y ago
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.
welterde 6y ago
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.
- dheera 6y ago
  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?
  - welterde 6y ago
    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.

spicyramen 6y ago

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

lallysingh 6y ago
Spam killed xmpp
- spicyramen 6y ago
  I remember using clients like pidgin with all my accounts it was a great experience. Now I need to have like 100 apps
- pmlnr 6y ago
  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.
- BlueTemplar 6y ago
  What are you talking about ?? You need to confirm each other before communicating on XMPP, spam can't get through that !
josephg 6y ago
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.
- BlueTemplar 6y ago
  > 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...

MattJ100 6y ago

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/ https://snikket.org/ if you're interested. It's possible I will broaden the scope one day. EDIT: typo

networkimprov 6y ago
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 https://github.com/networkimprov/mnm/blob/master/Protocol.md
- megous 6y ago
  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.

halukakin 6y ago

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.

rattray 6y ago

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

corytheboyd 6y ago
Thanks for sharing! They definitely nailed the marketing page, I’ll keep in my list of products to follow up on :)
dmix 6y ago
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.

m12k 6y ago

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

vector_spaces 6y ago

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 https://github.com/vector-im/element-ios/issues/3762 [2] https://github.com/vector-im/element-ios/issues/3572 https://github.com/vector-im/element-ios/issues/3572 [3] https://github.com/vector-im/element-ios/issues/3393 https://github.com/vector-im/element-ios/issues/3393 [4] https://matrix.org/blog/2020/12/18/introducing-cerulean https://matrix.org/blog/2020/12/18/introducing-cerulean

pmlnr 6y ago
This is disturbingly good summary. I remember Matrix being presented as less bloated compared to XMPP... sure.
erikbye 6y ago

mnky9800n 6y ago

Remember when Facebook messenger was xmpp based? Lol.

sizeofchar 6y ago
Also Google Talk.

zelly 6y ago

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.

johnisgood 6y ago

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

Cthulhu_ 6y ago

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.