Matrix, the open protocol for secure decentralised communications

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