3 ms·
> 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 e
by 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.
- ezst 2mo 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.