Live data from Hacker News

Jabber/XMPP: 25 Years of Digital Independence

gultsch.de

101–110 of 183 posts

Re: Jabber/XMPP: 25 Years of Digital Independence

#101

Earlier quoted context omitted.

It makes sense. It's old, crufty mix of extensions, which nobody actually wants to be that modular for a chat client, because that just gets you into mess of what server/client supports

Matrix is nearly as old today as XMPP was when the Matrix project was started, and Matrix is still such a pile of shit standard that there's STILL only one server implementation and one client. That's actually not how the standard was designed; if Matrix had been a successful project, according to their own goals, the ecosystem would look a lot more like XMPP than it does. Comparing XMPP at 11 years old to Matrix tod…

At 11 years old, XMPP had 0 usable clients (I was there and tried them). That's one less than Matrix.

Re: Jabber/XMPP: 25 Years of Digital Independence

#102
post #96
post #80

Earlier quoted context omitted.

And of course most XMPP clients which support OMEMO only support an old version of it, which is incompatible with the new OMEMO version, currently only supported by KDE’s own client—Kaidan. That also happens to be the only desktop client I feel like I’d actually enjoy using (if only I could use it to talk with people not using Kaidan).

FWIW Converse.js and Dino also support the latest OMEMO.

Oh, nice! It looks like Converse.js has added it just two months ago, but I haven’t been able to find anything for Dino (only complaints about as old as the latest release, about the newest OMEMO not being supported). Was it shipped very silently, or are they perhaps planning to add it in an upcoming release?

Re: Jabber/XMPP: 25 Years of Digital Independence

#103
post #101

Earlier quoted context omitted.

Matrix is nearly as old today as XMPP was when the Matrix project was started, and Matrix is still such a pile of shit standard that there's STILL only one server implementation and one client. That's actually not how the standard was designed; if Matrix had been a successful project, according to their own goals, the ecosystem would look a lot more like XMPP than it does. Comparing XMPP at 11 years old to Matrix tod…

At 11 years old, XMPP had 0 usable clients (I was there and tried them). That's one less than Matrix.

XMPP at 11 years old would place us in the year 2010. Requirements were different in those times. Psi on my desktop and Bombus (a J2ME client) on my Nokia E71 worked great. The transition from that into the mobile-first age was rough though. The article says that too. It only improved in 2014-2015.

Re: Jabber/XMPP: 25 Years of Digital Independence

#105
In 2009, I worked for a company that was developing a modified version of Ignite Realtime's Spark IM client and I have vague memory of sending messages to Gtalk from it. Because of Google's support, XMPP was all the craze back then.

It's great to see that Openfire (Ignite Realtime's XMPP server) has had a release even last week! https://www.igniterealtime.org/projects/openfire/

Re: Jabber/XMPP: 25 Years of Digital Independence

#106
post #95

I love XMPP and am hopeful for its future with what the teams behind Movim[0], and Fluux[1] are doing. It was a tremendous shame that Matrix didn't improve upon XMPP and instead did their own thing. I continuously wonder what would the XMPP ecosystem look like, if the millions of dollars of funding Matrix initially had (what a waste) went to XMPP instead? [0]: https://movim.eu/ [1]: https://github.com/processone/fluu…

Yeah yeah yeah. I’ve heard this for 8 years. And yet, everyone can talk a great game, no one can build a mobile client that is anywhere near the quality of any other chat platform. And here I am, hosting a Matrix server for my family for 6 years now, with no issues and an amazing experience, from the backend to the huge variety of mobile clients, a mature Rust sdk that I can hook bots into with ease, etc.

Matrix doesn't even support server-to-client message pushing, only polling. Which means, if you want your phone to receive a message while your client is in the background, you have to use a non-Matrix protocol to receive those.

This protocol is XMPP in 99% of the time, both Apple and Google use XMPP to connect the phones to their push notification service.

On Android, some Matrix clients offer the option to use non-Google push notification channel via UnifiedPush. UnifiedPush needs a distributor, a service that runs on the phone and manages the delivery of push notifications. Conversations, a popular Android XMPP messenger, can be used as such distributor.

So if you want digital independence with Matrix and thus do not want to use Apple/Google push, you might end up installing an XMPP messenger, so that your Matrix messenger actually can show notifications. Matrix alone just doesn't provide what is needed for digital independence.

Re: Jabber/XMPP: 25 Years of Digital Independence

#107

I love XMPP and am hopeful for its future with what the teams behind Movim[0], and Fluux[1] are doing. It was a tremendous shame that Matrix didn't improve upon XMPP and instead did their own thing. I continuously wonder what would the XMPP ecosystem look like, if the millions of dollars of funding Matrix initially had (what a waste) went to XMPP instead? [0]: https://movim.eu/ [1]: https://github.com/processone/fluu…

It's because the xmpp standard is absolutely brutal. I've tried to stand up a server and the amount of configuration I had to do just to get off the ground was absolute nonsense. It's sort of the Apache of chat protocols and that's not a compliment.

What server was that? I got into the XMPP self hosting game in 2014, even then, ejabberd was one of the most "fire and forget" piece of server software I was running. It takes some ports opening and some DNS SRV records to be set and you are good to go with all chat, calls and social features.

Re: Jabber/XMPP: 25 Years of Digital Independence

#108
post #102
post #96

Earlier quoted context omitted.

FWIW Converse.js and Dino also support the latest OMEMO.

Oh, nice! It looks like Converse.js has added it just two months ago, but I haven’t been able to find anything for Dino (only complaints about as old as the latest release, about the newest OMEMO not being supported). Was it shipped very silently, or are they perhaps planning to add it in an upcoming release?

Looks like I might have been wrong about Dino, sorry about that.

I worked on adding OMEMO2 support to Converse.js via libomemo.js and I tested it against Kaidan.

Re: Jabber/XMPP: 25 Years of Digital Independence

#109
post #90
post #57

Earlier quoted context omitted.

Actually, Matrix has a series of server and client implementations. Servers: https://matrix.org/ecosystem/servers/ Clients: https://matrix.org/ecosystem/clients/ Also, imho Matrix is a better standard than xmpp, because of what PunchHamster said and the better feature set. Of course, everyone is entitled to their own opinion :)

I think GP was speaking hyperbolically, because most new features hit Element/Synapse first and other clients lag behind implementing them. If you care about more than the basics working, it's kind of just the illusion of choice.

Probably, and also from the fact that although there's a plethora of matrix clients and servers on paper, none is as feature complete (or feature-complete to the point of usefulness, I might say) as "the one". XMPP has about one decent-to-great client per platform and multiple fully compatible and interoperable server implementations, and every single one of them is by different groups.

Re: Jabber/XMPP: 25 Years of Digital Independence

#110

I love XMPP and am hopeful for its future with what the teams behind Movim[0], and Fluux[1] are doing. It was a tremendous shame that Matrix didn't improve upon XMPP and instead did their own thing. I continuously wonder what would the XMPP ecosystem look like, if the millions of dollars of funding Matrix initially had (what a waste) went to XMPP instead? [0]: https://movim.eu/ [1]: https://github.com/processone/fluu…

As I understand it, Matrix is a much better conceptual fit for the IRC/Slack-like use case where users expect substantial messaging history to persist across new devices and often even for members newly joining a channel. XMPP started out as a message routing protocol, with server-side history (for individual users or channels) bolted on as an afterthought; Matrix is modeled around conversations/channels as a first-class object on the server side.

Of course, that doesn't automatically make it great at what it's trying to do, nor does it make XMPP terrible in practice, but between mixed extension support at the client and server side, with XMPP you can never really know if you're getting "plain old Jabber" or something more like Matrix in terms of user experience.

Post reply on HN