Rendered at 18:51:37 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
fishgoesblub 1 days ago [-]
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?
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.
ezst 11 hours ago [-]
> 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, Movim, …
I personally use Conversations on the go and Gajim otherwise. I also happen to have interfaced all my "high-volume/many-participants" IRC chans from back in the days with the biboumi² gateway, so they appear to my XMPP clients as native XMPP groupchats, and the experience was great-enough for me to ultimately drop weechat a decade or so ago and have all my "banquet"-style chans under one XMPP roof.
> 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.
From over a decade of using XMPP daily, this concern is more of philosophical nature than anything. The vast majority of the people you'll reach over XMPP use a decently modern and maintained client that will "just work". Worst case, they will still be getting your messages and the meaning across, because the "message passing" core of XMPP was defined 25-odds years ago and hasn't changed.
The real "risk" for XMPP would be to have a large number of users stuck on an unmaintained client, and users staying behind for years while the ecosystem moves on. We had a bit of that with pidgin 8-or-so years ago. The worse that happens is that you can't use the latest E2EE scheme with them, or that attachments are slower to arrive, this sort of things. That's IMO not bad for a 25 years old protocol that's truly decentralized.
> 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
lxgr 10 hours ago [-]
> 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.
ezst 9 hours ago [-]
> 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.
account42 3 hours ago [-]
> We had a bit of that with pidgin 8-or-so years ago.
8 years ago? Pidgin still doesn't do MAM today.
selfhoster1312 3 hours ago [-]
Yes, but i haven't met someone who uses Pidgin in more than 5 years. Still, the pidgin team appears to be alive and their blog is always a good read!
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. Stuff like reactions "work", notifications is a solved problem.
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.
For the HN crowd... I would say that there's still fun jank, but who doesn't like jankiness in their programs for fun? People should swarm to this opportunity to have some fun with busted tooling again!
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.
lxgr 10 hours ago [-]
> 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.
singpolyma3 6 hours ago [-]
Submit patch?
lxgr 10 hours ago [-]
> 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.
rtpg 8 hours ago [-]
> 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.
I suppose here you're saying "I should be able to do this without providers having to do work"? Like you show up with lxgr@foo.com to bar.com and create an account, and everything kinda fits into place (modulo you having to set up some DNS?)
It is already possible of course to have XMPP server at domain A handle things for domain B as well. But it is cool how ATProto seems to really bake in the concept of "all domains are welcome".
lxgr 5 hours ago [-]
Not quite. I'd like to have lxgr@example.com hosted at xmpp.foo.com today, but if foo.com shuts down unexpectedly one day, I'd like to be able to redirect it to xmpp.bar.com.
I might lose my chat history and maybe my contact list if I don't have a local backup of it, but people would still be able to reach me as lxgr@example.com. Ideally, I'd be able to upload my local, end-to-end encrypted backup to xmpp.bar.com and continue exactly where I left off.
AT proto's main innovation to me is decoupling the concerns of user identifier and data host at the protocol level, in the same way that DNS and my web or mail host are decoupled.
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.
pixelschubsi 12 hours ago [-]
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.
tcfhgj 7 hours ago [-]
> 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.
(aside long polling which I cannot comment) why is this a even an issue?
Centralized push services (may it be FCM or unified push) are at this point well established.
As a user using a specific messenger app as a push service doesn't gain me anything, it only makes it more difficult to switch messenger app if i choose to use it and mostly use an additional push service (hurting battery life), because most receive push notifications via Google anyway.
_flux 9 hours ago [-]
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?
pixelschubsi 8 hours ago [-]
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.
agile-gift0262 13 hours ago [-]
Not sure about iOS, but for Android Conversations is great
edhelas 13 hours ago [-]
Movim author there, thanks ! :)
shadowgovt 17 hours ago [-]
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.
Semaphor 16 hours ago [-]
> I've tried to stand up a server and the amount of configuration I had to do
I run my own server for 2 people. Using Prosody [0] took some config but wasn’t that hard. Easier than installing Arch, harder than installing Windows ;)
Nowadays, there is also Snikket [1] by the Prosody maintainer, which is essentially an opinionated all-in-one configuration setup based on Prosody, barely any config needed.
to anyone reading this who is thinking of setting up snikket: suffer through setting up prosody. It's a bit futzy but you won't find yourself saying "ah if only I had tried a bit harder" 10x a minute when trying to configure things later on.
agile-gift0262 13 hours ago [-]
Try out Snikket. Really easy to set up, with sensible defaults. You just docker compose up and have a pretty funcional XMPP server without needing to configure much. Adding complex things such as gateways onto Snikket is a bit more complicated, as you have to deal with Docker volumes etc to put the right file in the right place, but I found it easy to manage. I've been running my Snikket instance with gateways for WhatsApp and Matrix for a couple of years now and I'm really happy. It's very low maintenance
tredre3 16 hours ago [-]
Counter point: I ran prosody for years and changed almost nothing to the defaults.
Just like with Apache, all you need is a sane default configuration that covers the most common use cases, and I think modern XMPP servers offer that.
Semaphor 14 hours ago [-]
FWIW, I think I had to fight a bit to figure out setting everything up correctly for uploads to work. But as I said in sibling, nothing too problematic.
ezst 12 hours ago [-]
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.
PunchyHamster 22 hours ago [-]
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
akho 21 hours ago [-]
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.
neilalexander 21 hours ago [-]
XMPP leans heavily on capability negotiation and service discovery which makes it straightforward to degrade gracefully when feature mismatches occur. Matrix is significantly lacking in this regard.
shadowgovt 17 hours ago [-]
Unfortunately, some of the features that can degrade are things like "the chat is actually secure."
opan 15 hours ago [-]
I strongly prefer that with XMPP I can disable the encryption when it breaks to tell my friend I'm trapped under a boulder and bleeding out. With Matrix our chat is encrypted, I can't turn it off ever, if it stops working I can't communicate, my only option is to make a new room with encryption disabled and invite my friend hoping he sees the invite and accepts in time.
Dormeno 11 hours ago [-]
It's funny because I remember having an issue where my friend was sending me messages, and he couldn't read my messages, and my mobile client (Siskin) didn't let me turn off encryption for outgoing messages.
oivaksef 13 hours ago [-]
I want to see this movie
Edit: now I can't stop thinking about correlation vs causation - you being under the boulder bleeding out at the same time XMPP encryption suddenly stops working.
Physical hardware certificate thinggy which got crushed?
306bobby 6 hours ago [-]
That's how RCS's Universal Profile is too though as far as I understand with the new encryption standards.
Id rather someone be able to reach out to me with a note the chat is insecure, rather than be unreachable at all
tcfhgj 20 hours ago [-]
> 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.
akho 10 hours ago [-]
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?..
tcfhgj 10 hours ago [-]
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".
selfhoster1312 2 hours ago [-]
I don't have a horse in this race, but "incompatible room types" is precisely an issue i encountered on a selfhosted server. Agreed, that was for S2S federation and not C2S, but that was an issue.
vcccgjuf 21 hours ago [-]
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 today makes it abundantly clear that the main thing Element LLC does is waste European public grant funds
tcfhgj 20 hours ago [-]
Actually, Matrix has a series of server and client implementations.
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 :)
opan 15 hours ago [-]
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.
ezst 11 hours ago [-]
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.
JadedBlueEyes 9 hours ago [-]
I mean for alternative servers, 10% of people use Continuwuity and it looks pretty spec-complete [0] and more than enough to be useful.
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.
2) Why would open federation reject you? Given you don't throw away your private key
JadedBlueEyes 4 hours ago [-]
1) That hasn't been a problem for at least half a decade.
2) What do you even mean? I've literally deleted my entire database and then spun up a new server on the same domain before, it does not matter, other servers do not care! The worst that could happen is messages from the original server can no longer be verified as valid - and even that isn't a problem in practice.
tcfhgj 10 hours ago [-]
Define what you think are more than the basics?
muvlon 13 hours ago [-]
At 11 years old, XMPP had 0 usable clients (I was there and tried them). That's one less than Matrix.
inputmice 12 hours ago [-]
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.
singpolyma3 6 hours ago [-]
Everyone says this and so I believe them, but I used xmpp as my primary communication tool through the whole thing and it worked ok on my first android phone (HTC magic) and amazingly on my n900 followed by acceptably on my BB10 device and never had any issues
zaik 21 hours ago [-]
> 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.
opan 15 hours ago [-]
IRC and email worked out pretty well I think.
singpolyma3 6 hours ago [-]
Yes if you never add new features eventually everyone crystallizes
tcfhgj 9 hours ago [-]
e-mail stuck in time still not enceypting by defaul
"Oh, I'm sorry, did you want it to work? You should have installed the 'it actually works' modules."
Working with XMPP gave me a whole new appreciation for why people keep inventing their own chat protocols. I don't think this is an unsalvageable situation, but the protocol is desperately in need of an "XMPP: the Good Parts" doc.
It was so cool when facebook, google and others used to use xmpp, at that time I used a single IM client https://adium.im
zerozerotwo 22 hours ago [-]
This used to be one of the biggest Mac open source projects. I remember they demoed project builder (before Xcode) compiling it
eddieroger 4 hours ago [-]
One of my happiest open source memories was creating an Adiumy skin for my college and others actually downloading and using it. The app was huge. Those were the days.
nunez 16 hours ago [-]
Best chat client ever. Man we had it good back then.
exe34 1 days ago [-]
I had amsn when msn and yahoo messenger were the place everybody I knew was at.
d3Xt3r 23 hours ago [-]
I was on Miranda. It was tiny and portable (unlike Trillian) and could connect to pretty much every popular messaging service, including IRC. And in spite of being able to connect to everything, it used far lesser memory than even just a single instance of MSN and Yahoo. It was one of my go-to apps that I'd install on a freshly formatted PC back in the day.
pavo-etc 20 hours ago [-]
I have recently picked up XMPP as my agent communication layer, and its worked great. Each pi agent is given an account and wrapped in an XMPP client[0] that lets it speak to me and other agents when needed.
This has worked well since I can spin up new accounts on demand and I can use existing server software (ejabberd, perfect) and clients (Fluux, great; Conversations, okay). I've had to make a few custom modifications to each client to make agent comms a bit nicer (e.g. exposing status messages more prominently since I use that to expose current agent commands), but the XMPP layer has had pretty much everything I could have wanted.
Controlling a chat service is a bit intoxicating, I'm now using it as my notification service over a bunch of different projects.
I used Google Chat way back, its nice that the tech is still around and great as ever.
This is really neat. I've recently been watching people use custom pi harnesses and thinking of jumping in, but I was dreaming of a way to do essentially what pi-msg does so that I could drive it remotely in a more full-featured way. Thanks for sharing.
pavo-etc 15 hours ago [-]
Thanks! I had the same urge, I didn't want to be responsible for an entire GUI and communication layer but I did want to have a remotely controllable extensible harness, this was the perfect middle ground.
The benefit beyond that was having agents running on my server directly so they can do a lot of sysadmin and monitoring tasks, as well as suggesting config changes through PRs to my nix config.
dhc02 15 hours ago [-]
Letting the agents bang their heads against the wall hunting down a config fix for a random malfunctioning piece of my homelab instead of me is by far my favorite part of the AI present.
tehnoslow 19 hours ago [-]
Cool use case with the agents, hadn't thought of that
gatlin 19 hours ago [-]
Amazing! Perhaps my project here would interest you. Also do you have bonjour support?
pi-msg doesn't support bonjour, I'm running it on a nixos server (nix is the real secret ingredient of my whole setup) the xmpp server is the same machine as the agents. I'm almost always on a different network to the one where the server is. If the server goes down the agents and ejabberd are coming down simultaneously.
abound 23 hours ago [-]
I recently migrated from Google Voice to jmp.chat, which is a telephony/SMS/etc bridge to XMPP. I use Dino on my laptop, and Cheogram on my phone, and the experience has been quite nice and seamless. Next step is to host my own Prosody server and import my whole Google Voice history.
dewey 1 days ago [-]
> Matrix reinvented the wheel as a rubber-tyred metro. On paper, it provides real benefits, such as climbing steeper inclines, which are then used to aggressively advertise and lobby local governments to buy in. But in the end, the municipality gets locked into a single vendor.
I stumble upon Matrix from time to time, but Jabber I haven't really seen anywhere in the past decade after my internet friends moved to IRC. Are there any bigger communities still using it? Back in the days Facebook Messenger was backed by it, so maybe there's still some bigger entity using it as a backbone for something?
inputmice 1 days ago [-]
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/channels/1
AlecSchueler 11 hours ago [-]
> NATO, police forces and intelligence agencies use it
Is there anywhere to read more about this?
liotier 10 hours ago [-]
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"
dewey 6 hours ago [-]
Thanks! That was exactly the kind of "hidden usage" I was interested in as it seems to not be publicly used by a lot of people these days (As you can see by the user numbers on https://search.jabber.network/channels/1).
It seems their "JChat" application is based on XMPP.
Semaphor 1 days ago [-]
Yeah, I use it as a messenger for my wife and I.
svyatoslavpavl 1 days ago [-]
Jitsi Meet still runs on XMPP, Prosody handles the signaling. WhatsApp also started life as a patched ejabberd.
iamcalledrob 1 days ago [-]
WhatsApp is still based on XMPP unless things have changed a lot recently.
svyatoslavpavl 4 hours ago [-]
The protocol is still their stripped down XMPP dialect, yeah. I meant the server side: they rewrote most of the original ejabberd over the years, but it stayed Erlang.
The open protocol variant of that is called OMEMO. Same double ratchet and implemented using Signal's library (the same as used by WhatsApp) in many XMPP clients
tcfhgj 5 hours ago [-]
> the same as used by WhatsApp
source? wouldn't that be a license violation?
alex1138 22 hours ago [-]
I don't consider WA a product. I don't consider it a viable product. Post-2014/Zuckerberg. Who cares if it's XMPP, it didn't federate
19 hours ago [-]
opan 14 hours ago [-]
XMPP is somewhat popular on the fediverse, especially the Pleroma side. If you meet people there who want to chat elsewhere, they likely are on XMPP. Also if you have a Disroot account it comes with XMPP.
1970-01-01 1 days ago [-]
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!
thiht 10 hours ago [-]
> 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
singpolyma3 6 hours ago [-]
That sounds like a problem with some assholes, not a problem with your software. I'm sorry assholes happened to you
opan 14 hours ago [-]
I regularly use IRC, XMPP, and Matrix. I think your description fits IRC better. XMPP kinda has a Plan 9 or Amiga type of vibe, cult following "ahead of its time", but never took off totally how people hoped, or didn't stay relevant at least.
justsomehnguy 16 hours ago [-]
> XMPP is the pinnacle of chat that just works.
Except no.
You can't even have a conversation between Conversations and Fluux because OMEMO is enabled by default in Conversations and there is just no OMEMO support in Fluux - despite it being actually modern one.
Gajim works but Pidgin doesn't even show "I sent you an OMEMO encrypted message but your client doesn’t seem to support that". Just like images, which is a first party in Telegram and even WhatsApp.
So much for 'just works'.
F3nd0 15 hours ago [-]
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).
goffi 11 hours ago [-]
Libervia (on which I'm working) does support OMEMO:2 (it was actually the first client to implement it) + legacy one + OX (OpenPGP) + OX for Pubsub (so you can encrypt everything pubsub related: blog, forums, tickets, etc). ()
Anyway, there is a discovery mechanism, and clients do adapt the version used by peers, so there is no incompatibility. Kaidan choose for a while to have only OMEMO:2, because resources are limited and they were going for the latest version first, but resource are limited for everybody, and it took times for others to implement OMEMO:2 too.
NLnet/NGI did (and still does) gave financial support on several XMPP projects (including mine, huge thanks to them), and, curiously, when there is money to help, implementations happen. That's problem nb 1 with XMPP: lack of financial resource.
(
) GUI (notably web UI) is being reworked, not stable yet, but the CLI is pretty solid.
jcbrand 13 hours ago [-]
FWIW Converse.js and Dino also support the latest OMEMO.
F3nd0 13 hours ago [-]
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?
jcbrand 12 hours ago [-]
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.
singpolyma3 6 hours ago [-]
Fluux is brand new and 100% vibecoded, so not surprising if it has some rough edges.
grumbel 24 hours ago [-]
> XMPP is the pinnacle of chat that just works.
Not my experience. I had to give up on it since it was just completely flooded with spam, and unlike mail readers that have ways to mitigate it, XMPP clients were ill prepared. Might still work if you keep your address hidden, but as chat-like alternative to a public email it just stopped working years ago.
fluoridation 24 hours ago [-]
What do you mean? You have to accept a friend request before someone can message you. It's more spam-resistant than email, not less. That said, I don't know if there's anything that prevents spamming friend requests.
grumbel 24 hours ago [-]
And how am I going to find the valid friend requests under the hundreds of spam ones? I used it just like a chat version of public email, for bug reports and such, so I don't know who is going to message me beforehand.
ezst 21 hours ago [-]
You can mediate friends requests by having servers generate an invite link, you can generate QR codes your friend can scan on a side channel, ... There are ways
justsomehnguy 16 hours ago [-]
Or you can just show the welcome message from a new contact, just like anyone else does. Adding a 2nd factor here is the reason XMPP suck.
fluoridation 23 hours ago [-]
Fair enough. I've only ever used XMPP when Google chat used it and at work in the days before Slack.
daneel_w 23 hours ago [-]
I think that's a symptom of the provider you chose, not the XMPP sphere itself. I've used Jabber/XMPP for just over 15 years and while I've seen plenty of bullshit going on in various highly popular MUCs (join-floods, phishing attempts and such) I've never personally been subjected to spam directed at me.
tcfhgj 23 hours ago [-]
I have joined XMPP rooms via Matrix and have already gotten spam from XMPP this way
zaik 21 hours ago [-]
Which is surprising since XMPP allows you to hide your global address in public rooms and Matrix doesn't (unless they fixed it by now?).
troupo 21 hours ago [-]
> XMPP is the pinnacle of chat that just works.
No. It doesn't "just work". It very much depends on which subset of the XEPs all the parties in the chain support.
> All other popular systems and servers went defunct;
Well, in this sense it does just work :)
upofadown 16 hours ago [-]
You can always send and receive messages no matter what XEPs are supported. Not that that is a problem in practice. There is a fairly well established subset of XEPs that everyone supports.
Unless you want to encrypt said messages. But I guess insecure communication beats no communication at all. (I also never had much luck with voice and video calls using XMPP.)
grugdev42 8 hours ago [-]
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:
tox is this same, but you dont need install any program. just start
krisgenre 12 hours ago [-]
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.
I am the designer of Coccinella logo, if anybody remembers... Developer sadly died, but project was so ahead of its time I can believe sell point today is still an online shared canvas...
grumbel 12 hours ago [-]
Looking at my complete grey friends list in Pidgin, with not a single user left active, it looks like everybody left around 8-12 years ago. Many of the old servers are offline as well.
delduca 1 days ago [-]
I think Android still uses XMPP to delivery push notifications under the hood
inputmice 1 days ago [-]
Indeed. And on a Google-free Android phone the XMPP client Conversations can utilize its existing, permanent XMPP connection to deliver push notifications to other (mostly open-source) apps using an alternative to Google push (FCM) called UnifiedPush.
Unless I'm mistaken, Apple's push notifications network ("APN") and a few other macOS/iOS under-the-hood things are also built on top of XMPP.
tolerance 24 hours ago [-]
I had a good technical experience using XMPP once but the community I found using it was an obscure one and I haven't come across another instance of others using it since. No matter how useful a tool is the main hurdle is adoption. This sort of retrospective is useful from an advocacy point of view.
n3storm 5 hours ago [-]
These Christmas I am asking for a one binary rust XMPP server and I'll be back.
Dormeno 11 hours ago [-]
Why is every XMPP client a worse experience than Telegram? I don't get it.
edhelas 10 hours ago [-]
Define worse
Dormeno 9 hours ago [-]
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.
writtenone 2 hours ago [-]
Look into SimpleX Chat. It's like Telegram but with trustworthy encryption that's always-on, multiple profiles, and the servers are interchangeable so if one or two go down you can just switch them out.
Evgeny is a venture capitalist (ew) but the product is solid and they've published two TrailOfBits audits with a third completed and awaiting publication by TOB
_carbyau_ 18 hours ago [-]
When I ever have time...
1. Gain/find-someone-with crypto library use knowledge.
2. Jabber client with Iroh networking and E2EE.
3. Completely remove XMPP server dependence.
4. Allow users to exchange Iroh-Node-ID outside of jabber (QR code, other secure channels?), store in Jabber contacts.
5. Develop from there. Calendar usage, multiparty, backups.
But I have neither the time nor the knowhow right now.
basilgohar 1 days ago [-]
I loved using XMPP and used to run my own server and even had the apps that would send notifications from my phone for different events over XMPP (forgot the name at the moment).
I'm all-in on Matrix right now and use it for my family but it's a far cry from the usability that XMPP had. I am still hopeful that Matrix can live up to its promises but perhaps XMPP will always be around if that doesn't work out. Who knows!
wycx 20 hours ago [-]
MAXS? As far as I can tell, it is broken by newer versions of Android.
Daunk 21 hours ago [-]
XMPP always seemed great, buy I have yet to find a client that can replace Telegram's client on both desktop and mobile.
bobanrocky 15 hours ago [-]
We use xmpp for our company’s IOT product suite. Works quite well with its presence and messaging capabilities ..
Backend runs ejabberd.
kogasa240p 1 days ago [-]
Its biggest issue is adoption because it's very solid otherwise and even supports stuff like screen sharing.
goffi 11 hours ago [-]
I'm also working on experimental XMPP based remote desktop control for what it worth.
tcfhgj 23 hours ago [-]
screensharing is ubiquitous at this point
telesilla 1 days ago [-]
Google & XMPP standards foundation develop the very useful Jingle XEP, so XMPP is linked to the history of Google Voice and whatever Google Talk/Chat turned into, maybe somehow inspiring Google Meet? Jingle was also inspirational to WebRTC signalling.
dpc_01234 19 hours ago [-]
Any Android XMPP client recommendations? I tried one, then it's fork Monocle, and none of the seem to be able to handle simple notifications correctly.
Semaphor 16 hours ago [-]
Never had notifications issues with conversations.
opan 14 hours ago [-]
Seconding Conversations, though I wish it'd let me disable relative timestamps.
lnz_me 1 days ago [-]
i set up a xmpp server a few weeks ago for agent orchestration and agent to human workflows. hadn't inatalled ejabberd in a very long time but feeling right at home.
ee334y5rthsrth 8 hours ago [-]
show me one agent who use jabber for communications with user
writtenone 1 days ago [-]
Are there any XMPP clients with the UX and privacy of Signal?
All of them seem to look like they're from the 00s!
Thanks! Any good Android clients? "Conversations" seems to be the best and it's nowhere near the polish of Signal & Co. crashes often, UX is clunky, family will never stick with it.
4chandaily 1 days ago [-]
As a counterpoint, I use conversations literally every day, and cannot recall the last time it crashed. My partner and kids have used it for at least the last 7 or 8 years to communicate with me and each other. I don't claim there are no issues, but "crashes often" isn't something I would expect to hear about it.
I don't find the UX to be clunky either, but I acknowledge that could just be my familiarity with the program, so I would leave that for others to dispute.
fishgoesblub 1 days ago [-]
What makes you think that? I haven't experienced, or heard of people having frequent crashes. Me and my family also use it to communicate to each other with no issues regarding the UI.
arendtio 23 hours ago [-]
Crashes?!? I've been using Conversations for a long time and can't remember any crashes. Something must be wrong with your setup.
For me, the bigger problem is that I was unable to get OMEMO + Apple Clients working properly. I think OMEMO 1 has some design flaws and hope that OMEMO 2 will fix those.
pavo-etc 20 hours ago [-]
I ran into this exact problem. I needed to fork Conversations to add a lot of polish. My fork is definitely improved but still has a few rough edges I'm chipping away at.
F3nd0 15 hours ago [-]
Do you plan on contributing your improvements upstream, or is that not feasible for some reason?
unethical_ban 22 hours ago [-]
I think of Matrix as a protocol + client/server suite; an open standard with official software backing it and a number of parallel implementations. When I wanted to stand up an independent server that could do most of what Discord does for communities, Matrix was the easy find. Encrypted chat, e2e support, and encrypted voice and video chat rooms with screen share.
I admit I didn't research "XMPP-based discord alternative" but maybe that says something about the ecosystem's health.
zeafoamrun 1 days ago [-]
And I haven't used XMPP for about 20 of them (sadly)
giancarlostoro 1 days ago [-]
There was a time where both Google Chat (whatever it was called back then I lost track) and Facebook Chat were built on it. So you might have.
zeafoamrun 1 days ago [-]
You're right. I know at least one company used XMPP for things like customer support chat too. So maybe I have. I just mean the last time I used it intentionally was a long time ago before I was worn down futilely trying to convince friends to use it instead of locked down chat apps.
giancarlostoro 23 hours ago [-]
That's fair, no worries.
seba_dos1 1 days ago [-]
Google Talk - and it was an actual federating XMPP server, in contrast to Facebook which merely allowed you to login with an XMPP client.
giancarlostoro 23 hours ago [-]
There was a point where Google and Facebook supported external clients, and then within the same year both Google and Facebook closed up to any external clients, then ultimately ditching XMPP.
esafak 21 hours ago [-]
25 years of independence and, dare I say, irrelevance.
colechristensen 21 hours ago [-]
My first task at my first real tech job was setting up an ejabberd server
Flowdalic 1 days ago [-]
[flagged]
bborud 1 days ago [-]
If only they had avoided XML. XML drove away a lot of people who would otherwise have been interested early on.
(I once found myself in the same meeting as two of the people who made the mistakes that meant you couldn’t just pipe stuff through an XML parser and hope it worked. I tend to speak my mind)
[0]: https://movim.eu/
[1]: https://github.com/processone/fluux-messenger
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.
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, Movim, …
I personally use Conversations on the go and Gajim otherwise. I also happen to have interfaced all my "high-volume/many-participants" IRC chans from back in the days with the biboumi² gateway, so they appear to my XMPP clients as native XMPP groupchats, and the experience was great-enough for me to ultimately drop weechat a decade or so ago and have all my "banquet"-style chans under one XMPP roof.
> 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.
From over a decade of using XMPP daily, this concern is more of philosophical nature than anything. The vast majority of the people you'll reach over XMPP use a decently modern and maintained client that will "just work". Worst case, they will still be getting your messages and the meaning across, because the "message passing" core of XMPP was defined 25-odds years ago and hasn't changed.
The real "risk" for XMPP would be to have a large number of users stuck on an unmaintained client, and users staying behind for years while the ecosystem moves on. We had a bit of that with pidgin 8-or-so years ago. The worse that happens is that you can't use the latest E2EE scheme with them, or that attachments are slower to arrive, this sort of things. That's IMO not bad for a 25 years old protocol that's truly decentralized.
¹: https://blogs.gnome.org/tbernard/2018/05/16/banquets-and-bar...
²: https://codeberg.org/poezio/biboumi/
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
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.
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.
8 years ago? Pidgin still doesn't do MAM today.
https://pidgin.im/post/
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. Stuff like reactions "work", notifications is a solved problem.
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.
For the HN crowd... I would say that there's still fun jank, but who doesn't like jankiness in their programs for fun? People should swarm to this opportunity to have some fun with busted tooling again!
[0] https://wiki.alopex.li/ADiveIntoOpenChat
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.
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.
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.
I suppose here you're saying "I should be able to do this without providers having to do work"? Like you show up with lxgr@foo.com to bar.com and create an account, and everything kinda fits into place (modulo you having to set up some DNS?)
It is already possible of course to have XMPP server at domain A handle things for domain B as well. But it is cool how ATProto seems to really bake in the concept of "all domains are welcome".
I might lose my chat history and maybe my contact list if I don't have a local backup of it, but people would still be able to reach me as lxgr@example.com. Ideally, I'd be able to upload my local, end-to-end encrypted backup to xmpp.bar.com and continue exactly where I left off.
AT proto's main innovation to me is decoupling the concerns of user identifier and data host at the protocol level, in the same way that DNS and my web or mail host are decoupled.
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.
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.
(aside long polling which I cannot comment) why is this a even an issue?
Centralized push services (may it be FCM or unified push) are at this point well established.
As a user using a specific messenger app as a push service doesn't gain me anything, it only makes it more difficult to switch messenger app if i choose to use it and mostly use an additional push service (hurting battery life), because most receive push notifications via Google anyway.
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.
It's sort of the Apache of chat protocols and that's not a compliment.
I run my own server for 2 people. Using Prosody [0] took some config but wasn’t that hard. Easier than installing Arch, harder than installing Windows ;)
Nowadays, there is also Snikket [1] by the Prosody maintainer, which is essentially an opinionated all-in-one configuration setup based on Prosody, barely any config needed.
[0]: https://prosody.im/
[1]: https://snikket.org/
Just like with Apache, all you need is a sane default configuration that covers the most common use cases, and I think modern XMPP servers offer that.
Edit: now I can't stop thinking about correlation vs causation - you being under the boulder bleeding out at the same time XMPP encryption suddenly stops working.
Physical hardware certificate thinggy which got crushed?
Id rather someone be able to reach out to me with a note the chat is insecure, rather than be unreachable at all
not it isn't - still today there's no choice between incompatible room types or incompatible encryption algorithms and whatever else.
> 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".
Comparing XMPP at 11 years old to Matrix today makes it abundantly clear that the main thing Element LLC does is waste European public grant funds
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 :)
[0]: https://forgejo.ellis.link/continuwuation/continuwuity/issue...
- 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...
2) Why would open federation reject you? Given you don't throw away your private key
2) What do you even mean? I've literally deleted my entire database and then spun up a new server on the same domain before, it does not matter, other servers do not care! The worst that could happen is messages from the original server can no longer be verified as valid - and even that isn't a problem in practice.
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.
Working with XMPP gave me a whole new appreciation for why people keep inventing their own chat protocols. I don't think this is an unsalvageable situation, but the protocol is desperately in need of an "XMPP: the Good Parts" doc.
https://xmpp.org/extensions/xep-0479.html
It exists! https://docs.modernxmpp.org/
This has worked well since I can spin up new accounts on demand and I can use existing server software (ejabberd, perfect) and clients (Fluux, great; Conversations, okay). I've had to make a few custom modifications to each client to make agent comms a bit nicer (e.g. exposing status messages more prominently since I use that to expose current agent commands), but the XMPP layer has had pretty much everything I could have wanted.
Controlling a chat service is a bit intoxicating, I'm now using it as my notification service over a bunch of different projects.
I used Google Chat way back, its nice that the tech is still around and great as ever.
[0]: https://github.com/zachpmanson/pi-msg
The benefit beyond that was having agents running on my server directly so they can do a lot of sysadmin and monitoring tasks, as well as suggesting config changes through PRs to my nix config.
https://github.com/gatlin/pii
pi-msg doesn't support bonjour, I'm running it on a nixos server (nix is the real secret ingredient of my whole setup) the xmpp server is the same machine as the agents. I'm almost always on a different network to the one where the server is. If the server goes down the agents and ejabberd are coming down simultaneously.
I stumble upon Matrix from time to time, but Jabber I haven't really seen anywhere in the past decade after my internet friends moved to IRC. Are there any bigger communities still using it? Back in the days Facebook Messenger was backed by it, so maybe there's still some bigger entity using it as a backbone for something?
Is there anywhere to read more about this?
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"
It seems their "JChat" application is based on XMPP.
source? wouldn't that be a license violation?
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
Except no.
You can't even have a conversation between Conversations and Fluux because OMEMO is enabled by default in Conversations and there is just no OMEMO support in Fluux - despite it being actually modern one.
Gajim works but Pidgin doesn't even show "I sent you an OMEMO encrypted message but your client doesn’t seem to support that". Just like images, which is a first party in Telegram and even WhatsApp.
So much for 'just works'.
Anyway, there is a discovery mechanism, and clients do adapt the version used by peers, so there is no incompatibility. Kaidan choose for a while to have only OMEMO:2, because resources are limited and they were going for the latest version first, but resource are limited for everybody, and it took times for others to implement OMEMO:2 too.
NLnet/NGI did (and still does) gave financial support on several XMPP projects (including mine, huge thanks to them), and, curiously, when there is money to help, implementations happen. That's problem nb 1 with XMPP: lack of financial resource.
(
) GUI (notably web UI) is being reworked, not stable yet, but the CLI is pretty solid.I worked on adding OMEMO2 support to Converse.js via libomemo.js and I tested it against Kaidan.
Not my experience. I had to give up on it since it was just completely flooded with spam, and unlike mail readers that have ways to mitigate it, XMPP clients were ill prepared. Might still work if you keep your address hidden, but as chat-like alternative to a public email it just stopped working years ago.
No. It doesn't "just work". It very much depends on which subset of the XEPs all the parties in the chain support.
> All other popular systems and servers went defunct;
Well, in this sense it does just work :)
https://xmpp.org/extensions/xep-0479.html
https://compliance.conversations.im/
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
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/
There was a talk at FOSDEM about that.
https://gultsch.video/w/gRGZqKKvNBvvMesyWNQzoK
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.
Evgeny is a venture capitalist (ew) but the product is solid and they've published two TrailOfBits audits with a third completed and awaiting publication by TOB
1. Gain/find-someone-with crypto library use knowledge.
2. Jabber client with Iroh networking and E2EE.
3. Completely remove XMPP server dependence.
4. Allow users to exchange Iroh-Node-ID outside of jabber (QR code, other secure channels?), store in Jabber contacts.
5. Develop from there. Calendar usage, multiparty, backups.
But I have neither the time nor the knowhow right now.
I'm all-in on Matrix right now and use it for my family but it's a far cry from the usability that XMPP had. I am still hopeful that Matrix can live up to its promises but perhaps XMPP will always be around if that doesn't work out. Who knows!
All of them seem to look like they're from the 00s!
I don't find the UX to be clunky either, but I acknowledge that could just be my familiarity with the program, so I would leave that for others to dispute.
For me, the bigger problem is that I was unable to get OMEMO + Apple Clients working properly. I think OMEMO 1 has some design flaws and hope that OMEMO 2 will fix those.
I admit I didn't research "XMPP-based discord alternative" but maybe that says something about the ecosystem's health.
(I once found myself in the same meeting as two of the people who made the mistakes that meant you couldn’t just pipe stuff through an XML parser and hope it worked. I tend to speak my mind)