Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Jabber/XMPP: 25 Years of Digital Independence

gultsch.de

Post reply on HN
Print view View original

121–130 of 183 posts

Re: Jabber/XMPP: 25 Years of Digital Independence

#121

Post by lxgr »

rtpg wrote: post #113
lxgr wrote: post #110

Earlier quoted context omitted.

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-c…

I was generally "Matrix feels right" but I read through [0] and other discussions and I think that Matrix's E2E focus + way of duplicating everything just means that it suffers a lot of scalability issues that "plain old Jabber" won't have. now Jabber has client issues, but stuff like Monal "basically work" for text + images + chat rooms. I'm excited for Fluux. You can of course set up one of the random web clients.…

> notifications is a solved problem.

Eh, last time I tried I still got leftover notifications for messages I had long read and even replied to on a different client hanging around on my other devices. (To be fair, Matrix does the same thing too, but only in roughly 50% of all cases, which is much more infuriating than something I can at least understand as a fundamental protocol limitation and not a weird implementation bug.)

I've been using XMPP on and off over the past 20 years and I would really love it to succeed, but papercuts like these need to be solved before I can recommend it even to technically open-minded friends.

> But like... at a basic level, "I'm hosting a Jabber server for my small community" has a lot less headaches than with Matrix. Yes if your server goes down then you lose the chat. Oh no. Plenty survived off of IRC IMO.

It might be great for that, but by the same token it's quite terrible as a persistent personal messaging handle. Durable identity/handles shouldn't be so bound to a community, since it makes it very hard to switch and you need to put an incredible amount of trust in the admin(s) as a result. (This is a tangent to the Matrix vs. XMPP point, as both have the same issue, as far as I can tell.)

Ideally, I'd like to have me@mydomain.com as my persistent XMPP ID that I can freely migrate across servers just by updating a DNS record without having to worry too much about who is actually hosting the server. The AT protocol does this right.

Re: Jabber/XMPP: 25 Years of Digital Independence

#122

Post by lxgr »

ezst wrote: post #117
lxgr wrote: post #110

Earlier quoted context omitted.

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-c…

> Matrix is a much better conceptual fit for the IRC/Slack-like use case Debatable, this mostly boils down to the client design choices and priorities, and has little to nothing to do with the protocol. Someone came-up with a metaphor I like to illustrate it: the banquet and the barbecue¹. XMPP has "barbecue"-style clients like Conversations, Kaidan, Dino?, and other that are rather "banquet"-style like Gajim, Fluux,…

> Someone came-up with a metaphor I like to illustrate it: the banquet and the barbecue¹.

That's a nice way of putting it and it definitely resonates with my experience.

But why wouldn't it be possible to have these two in the same app as long as they are very cleanly separated in terms of who gets to notify me when, what's displayed where etc.?

WhatsApp (with channels) and Telegram (with its huge groups) seem to address both just fine, as far as I can tell, although I barely use their "mass-messaging/social-media-like" features.

As to whether one protocol can address both use cases: Maybe it doesn't need to either? I could see 1:1 chats and "ephemeral/barbecue" groups using one type of history persistence policy (i.e. usually none) and large group chats/pub-sub-like feeds another. This could all be independent of what holds somebody's persistent identity/identities.

Re: Jabber/XMPP: 25 Years of Digital Independence

#123

Post by liotier »

AlecSchueler wrote: post #114
inputmice wrote: post #3

Earlier quoted context omitted.

XMPP these days often gets used as a friends-and-family style messenger (Think WhatsApp, iMessage, Signal replacement) rather than something communities would use (Discord/IRC). A lot of users of XMPP are also out of the public eye. NATO, police forces and intelligence agencies use it. The community style channels are supported though and a search engine for them can be found here: https://search.jabber.network/chann…

> NATO, police forces and intelligence agencies use it Is there anywhere to read more about this?

The existence of "XEP-0365: Server to Server communication over STANAG 5066 ARQ" suggests military usage. Isode advertises XMPP as "The NATO Standard for instant messaging" (https://www.isode.com/secure-xmpp/) and it is one of their core offerings. I remember seeing NATO command posts using IRC long ago - makes sense because it is ultra light, and therefore usable on extremely low bitrate degraded links... XMPP seems to be the successor for that purpose.

https://www.sigidwiki.com/wiki/XMPP_trials says "On shortwave, you can see the military use this protocol. They are known for using MIL 188-110A Serial HF waveform (fixed 600bps/S) and 6-bit code clear text with dual bursts of STANAG 4539 and STANAG-5066 as for XMPP Multi-User Chat (MUC) messages, over a bandwidth of 34 kHz. Multi-User Chat (MUC) is a central service for military communication. [..] XMPP is widely used for military deployments, where operation over constrained and degraded networks is often essential, particularly for tactical operation"

Re: Jabber/XMPP: 25 Years of Digital Independence

#124

Post by akho »

tcfhgj wrote: post #59
akho wrote: post #50

Earlier quoted context omitted.

Matrix is in the same place wrt feature mismatches. It's a quality of the problem, not of the solution. I actually think XMPP does a better, more structured job here.

> Matrix is in the same place wrt feature mismatches. not it isn't - still today there's no choice between incompatible room types or incompatible encryption algorithms and whatever else.

Calls are implemented differently across clients, threads only sometimes work. And, apparently from your comment, there's only ever going to be one encryption algorithm, because cryptography is a solved problem now?..

Re: Jabber/XMPP: 25 Years of Digital Independence

#125

Post by regularfry »

rtpg wrote: post #113
lxgr wrote: post #110

Earlier quoted context omitted.

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-c…

I was generally "Matrix feels right" but I read through [0] and other discussions and I think that Matrix's E2E focus + way of duplicating everything just means that it suffers a lot of scalability issues that "plain old Jabber" won't have. now Jabber has client issues, but stuff like Monal "basically work" for text + images + chat rooms. I'm excited for Fluux. You can of course set up one of the random web clients.…

I found snikket to be pretty much perfect for the use case I wanted, which was something locally-hosted I could drop in a VM so I had a channel for talking to bots that didn't need API keys for third party services.

The only downsides I've experienced are:

1. Images and accompanying text get separated, which turn-based bots get confused by. I seem to recall there's a standard for this but it's not implemented.

2. XMPP support isn't common in claw-type agents so I've had to patch it in. Not a terrible experience overall.

I had a look at Matrix but bounced off Element, hard.

Re: Jabber/XMPP: 25 Years of Digital Independence

#126

Post by lxgr »

regularfry wrote: post #125
rtpg wrote: post #113

Earlier quoted context omitted.

I was generally "Matrix feels right" but I read through [0] and other discussions and I think that Matrix's E2E focus + way of duplicating everything just means that it suffers a lot of scalability issues that "plain old Jabber" won't have. now Jabber has client issues, but stuff like Monal "basically work" for text + images + chat rooms. I'm excited for Fluux. You can of course set up one of the random web clients.…

I found snikket to be pretty much perfect for the use case I wanted, which was something locally-hosted I could drop in a VM so I had a channel for talking to bots that didn't need API keys for third party services. The only downsides I've experienced are: 1. Images and accompanying text get separated, which turn-based bots get confused by. I seem to recall there's a standard for this but it's not implemented. 2. XMP…

> XMPP support isn't common in claw-type agents so I've had to patch it in.

I found this pretty baffling/sad. Why do these agent harnesses have messaging plug-ins for the most obscure messaging platforms but not XMPP? It seems like a no-brainer!

People would apparently rather pay for a second number/SIM/phone dedicated to Openclaw on WhatsApp and suffer periodic outages due to Meta actively discouraging automation use than set up a minimal XMPP server and client...

Even setting up Matrix (at least with E2E encryption) was incredibly painful. It worked in the end for me, but the amount of tokens I've had to burn... And I don't even want to think about the next update.

Re: Jabber/XMPP: 25 Years of Digital Independence

#127

Post by tcfhgj »

akho wrote: post #124
tcfhgj wrote: post #59

Earlier quoted context omitted.

> Matrix is in the same place wrt feature mismatches. not it isn't - still today there's no choice between incompatible room types or incompatible encryption algorithms and whatever else.

Calls are implemented differently across clients, threads only sometimes work. And, apparently from your comment, there's only ever going to be one encryption algorithm, because cryptography is a solved problem now?..

Don't Element Continuwuity, Synapse, Sable, FluffyChat and more all implement Matrix RTC, because this is most likely the future of video calls in Matrix (while not even officially part of the spec at this point)?

> And, apparently from your comment, there's only ever going to be one encryption algorithm, because cryptography is a solved problem now?..

That's not from my comment. If there will be another one it likely will be integrated into THE specification such that it will NOT divide the ecosystem into "I prefer MEGOLM" and "I prefer to implement new thing".

Re: Jabber/XMPP: 25 Years of Digital Independence

#128

Post by thiht »

1970-01-01 wrote: post #17

XMPP is the pinnacle of chat that just works. And it is champion by default, which is kind of the point here. All other popular systems and servers went defunct; it will never be taken over by BigCo and left to rot. Here's to 25 more years!

> XMPP is the pinnacle of chat that just works

My limited experience is that it's not the case. When I tried to join a few rooms I got insulted because my client apparently used extensions that weren't supported by some XMPP enthusiasts' clients, so my client sucked and I had to change it and use an ugly one instead.

I'd rather get a feature-complete protocol than an extensible one, so that at least everyone can speak the same

Re: Jabber/XMPP: 25 Years of Digital Independence

#129

Post by JadedBlueEyes »

ezst wrote: post #109
opan wrote: post #90

Earlier quoted context omitted.

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.

I mean for alternative servers, 10% of people use Continuwuity and it looks pretty spec-complete [0] and more than enough to be useful.

[0]: https://forgejo.ellis.link/continuwuation/continuwuity/issue...

Re: Jabber/XMPP: 25 Years of Digital Independence

#130

Post by tcfhgj »

opan wrote: post #89
zaik wrote: post #48

Earlier quoted context omitted.

> mess of what server/client supports If you allow for independent implementations of the protocol this will always happen. Also, inventing another non-standard protocol creates even more incompatibility between clients and servers.

IRC and email worked out pretty well I think.

e-mail stuck in time still not enceypting by defaul
Post reply on HN