8 ms·
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
by fishgoesblub 24d 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?
[0]: https://movim.eu/ https://movim.eu/
[1]: https://github.com/processone/fluux-messenger https://github.com/processone/fluux-messenger
- PunchyHamster 23d agoIt 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
- zaik 23d 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 23d agoIRC and email worked out pretty well I think.
- tcfhgj 23d agoe-mail stuck in time still not enceypting by defaul
- singpolyma3 23d agoYes if you never add new features eventually everyone crystallizes
- akho 23d agoMatrix 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 23d agoXMPP 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 23d agoUnfortunately, some of the features that can degrade are things like "the chat is actually secure."
- opan 23d agoI 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.
- oivaksef 23d agoI 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?
- Dormeno 23d agoIt'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.
- vcccgjuf 23d agoMatrix 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 23d agoActually, Matrix has a series of server and client implementations. Servers: https://matrix.org/ecosystem/servers/ https://matrix.org/ecosystem/servers/ Clients: https://matrix.org/ecosystem/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 :)
- opan 23d agoI 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 23d agoProbably, 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 23d agoI 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/issues/880 https://forgejo.ellis.link/continuwuation/continuwuity/issue...
- shadowgovt 23d ago"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.
- ValdikSS 23d agoDaniel (the author of the linked article) was one of the people to define profiles for human chatting: https://xmpp.org/extensions/xep-0479.html https://xmpp.org/extensions/xep-0479.html
- account42 22d agoThat just means the protocol is old enough to have accumulated that much technical debt, which is a sign of resilience.
- shadowgovt 23d agoIt'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 23d 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. [0]: https://prosody.im/ https://prosody.im/ [1]: https://snikket.org/ https://snikket.org/
- rtpg 23d agoto 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.
- tredre3 23d agoCounter 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 23d agoFWIW, 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.
- agile-gift0262 23d agoTry 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
- pkulak 23d agoYeah 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.
- agile-gift0262 23d agoNot sure about iOS, but for Android Conversations is great
- account42 22d agoYes. The only feature I'm missing is to show linked images inline. But that's a matter of taste.
- pixelschubsi 23d agoMatrix 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.
- _flux 23d agoThe 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?
- edhelas 23d agoMovim author there, thanks ! :)
- lxgr 23d agoAs 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.
- rtpg 23d agoI 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! [0] https://wiki.alopex.li/ADiveIntoOpenChat https://wiki.alopex.li/ADiveIntoOpenChat
- lxgr 23d 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.