3 ms·

> 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

by ezst 1mo 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 1mo 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 1mo 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.
tcfhgj 1mo ago
> 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
account42 1mo 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 1mo 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! https://pidgin.im/post/ https://pidgin.im/post/
  - rw_grim 1mo ago
    We've retired the blog in favor of just posting on our discourse as noted in our last blog post ;)
- rw_grim 1mo ago
  Yep, it's hard to run a volunteer project when there's so much work to do...

by ezst 1mo ago

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

tcfhgj 1mo ago

> 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

account42 1mo 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 1mo 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! https://pidgin.im/post/ https://pidgin.im/post/
- rw_grim 1mo ago
  We've retired the blog in favor of just posting on our discourse as noted in our last blog post ;)
rw_grim 1mo ago
Yep, it's hard to run a volunteer project when there's so much work to do...