MillesimusThe #XmppSummit25 is closing in. Reason enough to write a wishlist for the #xmpp ecosystem: https://codeberg.org/millesimus/xmpp-wishlist/src/branch/main/README.md
Update: #XMPPsummit27 is the correct tag. :)
Marvin W@millesimus
- Make groups a client concept
This makes sense for small, private groups, but less so for public channels, simply because it doesn't scale. Also your server will always learn about those groups anyway due to patterns: research has shown it takes 3 to 5 messages in a group for a server to reliably discover group membership for this kind of group (client fanout), even if sealed sender is used.
- Make groups a client concept
This makes sense for small, private groups, but less so for public channels, simply because it doesn't scale. Also your server will always learn about those groups anyway due to patterns: research has shown it takes 3 to 5 messages in a group for a server to reliably discover group membership for this kind of group (client fanout), even if sealed sender is used.
@larma
I agree that this is mainly a thing for private groups. I just didn't write it down.
I do agree w.r.t. to correlations, but 1) it's still better than having the metadata rest on the server, 2) it solves the annoying issue of users on remote servers dropping from the group on a server restart, 3) the correlation could be mitigated by multi-address profiles which are also on my wish list.^^
I agree that this is mainly a thing for private groups. I just didn't write it down.
I do agree w.r.t. to correlations, but 1) it's still better than having the metadata rest on the server, 2) it solves the annoying issue of users on remote servers dropping from the group on a server restart, 3) the correlation could be mitigated by multi-address profiles which are also on my wish list.^^
@millesimus
Concepts for what some also call "multi party direct message" have been around for some time. The problem is the adoption, as it can't be done easily in backwards-compatible fashion when existing clients only have the concept of server-managed group chats and direct 1-1 messages.
Maybe we can find some solution where a MUC is still used, but only for communication with non-supporting clients, so we can start rolling this out backwards-compatible and eventually cut the MUC out.
@larma Maybe clients could implement them and show an "upgrade this group chat to the new version" button to group admins. Or would you prefer backwards-compatibility even for those cases?
@millesimus
Users don't know and shouldn't care which clients other users use or want to use. Such a button thus might accidentally kick users from a group without the user or client knowing, which sounds like a terrible UX. Given that the benefit of this "upgrade" for endusers is really not that big (no new feature, no practical changes at all in the happy case), I doubt a lot of people would ever want to press such button except developers.
Users don't know and shouldn't care which clients other users use or want to use. Such a button thus might accidentally kick users from a group without the user or client knowing, which sounds like a terrible UX. Given that the benefit of this "upgrade" for endusers is really not that big (no new feature, no practical changes at all in the happy case), I doubt a lot of people would ever want to press such button except developers.
@larma Yes, I see. Silent kicks are a hard argument against it. Users wouldn't even have the chance to switch their client to rejoin the group.