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

131–140 of 183 posts

Re: Jabber/XMPP: 25 Years of Digital Independence

#131

Post by tcfhgj »

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

> Debatable, this mostly boils down to the client design choices and priorities, and has little to nothing to do with the protocol.

I think it does.

How would you as a client choose that the (potentially) encrypted chat history of all rooms is immediately available after logging in, let alone after joining an encrypted room?

You can't:

- how long messages are stored server side depends on someone else's server

- encrypted messages aren't recoverable from new sessions

Re: Jabber/XMPP: 25 Years of Digital Independence

#132

Post by _flux »

pixelschubsi wrote: post #106
pkulak wrote: post #95

Earlier quoted context omitted.

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

The protocol of Matrix does long polling though. Is there a big difference? You want at least heartbeat to detect a broken connection (at least from client end), and it looks like XMPP does not come with server-originated hearbeat for that purpose, so it's back to client-side pinging?

Re: Jabber/XMPP: 25 Years of Digital Independence

#133

Post by Dormeno »

edhelas wrote: post #119
Dormeno wrote: post #116

Why is every XMPP client a worse experience than Telegram? I don't get it.

Define worse

This is not an exhaustive list, just stuff off the top of my head.

Finding/viewing/sharing/joining chats

Adding users (can't find them, invites not being received, etc)

Broken messaging (messages not arriving, formatting not being handled or handled the same way, even on the same XMPP server!)

OMEMO issues (key exchange not working, or OMEMO keys getting lost or something when both clients involved were working perfectly fine the day before - Telegram's E2E doesn't break randomly and no, there isn't a MitM issue)

Clients asking for encryption, but then get mad because you're using Thunderbird's XMPP implementation and complain they don't like the encryption supported by Thunderbird.

Not being able to disable encryption on some clients (I actually rather not have encryption anymore because of all the problems)

Multi-device messaging issues (fresh chats can have messages going to one device but not the one the user is active on or history synchronisation)

Mobile notifications inconsistently working, even when using external push messaging providers (it works consistently always on Telegram, it's even more consistent with Matrix, even though Matrix has more push disadvantages)

Client crashes (I can't even remember when Telegram last crashed, but Pidgin crashed on me today and it has only a single XMPP account on it)

Clients failing to connect without useful information (Siskin no longer connects to my account and the only indication is that the "enabled" button becomes disabled, despite the account working on other clients and devices)

UI lockups (Miranda NG, Psi, Gajim, and Pidgin all tend to become unresponsive for short periods of time, probably a blocking wait being imposed in the UI for some reason?)

Common issues that every modern messaging application has, like voice and video, are barely supported overall despite being fully supported in the XMPP standards (file sending is even an issue for Thunderbird)

There is next to no failure recovery on most XMPP clients. Anything that fails on Telegram will try to recover and resend without needing the user to intervene and helpfully displays it's working on it.

Re: Jabber/XMPP: 25 Years of Digital Independence

#134

Post by ezst »

lxgr wrote: post #122
ezst wrote: post #117

Earlier quoted context omitted.

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

> But why wouldn't it be possible to have these two in the same app

I don't believe it's "impossible" to have both in a same app, it's just that the kind of high-density UI and advanced features you depend upon for high-volume chats rarely intersect with family-scale/1-to-one chats, so you either make compromises that directly affect usability/efficiency, or you essentially end-up with 2 chat paradigms at odds in a same client.

> As to whether one protocol can address both use cases: Maybe it doesn't need to either?

It depends what you mean by protocol in this case. Chat rooms (MUCs in the XMPP verbiage) are handled by a specific component, so it's practically happening the way you describe, but at its core, the "message-passing" (stanza-based) nature of the XMPP protocol doesn't change.

Re: Jabber/XMPP: 25 Years of Digital Independence

#135

Post by mvdwoord »

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?

You can find some clues in the published service catalog of the NATO Communications and Information Agency (NCIA) here: https://www.ncia.nato.int/about-us/service-portfolio/custome...

It seems their "JChat" application is based on XMPP.

Re: Jabber/XMPP: 25 Years of Digital Independence

#136

Post by ezst »

JadedBlueEyes wrote: post #129
ezst wrote: post #109

Earlier quoted context omitted.

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

Last I checked (couple years ago?) it was ill-advised to use anything but Synapse, because:

- you would be at the mercy of very real and frequent federation problems (Matrix being so implementation-dependent and centred around Synapse ; like, the json serialization format is better described as "whatever order and structure python's stdlib is doing"¹)

- there is no non-destructive way back to another server (the open federation would just reject you, and you would have to "start anew"). Interestingly, that last one pushed some servers over the fence and into XMPP, and they could then switch implementations (e.g. from prosody to ejabberd) effortlessly.

¹: https://telegra.ph/why-not-matrix-08-07#:~:text=matrix%20hom...

Re: Jabber/XMPP: 25 Years of Digital Independence

#138

Post by pixelschubsi »

_flux wrote: post #132
pixelschubsi wrote: post #106

Earlier quoted context omitted.

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

The protocol of Matrix does long polling though. Is there a big difference? You want at least heartbeat to detect a broken connection (at least from client end), and it looks like XMPP does not come with server-originated hearbeat for that purpose, so it's back to client-side pinging?

Well, apparently long polling is so bad on battery that Matrix clients for phones prefer to just not provide background notifications without any external push service. From what I understand, many Matrix services give their long polling a timeout of 60 seconds, which would prevent a phone from entering deep-sleep states.

XMPP uses a persistent connection. These are kept alive using TCP keepalive (both from server and on the client, but client side will be handled by the MPU and thus doesn't need CPU wake-up) and client initiated application protocol pings at intervals of 5 minutes or even less. Client initiated pings are much better on the application protocol, because they can be synced with other operating system tasks and thus don't need any active wake-up.

Re: Jabber/XMPP: 25 Years of Digital Independence

#140

Post by ee334y5rthsrth »

grugdev42 wrote: post #137

XMPP is great. You can own your whole stack with no commercial restrictions. If you're coming from Slack, this plugin is a game changer: https://modules.prosody.im/mod_slack_webhooks sudo prosodyctl install --server= https://modules.prosody.im/rocks/ mod_slack_webhooks

tox is this same, but you dont need install any program. just start
Post reply on HN