Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • The sad part of it, way back we had to deal with icq, msn, Yahoo and then had the chance to reunite every one with XMPP. But that dream failed. Now we have a gazillion of services with anoying things like FOSS projects using closed source services like WhatsApp as their community base.
  • I can relate. I run Synapse for only 2 users, and every update is like a lottery. "Unable to decrypt" most often. Logout 2-3 times, clear cache, then suddenly it works again.

    IRC was so easy. :(

  • as someone who wasn’t online in the IRC heydays i really wonder why we can’t just build on it, instead of inventing new protocols
  • I host a matrix server and have three friends in it. One or all of them being unable to decrypt messages happens every few months and there’s no easy way to learn WHY do I reboot the server.

    Annoying, but the other chat apps have trade-offs I don’t care for.

  • I've hosted my own synapse since 2019, maybe even earlier. Its the same virtualized instance, all I've ever done is update it. Never had to reboot it other than due to updates.

    Nothing in any logs?

  • said that, i manage a matrix instance in my company for more than 500 users, and everything works just fine. I like their device authorization models, their stack is easy to maintain and update. Everything works flawless. I used to maintain rocket chat in the same order of magnitude and it was a mess. I deploy it in Kubernetes + Authentik and I am pretty happy with the results. Long live to Matrix/Element!
  • I used to use Matrix. Its user experience was sub par, but in the end it rendered itself unusable to me before I had decided to abandon it of my own volition.

    As far as I can tell it isn't so much a protocol as a collection of apps talking different protocols while claiming to use the same protocol.

    by Lerc
  • The pain in admin'ing a server is real - even for my tiny one! I haven't bumped into these specifically with tuwunel, mostly SSO issues that have been resolved.

    But man being able to have all my chats bridged to one thing where I can comfortably sit in a client I control and can freely modify? The feature set and integrations available are really tough to beat.

  • I find the bridge setup rather suboptimal, but with a complete lack of a good Pidgin alternative for the modern age, it's the best system around, whether you do it with Matrix or with XMPP.
  • I feel this. And it doesn't even cover the very first conversation I have with my users.

      "You want to install Element"
      "But I want Matrix."
      "They call it Element now."
      "I want to speak on Element?"
      "No you want to speak on Matrix using Element."
      "Uh."
      "Don't worry about it. Look, just install Element."
      "Well, I see Element and Element X."
      "Oh right. Well, do you want to video chat?"
      "What?"
      "Element X doesn't video chat well. If you want video chat and a more featureful but slower chat experience, install Element.  If you don't care about reliable video chat and don't mind rooms jumping around and not organizing them, but you want to subscribe to a zillion of them, choose Element X"
      "What?"
      "Oookay, let me explain. See, once there were--"
      "Can't I just install the Matrix app?"
      "It's Element or Element X. Do you want to video chat?"
      "Um probably?"
      "Well then Element, not X, that's the one you want to start with."
      "Start with Element without the X?"
    
    It's so needlessly complex.
  • Element X does video chat just fine by now, doesn't it?
  • That's a strange conversation to have. Just compare it with email and they immediately get it
  • God, it reads like a slapstick comedy routine...
  • I usually recommend Element X on Android, FluffyChat if they complain too much about Element X after using it a bit, and nheko on desktop.

    It is really annoying that Element X is missing so many things Element had (you can't even do /me messages, markdown headlines aren't shown properly either), but getting someone to move apps is pretty tough, so might as well get them on the new one that will hopefully get better with time.

    Also I never tell people about voice or video in Matrix unless they ask, and if they do I tell them I don't use it, it's probably not great, and to just use Mumble for voice and Jitsi for video.

    by opan
  • Explaining to non-tech people that Matrix was email and Element was Gmail was easy to understand.
  • Element X does video calls fine. It's been ages since it was the messy beta you describe it as. In fact, it does calls better these days. There's no good reason to go with Element Classic anymore, I don't understand why they don't just drop the old thing.

    All the other things are just as true if you replace "Matrix" and "Element" with "email" and "outlook"/"gmail".

    If you don't think the person you're talking to understands the difference between apps and emails ("I can email outlook people from my gmail?" is a serious question these days), just don't mention it. They're not going to get into the weeds anyway.

    When I tried to explain the different "servers" in Discord to some a-technical people I had the same problem and disabling invites + not bothering with explaining the server concept seems to work out a lot better. I've given up trying to explain computer things to people who don't want to understand how the things they rely on work.

  • The unfortunate surprise with self-hosting Matrix is that Element X requires sliding sync and Element X cannot be installed on macOS if you have System Integrity turned off (I assume they store the keys in the Secure Enclave or something).

    Conduit gained support for SS fairly recently so that’s good.

    For a decent client, I’d recommend Cinny. There’s currently a fork of Cinny in development but it doesn’t work with my self-hosted server right now.

  • Element Desktop is the element desktop client (doesn't officially have sliding sync yet)
  • Remark half-way in the rant they are using dendrite, an experimental matrix server implementation that has been abandonned. Thus ranting about it is cheeky at best.

    I have been using synapse for years with little issue.

  • Hi, could you describe the environment you're using it? Thank you
  • I worked on Dendrite for a number of years, activity on it pretty much fell off a cliff after I left Element but there seems to be a fork called Zendrite that has carried on with development more recently. There is a migration path from a standard Dendrite installation: https://zendrite.pat-s.me/administration/migration-from-dend...
  • This is addressed two paragraphs later:

    > Years ago, when the server was set up, choosing Dendrite seemed like a good decision

    > Unfortunately, migrating between Matrix homeserver implementations remains a problem with no satisfying solution, so we're kind of stuck on slowly rotting foundations.

  • > Dendrite is kind of deprecated as a homeserver these days, at least it doesn't seem to be the main focus of development and most recent commits are mere dependency bumps. Years ago, when the server was set up, choosing Dendrite seemed like a good decision, because it was easier to deploy and maintain than Synapse and there was a promise for a bright future for the first 2nd generation homeserver implementation. Unfortunately, migrating between Matrix homeserver implementations remains a problem with no satisfying solution, so we're kind of stuck on slowly rotting foundations.

    Dendrite may or may not have been a good choice for a Matrix homeserver at the time the decision to start it was made, years ago. But the real problem, as the blog post points out, is that there is no good way to change that decision. Migrating to a new homeserver implementation is equivalent to destroying the old server and creating a new one from scratch - which also has the implication that any user whose account was on the old server loses that account and has to create a new one, because Matrix user accounts are tied to some homeserver (a bad design decision, I think). Tying system identity to someone else's server - and that server's domain name - is the cardinal sin of federated identity systems, the ActivityPub ecosystem has exactly the same problem.

  • Are there any real options in this space for something that is

    - E2EE

    - Large group capable (100+ users)

    - FOSS + self hostable

    - Not riddled with security issues

    - Relatively easy to use for iOS and Android users (safe for normies)

    I help run a Matrix server for people who are at risk from the current administration and I can attest to all of the issues mentioned plus a few more.

    I'd rather not move to something as hostile as Discord and while we've tried Stoat it's infinitely more buggy and the lack of iOS apps is causing problems.

    Rocket chat is interesting but E2EE is early in development, lots of security issues at last check.

    Simplex isn't going to be better for large group stuff, it has the same fundamental sync issues Matrix does and the devs are more interested in crypto than fixing that.

  • That’s Matrix. Matrix has spent too much time chasing Discord, with spaces, and group video chat, and email with federation. And too much time chasing Slack with threads. But everything you mentioned is core Matrix chat and works great on every client.
  • Chatto is what I am starting to lean into. Still early in development, but self-hosted version is available and the dev has been responsive and nice to chat to.
  • Maybe Delta Chat?

    UX feels less polished yet snappier than Element-Matrix and the project seems pretty active.

    https://delta.chat/

  • We (https://phnx.im/about) are building something new (https://air.ms). The website doesn’t yet mention self-hosting and federation, but we’d like to get there as well. Beyond that, our focus is on combining good UX with state-of-the-art security. It might not float everybody’s boat, but it should satisfy the list above.

    We are in an early phase right now, where we test the product with a limited number of people, hence the invitation-only approach. We intend to drop that towards the end of the year if all goes well.

    We helped co-author MLS, and we also contribute to the MIMI IETF working group. We’d like Air to be as standards-based as possible.

    We are also curious to learn about specific problems that folks think have not been solved yet in the space.

  • You‘re describing Wire. One could quibble about the FOSS part but it is open source (gplv3 or agpl). It’s used by a bunch of European governments and agencies, as well as American agencies, has regular security reviews and thanks to MLS, supports groups with more than 2k clients. Self hosting is a bit of a pain, but people are doing it.

    Give it a try

  • Doesn't XMPP check all those, and more? I run my local _ejabberd_ for a decade and some, and I'm joined to a couple 100+-users rooms. On my phone, I have a whatsapp-like experience with _Conversations_, that even the least tech-savvy in my circles use happily. On the laptop, I have _Gajim_, which is more "banquet-style" and serves to follow along fast-paced large rooms, most of which happen to be on IRC, but I don't even mind that, thanks to the _biboumi_ bridge which unceremoniously connects me there as if I was a regular IRC client. I also keep an eye on _movim_ which promises a more discord-like experience: it has gamers-style voice/video/screen-sharing rooms, it has spaces (although the paint isn't completely dry on those), and it's working on scaling-up calls to very large rooms by having galene as a SFU.

    What I find also amazing in all this is that all the client/server/bridge names I brought up are independent and healthy projects. XMPP is very mature and decentralized. Not just in theory by nature of its protocol, but practically/politically by its many implementations across many stacks and implementers across many countries.

    by ezst