6 ms·

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 ne

by lxgr 2mo ago

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.

rtpg 2mo ago
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! [0] https://wiki.alopex.li/ADiveIntoOpenChat https://wiki.alopex.li/ADiveIntoOpenChat
- lxgr 2mo 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 2mo 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 2mo 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.
      - goffi 2mo ago
        Hey. I'm currently working on this: https://xmpp.org/extensions/xep-0516.html https://xmpp.org/extensions/xep-0516.html
        lxgr 2mo ago
        This is awesome, thank you!
      - rtpg 2mo ago
        I mean apart from the uploading of the backup xmpp already lets you do this right? That's my impression at least. Maybe I'm misunderstanding something. (The premise in my understanding is that you own example.com and control its DNS records right? And not "well I hosted on foo.com as name@foo.com but it went down and now I want to move")
- regularfry 2mo ago
  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 2mo 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 2mo ago
      Submit patch?
      - regularfry 2mo ago
        I did this on one project but things moved fast enough (and I've had too much going on) that I couldn't go round the review cycle fast enough and keep it architecturally aligned to get it merged.
- account42 2mo ago
  > Yes if your server goes down then you lose the chat. Don't all actively maintained servers support persistent message archive management now?
ezst 2mo 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. ¹: https://blogs.gnome.org/tbernard/2018/05/16/banquets-and-barbecues/ https://blogs.gnome.org/tbernard/2018/05/16/banquets-and-bar... ²: https://codeberg.org/poezio/biboumi/ https://codeberg.org/poezio/biboumi/
- lxgr 2mo 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.

by lxgr 2mo ago

rtpg 2mo ago

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! [0] https://wiki.alopex.li/ADiveIntoOpenChat https://wiki.alopex.li/ADiveIntoOpenChat

lxgr 2mo 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 2mo 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 2mo 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.
    - goffi 2mo ago
      Hey. I'm currently working on this: https://xmpp.org/extensions/xep-0516.html https://xmpp.org/extensions/xep-0516.html
      - lxgr 2mo ago
        This is awesome, thank you!
    - rtpg 2mo ago
      I mean apart from the uploading of the backup xmpp already lets you do this right? That's my impression at least. Maybe I'm misunderstanding something. (The premise in my understanding is that you own example.com and control its DNS records right? And not "well I hosted on foo.com as name@foo.com but it went down and now I want to move")
regularfry 2mo ago
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 2mo 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 2mo ago
    Submit patch?
    - regularfry 2mo ago
      I did this on one project but things moved fast enough (and I've had too much going on) that I couldn't go round the review cycle fast enough and keep it architecturally aligned to get it merged.
account42 2mo ago
> Yes if your server goes down then you lose the chat. Don't all actively maintained servers support persistent message archive management now?

ezst 2mo 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. ¹: https://blogs.gnome.org/tbernard/2018/05/16/banquets-and-barbecues/ https://blogs.gnome.org/tbernard/2018/05/16/banquets-and-bar... ²: https://codeberg.org/poezio/biboumi/ https://codeberg.org/poezio/biboumi/

lxgr 2mo 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.