- cross-posted to:
- [email protected]
- cross-posted to:
- [email protected]
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).
Not to dismiss the work of FOSS developers, but siskin seems quite primitive. It does provide the very basic functionality that you could expect from any messenger from about 10 years ago but that’s about it.
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, but I did not manage to make calls between pidgin and conversations.
Which is kind of my beef with frustration with XMPP. There was never a whole combination of client/servers that would work consistent.
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. 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.
Well, yeah… but since when it is a good idea to let a server unpatched/out-of-date in the public internet?
Fair, but it does that in ways that do not deceive its users, as in, what it does it does pretty well.
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?
Are you talking about ? 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 is full of gotchas but is a good step to add to your testing).
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.
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?
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).
AFAIK, none of that existed 20 years ago and all of that are features that expected of any basic messenger.
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.