Highlights include Sliding Sync (instant login/launch/sync), Native OIDC (industry-standard authentication), Native Group VoIP (end-to-end encrypted large-scale voice & video conferencing) and Faster Joins (lazy-loading room state when your server joins a room).

  • u_tamtam@programming.dev
    link
    fedilink
    arrow-up
    1
    ·
    1 year ago

    Not to dismiss the work of FOSS developers, but siskin seems quite primitive.

    Fair, but it does that in ways that do not deceive its users, as in, what it does it does pretty well.

    It does provide the very basic functionality that you could expect from any messenger from about 10 years ago but that’s about it.

    As far as I’m concerned, Instant messaging was a solved problem 20 years ago, we had practically more features in Yahoo and MSN Messengers (of which XMPP was a superset, for bridging and compatibility purposes), and Whatsapp, telegram and the rest have been removing the most distracting features. What are you missing for effective communication essentially?

    I may try to take another look, but I did have a ejabberd server that was passing pretty much all the tests in the conversations suite

    Are you talking about the compliance suite? As far as I remember, it’s pretty upfront about testing the capability but not the implementation (because testing for things like calls is very difficult and network dependent, you won’t get the same behavior from being behind a NAT or a public IP, and the test passing is no guarantee that it will work in the wild. Even Google's own WebRTC STUN/TURN testing tool is full of gotchas but is a good step to add to your testing).

    Which is kind of my beef with frustration with XMPP. There was never a whole combination of client/servers that would work consistent.

    There will never be a client nor a server that will implement all XEPs, because that’s not desirable: some fringe/IoT/obsolete cases just have no meaning nor use for most users, though there are some compatibility levels, updated regularly, that all maintained clients and developers target (e g. https://xmpp.org/extensions/xep-0479.html ). Under those circumstances you have a pretty good user experience.

    As long as this working implementation is working and it is open source with some community oversight, I don’t mind having a clear leader in the project.

    But how about the implementation not working so well in practice and with enormous trade-offs, and the leader being essentially a marketing agency running for funds while covering up those trade-offs or blatantly lying about them?

    The alternative is this eternal push-pull of forces that we had in XMPP, where we end up with a fragmented ecosystem which is never universally accessible.

    Beyond the facade of new vector’s products, Matrix is as much fragmented if not more. Why would it be otherwise? Nothing is fundamentally better: there’s a spec and people chasing it. Except that in the case of Matrix, the spec is just there for reference and eventually consistent with what’s in the code of synapse running matrix.org, which is actually what matters (and might be quite different from what your server is doing for a bunch of good and bad reasons). I’ve bumped into more client to server and server to server incompatibilities hosting Matrix for few months than I did over years and years of operating XMPP. Things are just so much more stable and mature there (and slow, and boring, which users and admins alike tend to appreciate for something so central to their lives).

    • rglullis@communick.newsOP
      link
      fedilink
      English
      arrow-up
      1
      ·
      1 year ago

      Instant messaging was a solved problem 20 years ago

      • Emoji support
      • Reactions
      • Share location in real-time
      • Threads in conversation
      • Media embeds

      AFAIK, none of that existed 20 years ago and all of that are features that expected of any basic messenger.

      how about the implementation not working so well in practice and with enormous trade-offs, and the leader being essentially a marketing agency running for funds

      GOTO 1. It’s the best one that we have (in practice) and it’s open source. If leadership ever becomes a real problem, it can be replaced.

      • u_tamtam@programming.dev
        link
        fedilink
        arrow-up
        1
        ·
        1 year ago
        • Emoji support

        XMPP had that in 2002, before emojis was a thing outside japan :)
        https://xmpp.org/extensions/xep-0038.html

        • Reactions

        2006: https://xmpp.org/extensions/xep-0201.html

        • Share location in real-time

        2003: https://xmpp.org/extensions/xep-0080.html

        • Threads in conversation

        2006 (see reactions)

        • Media embeds

        Which media? You had whiteboards in 2001 (https://xmpp.org/extensions/xep-0010.html), games in 2002 (https://xmpp.org/extensions/xep-0047.html), stocks in 2003 (https://xmpp.org/extensions/xep-0067.html), rich text (beyond markup) in 2003 (https://xmpp.org/extensions/xep-0071.html), mood (https://xmpp.org/extensions/xep-0107.html), activity (https://xmpp.org/extensions/xep-0108.html), maps (https://xmpp.org/extensions/xep-0110.html), tune (https://xmpp.org/extensions/xep-0118.html), co-browsing (https://xmpp.org/extensions/xep-0151.html), calls (https://xmpp.org/extensions/xep-0166.html), serverless (https://xmpp.org/extensions/xep-0174.html)

        and all those were added to XMPP because they were in widespread use in the popular messengers of that era (for the history lesson, XMPP was built first and foremost to bridge and unite all messengers). So, yeah, the trend has been going towards simplification over the years, not the opposite, and there were many many things that you could do in MSN Messenger in 2005 that you won’t be able to do in FB/WA/TG/Matrix/… :)

        • rglullis@communick.newsOP
          link
          fedilink
          English
          arrow-up
          1
          ·
          1 year ago

          XMPP had that …

          XMPP had all that, but there was no single application that implemented all of that. What we had was a hodge-podge of different applications, each trying to have their thing built into the standard but not really ever becoming an universal implementation. The fact that you can point to 11 (eleven!!) different XEPs as a response to “media embeds” should be a point of shame, not of pride.

          I understand your defense of open standards and I’d love if the bazaar model could’ve worked for XMPP. Unfortunately, it didn’t. It is taking a Cathedral to come up and implement something that is at very least workable in all major platforms and still open for those that want to deviate from the main effort.

          Is the Cathedral perfect? No, of course not. No institution ever is. But I can have my wife and my parents install Element on their phones (android or iOS) and be talking with them in less than 10 minutes, but I can not do the same with XMPP without having to accept a huge amount of compromises.

          • u_tamtam@programming.dev
            link
            fedilink
            arrow-up
            1
            ·
            1 year ago

            XMPP had all that, but there was no single application that implemented all of that.

            You seem to underestimate a lot the messaging landscape of back then :) It wasn’t a “XMPP thing” to implement those for laughs and giggles, it was the qualifying feature set of every popular app then, and XMPP clients like Gajim, Psi, Pidgin, … were competing against multi-protocol clients like Adium, Trillian, Telepathy, … and 3rd party ones (like aMSN, KMess, …) to implement the features of MSN, Yahoo, ICQ, … Yup, it was a zoo, but it was not XMPP’s. The only point of shame I see here is that we lost pretty much all the fun and innovation when everything became “mobile-first”.

            I understand your defense of open standards and I’d love if the bazaar model could’ve worked for XMPP. Unfortunately, it didn’t. It is taking a Cathedral to come up and implement something that is at very least workable in all major platforms and still open for those that want to deviate from the main effort.

            I don’t think this analogy is relevant there, and I certainly don’t think that the multitude of XEPs I listed are evidence of XMPP being akin to a bazaar: the XMPP protocol is very lean and coherent, and kept that way by the XSF. Those XEPs were meant to document and standardize the practices of the time.

            But I can have my wife and my parents install Element on their phones (android or iOS) and be talking with them in less than 10 minutes, but I can not do the same with XMPP without having to accept a huge amount of compromises.

            I have no idea what compromises you are talking about. I have SO, parents and many more, of all ages, abilities and systems having joined XMPP, with no difficulty whatsoever. The experience probably even is better here than on Matrix because not only can you generate invite links/qrcodes that contain a bootstrapped contacts list, there is also the option to discover contacts via mobile phone numbers (e.g. from quicksy.im, choegram) that comes handy in some contexts.

            • rglullis@communick.newsOP
              link
              fedilink
              English
              arrow-up
              1
              ·
              edit-2
              1 year ago

              I have no idea what compromises you are talking about. I have SO, parents and many more, of all ages, abilities and systems having joined XMPP

              “Joining XMPP” is a low bar. I’m talking about it having a viable, usable alternative with features that people are used to expect.

              You mentioned siskim as the best alternative for iOS which - looking at the main page and open github issues - does not seem to support reactions or group messaging. In 2023, this is not acceptable for anyone but the most hardcore apologists.

              • u_tamtam@programming.dev
                link
                fedilink
                arrow-up
                1
                ·
                1 year ago

                I have no idea what compromises you are talking about. I have SO, parents and many more, of all ages, abilities and systems having joined XMPP

                …and by that, I meant not just them logging into XMPP, but XMPP effectively dislodging WhatsApp and all other centralized proprietary apps, for the whole family. There is absolutely nothing they miss in terms of features using XMPP for day to day communications, and even the less savvy/older folks understand and appreciate that the niece’s birthday pictures are stored on the family NAS and not on some facebook server.
                Compared to Matrix, they get something that’s fast, light on their battery, light on their data plan, that has instant message delivery, that works behind firewalls (thanks to SRV and https multiplexing), has zero downtime, and more importantly, zero vaporware features like threads and spaces that barely work. I created our very first family room in 2015, and we’ve been using it uninterruptedly every single day since.

                Matrix is no alternative to XMPP for us. I tried very hard to make it work, but the running costs, the admin overhead and the constant need for user support (because you’ve got to explain basic features which are counter-intuitive like encryption, not to use this or that feature, why we’ve got to migrate rooms, why messages to the outside and to bridges sometimes take a long time to reach without notice nor warning, …) just makes it impractical and gives a bad impression. Matrix just isn’t that good when self-hosting.

                You mentioned siskim as the best alternative for iOS which - looking at the main page and open github issues - does not seem to support reactions or group messaging.

                I can assure you that Siskin supports groups. And reactions is a good example where Matrix could learn a lesson or two from XMPP and its extensibility and concern for compatibility: instead of splitting the world between clients that support the feature (i.e. Element and the poor suckers left behind), in XMPP land, reactions appear as reactions in clients supporting them, and as cited messages + emojis elsewhere. Not supporting reactions is sometimes a conscious choice by developers (for e.g. performance, accessibility reasons or limits of some platforms e.g. TUI), and this is totally acceptable because the meaning/intent of the discussion isn’t degraded.