I’m looking into hosting one of these for the first time. From my limited research, XMPP seems to win in every way, which makes me think I must be missing something. Matrix is almost always mentioned as the de-facto standard, but I rarely saw arguments why it is better than XMPP?

Xmpp seems way easier to host, requiring less resources, has many more options for clients, and is simpler and thus easier to manage and reason about when something goes wrong.

So what’s the deal?

  • @rglullis@communick.newsEnglish
    54•7 months ago

    has many more options for clients,

    The problem of XMPP is here. These options are not uniform among the possible different combinations of servers and clients.

    The situation has improved a lot, but there was a point in time where saying “this is my XMPP handle” was far from enough to know if you’d be able to communicate with others, and you’d have to figure out things like:

    • Does the server support MUC?
    • Does the server support E2E? If so, which?
    • Are emojis supported on the server, or do they get converted to ASCII?
    • Can you use audio calls? If so, which codec?
    • If my client supports “share live location”, what do you see on your end?

    Not to mention that until recently there was no decent XMPP client for iOS. Even today, the best alternative is siskin, which may have its vocal fans but quite frankly is pretty barebones and has a UI that would be considered ugly even in 2010.

    Matrix as a protocol is technically worse than XMPP and Synapse is a resource hog compared to Prosody and Ejabberd? Yes, true. But at least I can tell non-technical people to download Element from the App stores and they will have a consistently-not-great-but-acceptable-and-improving experience.

    • DerinEnglish
      18•7 months ago

      This is the correct answer, IMO.

      I loved using XMPP back in the day, but I struggled talking with people who weren’t on the same server as me because of spec and client variations.

      While Synapse is a resource hog, it (and Element) - to a certain degree - does the job. Can’t wait until sync v3 lands in the main server.

      The only issue I have is with one friend who insists on deploying his own version of Synapse, but can’t figure out coturn and - as a result - we can’t voice chat properly.

      Goddammit. Two steps forward, one step backward. 😅

      • @helenslunch@feddit.nlEnglish
        9•7 months ago

        Funny I just launched Conduit this morning. Seems to work better than Synapse and is supposedly lighter.

        • DerinEnglish
          9•7 months ago

          Conduit sounds very exciting - but my synapse installation (and its concomitant database) is too old and big for me to make a switch to anything else just yet.

          But I’m hoping Dendrite will one day allow me to migrate over - I don’t like how one of my most mission critical programs is a Python program running out of a packaged venv. 😅

      • antsuEnglish
        2•7 months ago

        Suggest your friend to give Eturnal a try maybe. I have it running on an Oracle free tier instance, and I use it daily to have video calls with my family using Synapse/Element (and Jitsi inside Element for group calls), and it works great. The documentation is very good too.

        Edit: this is my Eturnal config, for reference:

        eturnal: listen: - ip: "::" port: 3478 transport: udp enable_turn: true - ip: "::" port: 3478 transport: auto enable_turn: true - ip: "::" port: 5349 transport: tls enable_turn: true realm: turn. tls_crt_file: /etc/letsencrypt/live/turn./fullchain.pem tls_key_file: /etc/letsencrypt/live/turn./privkey.pem tls_options: - no_tlsv1 - no_tlsv1_1 - cipher_server_preference

        And the compose file: services: eturnal: container_name: eturnal image: ghcr.io/processone/eturnal:latest environment: ETURNAL_RELAY_MIN_PORT: 49160 ETURNAL_RELAY_MAX_PORT: 59160 ETURNAL_RELAY_IPV4_ADDR: ETURNAL_RELAY_IPV6_ADDR: ETURNAL_SECRET: volumes: - ./eturnal.yml:/etc/eturnal.yml:ro - /etc/letsencrypt:/etc/letsencrypt:ro restart: unless-stopped read_only: true cap_drop: - ALL security_opt: - no-new-privileges:true network_mode: host

        • DerinEnglish
          1•7 months ago

          Ooh, I’ll tell them to try it out - looks cool, cheers!

    • @mbirth@lemmy.mbirth.ukEnglish
      5•7 months ago

      But at least I can tell non-technical people to download Element from the App stores and they will have a consistently-not-great-but-acceptable-and-improving experience.

      Conversations on Android looks and feels like any other modern messenger and supports basically all the XMPP features there are. And I found Monal on iOS to be pretty usable as well, when I tested it 3 years ago.

      • poVoqEnglish
        5•7 months ago

        Yes, Monal is catching up to Siskin fast, but until recently didn’t support a/v calls which is why many people still prefer Siskin.

        As for a unified system, have a look at https://snikket.org which offers a one-stop solution under a single brand similar to Element. It uses lightly modified versions of Conversations, Siskin and Prosody (as a server) under the hood.

      • @rglullis@communick.newsEnglish
        3•7 months ago

        Conversations on Android seems to be the default answer for “advanced client”.

        But for everything else… look at Monal’s blog, they only added support to audio calls in October of last year. Nice to see it’s still being developed, but “too little, too late” seems fair.

        • poVoqEnglish
          2•7 months ago

          The other XMPP client for iOS called Siskin has had a/v calls for many years now.

          • @rglullis@communick.newsEnglish
            3•7 months ago

            Yeah, I mentioned it in the first comment. But seriously, it looks like something built in 2009. It might be functional, but only a die-hard XMPP fan would be interested in using it.