Differences between revisions 3 and 4
Revision 3 as of 2020-208 00:56:57
Size: 3501
Editor: Singpolyma
Comment:
Revision 4 as of 2020-247 23:57:48
Size: 6845
Editor: CPEf81d0f884ab3-CMf81d0f884ab0
Comment: Describe current state of thoughts on various MUC options
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
It is desired that soprani.ca should support multi-user chats involving XMPP and SMS users. From a technology standpoint, there are several things possibly involved here:

* XMPP MUC (broad client support): https://xmpp.org/extensions/xep-0045.html
* XMPP extended addressing (limited client support): https://xmpp.org/extensions/xep-0033.html
* Multi-recipient MMS (moderate client support)

== A User Experience ==

XMPP user is in a chat with another user (XMPP or SMS -- they don't know or care which), hits "invite contact" and selects an Cheogram JID, thus generating an XMPP MUC and joining it, and inviting the existing user as well as the new Cheogram JID using https://xmpp.org/extensions/xep-0045.html#registrar-querytypes-invite and/or https://xmpp.org/extensions/xep-0249.html -- all users end up in the chat.

If both users are Cheogram JIDs, the configured route supports multi-recipient MMS, and the users in the chat support multi-recipient MMS, that would be the ideal UX for the "SMS users". If any user does not support MMS or multi-recipient MMS, it would be nice if they could still participate. Being able to have an "SMS user" in the same conversation with several XMPP users would also be expected.

== Receiving Multi-recipient MMS ==

If a multi-recipient MMS includes a user at an SGX that supports this technology, the user should receive the message, and ideally know who else it was sent to and have a way to "reply to all". Given the current UX that exists in different clients, the best experience for the user would probably be to have the XMPP MUC UI be used.

Multi-recipient MMS acts at a protocol-level like email reply-all chains (multiple recipients listed on each message), but the lack of a thread ID means that many clients in practise treat the sum of all recipients as a conversation identifier. This means that if we allow a user to invite someone new to the chat, all multi-recipient MMS users will see this as a new conversation starting with a different group -- it remains to be seen if this is well handled by social convention or is very confusing.
Some [[SGX]] support [[SGX/GroupMMS]] which is implemeted via https://xmpp.org/extensions/xep-0033.html -- no known client has useful UX for this XEP. Most clients have a decent UX for MUC, and it would be nice to exploit that to get good MMS UX as well.
Line 21: Line 5:
Fallback mode that works for an SMS user: send all messages from a particular groupchat through a single phone number and prepend messages with the nickname of the user who sent them. SMS replies to this number will be relayed to the group using the Cheogram JID of the phone number. All Cheogram JIDs already support being present in any MUC. This works by sending all messages from a particular groupchat through a single phone number and prepending messages with the nickname of the user who sent them. SMS replies to this number will be relayed to the group using the Cheogram JID of the phone number.
Line 23: Line 7:
To support multiple groupchats containing the same SMS user this requires one phone number per chat. To support multiple groupchats containing the same Cheogram JID would require one phone number per chat (possibly via MUX), and is currently not supported.
Line 25: Line 9:
This could be mixed with multi-recipient MMS to include SMS users who do not support that feature: the recipient list would include all multi-recipient MMS supporters and a "special" Cheogram number for the groupchat that would receive messages and relay them to SMS users, replies from SMS users would be relayed to the MMS group with nickname prefixes in the content. Not curerntly supported: this could be mixed with multi-recipient MMS to include SMS users who do not support that feature: the recipient list would include all multi-recipient MMS supporters and a "special" Cheogram number for the groupchat that would receive messages and relay them to SMS users, replies from SMS users would be relayed to the MMS group with nickname prefixes in the content.
Line 27: Line 11:
== Technical implementation == == MUC to XEP0033 Bridge ==
Line 29: Line 13:
Multi-recipient MMS has an obvious and simple mapping to XEP0033. As usual, to simplify SGX and share more complex logic between possible providers an SGX that supports multi-recipient MMS should implement XEP0033 (with the raw host of the component acting as the multicast service, accepting JIDs at its own host and possible `tel:` URIs as possible recipients and rejecting any others, see [[SGX/GroupMMS]]). While a bridge built into Cheogram has been contemplated, right now Cheogram is already several layers of undesigned and hastily-written legacy screaming to be rewritten, and in may not bear the load of yet another mode layered on without some amount of design being applied. Also until a rewrite or at least a massive documentation effort it is quite difficult for developers other than Singpolyma to add significant new features.
Line 31: Line 15:
More complex mappings to MUC or chats containing a mix of XMPP, SMS, and multi-recipient MMS users should be delegated to Cheogram. Besides this, other soprani.ca components, such as Cheogram SMTP, may benefit from this kind of bridge. So experimenting with doing it outside of Cheogram is probably worth something in any case.

=== Option 1: Full Control ===

The easiest option to implement is one where we do not allow mixing XEP0033 supporting JIDs with other MUC participants. That is, we would not support "in the wild" MUCs via this bridge at all, but instead the bridge must be an XMPP component that implements a MUC server/component.

Each MUC on the bridge has a single owner JID which originally created it, and they all act as "private groups": only JIDs invited by the owner are allowed to join. When an owner tries to add a JID (either by adding them as a member, or by mediated invitation) the domain of the JID is scanned for XEP0033 support and an error is returned if it is not found (this is to reduce the change of accidentally inviting a JID that has no support which would be very confused otherwise -- it is not required technically but I think it would be a UX improvement).

Mediated invitations should *not* be relayed to their target JIDs, nor should invitations or groupchat type messages or any other MUC detail be leaked to *any* JID except the owner.

Any type=groupchat message the owner sends to the MUC is relayed to the domain(s) of the participants with XEP0033 metadata indicating the full JIDs of all other recipients as "to" and the owner as "ofrom". The "from" should be the room JID itself. Any other stanza from the owner to the MUC is *not* relayed, but is instead either handled for MUC setup purposes (adding members, etc) or else usually ignored, or in the case of iq return a not supported error.

Any message received by the MUC JID from a participating JID *must* have XEP0033 metadata on it. Any stanza from a JID not in the members must be rejected with item-no-found. Any stanza from a mmeber other than the owner without XEP0033 metadata must be rejected. All XEP0033 to and cc items *must* be marked as "delivered" except for the owner's JID, otherwise an error must be returned.

An XEP0033 message recevied from a member of the room and with the owner listed as not "delivered" will be relayed to the owner as a groupchat message from MUCJID/SENDERJID, that is just like any MUC message from the nick equal to the sender's JID. XEP0033 ofrom must be added so that the client can know the "true" JID of the sender and thus show avatar/roster nick information (since that's basically the point of all this).

UX NOTE: Cheogram will reject KEP0033 messages that have targets other than ones at cheogram.com, so the user may end up creating a room where all messages sent to cheogram return errors.

UX NOTE: Under this system a user who wants to start a new MMS group must first join an {{{arbitrarily-named-room@bridge.component.tld}}} and then invite their cheogram JID contacts *to that room* -- attempts to invite cheogram JIDs to any other MUC (including temporary ones created by using UIs to add a user to an existing 1:1 conversation) will result in Historical Cheogram usage by accident.

=== Option 2: Open World ===

This version is more complex, harder to do outside of Cheogram, and may result in different unexpected results. Nevertheless, it is also more powerful and generic, and so I will describe it here.

This is basically an upgrade for Historical Cheogram where any Cheogram JID that is in a MUC (where these are normal "in the wild" MUCs) will receive a Group MMS for any groupchat message received from a MUC they are in. The Group MMS would come from the phone number of the ofrom sender (though that won't work in public, cloaked MUC...) if they have one. If the ofrom sender is a different Cheogram JID we assume they sent it as Group MMS and this recipient has already got a copy. If the ofrom sender has no associated 1:1 route, or if their route does not support Group MMS, or if their JID is not known, then we send from The Cheogram Phone Number and prement nickname as per Historical. If the reicipient is the only cheogram JID in the MUC, or if there are non-cheogram-using JIDs in the MUC then The Cheogram Phone Number is added as a recipient also, to force Group MMS + to show that there are "other participants" not shown on the MMS side.

In the simple case where the criteria for option 1 are met, this will result in identical UX on the MMS side and nicer UX on the XMPP side (any MUC full of cheogram JIDs may be used). Inviting a non-cheogram JID will result in Historical-style messages in the group, but won't break entirely, and if the group is primarily Cheogram JIDs everything will still run smoothly. If a Cheogram using JID (with a 1:1 route set) is added to the MUC, their phone number will be added on the Group MMS side seamlessly. Only in the case of a MUC with many non-cheogram JIDs who are also not Cheogram users will something like the Historical Cheogram really show up with basically the historical UX.

I have not given too much thought to how much of this could be acheived by a seperate component outside of Cheogram, so if this option is desired more thought may be needed.

Some SGX support SGX/GroupMMS which is implemeted via https://xmpp.org/extensions/xep-0033.html -- no known client has useful UX for this XEP. Most clients have a decent UX for MUC, and it would be nice to exploit that to get good MMS UX as well.

Historical Cheogram

All Cheogram JIDs already support being present in any MUC. This works by sending all messages from a particular groupchat through a single phone number and prepending messages with the nickname of the user who sent them. SMS replies to this number will be relayed to the group using the Cheogram JID of the phone number.

To support multiple groupchats containing the same Cheogram JID would require one phone number per chat (possibly via MUX), and is currently not supported.

Not curerntly supported: this could be mixed with multi-recipient MMS to include SMS users who do not support that feature: the recipient list would include all multi-recipient MMS supporters and a "special" Cheogram number for the groupchat that would receive messages and relay them to SMS users, replies from SMS users would be relayed to the MMS group with nickname prefixes in the content.

MUC to XEP0033 Bridge

While a bridge built into Cheogram has been contemplated, right now Cheogram is already several layers of undesigned and hastily-written legacy screaming to be rewritten, and in may not bear the load of yet another mode layered on without some amount of design being applied. Also until a rewrite or at least a massive documentation effort it is quite difficult for developers other than Singpolyma to add significant new features.

Besides this, other soprani.ca components, such as Cheogram SMTP, may benefit from this kind of bridge. So experimenting with doing it outside of Cheogram is probably worth something in any case.

Option 1: Full Control

The easiest option to implement is one where we do not allow mixing XEP0033 supporting JIDs with other MUC participants. That is, we would not support "in the wild" MUCs via this bridge at all, but instead the bridge must be an XMPP component that implements a MUC server/component.

Each MUC on the bridge has a single owner JID which originally created it, and they all act as "private groups": only JIDs invited by the owner are allowed to join. When an owner tries to add a JID (either by adding them as a member, or by mediated invitation) the domain of the JID is scanned for XEP0033 support and an error is returned if it is not found (this is to reduce the change of accidentally inviting a JID that has no support which would be very confused otherwise -- it is not required technically but I think it would be a UX improvement).

Mediated invitations should *not* be relayed to their target JIDs, nor should invitations or groupchat type messages or any other MUC detail be leaked to *any* JID except the owner.

Any type=groupchat message the owner sends to the MUC is relayed to the domain(s) of the participants with XEP0033 metadata indicating the full JIDs of all other recipients as "to" and the owner as "ofrom". The "from" should be the room JID itself. Any other stanza from the owner to the MUC is *not* relayed, but is instead either handled for MUC setup purposes (adding members, etc) or else usually ignored, or in the case of iq return a not supported error.

Any message received by the MUC JID from a participating JID *must* have XEP0033 metadata on it. Any stanza from a JID not in the members must be rejected with item-no-found. Any stanza from a mmeber other than the owner without XEP0033 metadata must be rejected. All XEP0033 to and cc items *must* be marked as "delivered" except for the owner's JID, otherwise an error must be returned.

An XEP0033 message recevied from a member of the room and with the owner listed as not "delivered" will be relayed to the owner as a groupchat message from MUCJID/SENDERJID, that is just like any MUC message from the nick equal to the sender's JID. XEP0033 ofrom must be added so that the client can know the "true" JID of the sender and thus show avatar/roster nick information (since that's basically the point of all this).

UX NOTE: Cheogram will reject KEP0033 messages that have targets other than ones at cheogram.com, so the user may end up creating a room where all messages sent to cheogram return errors.

UX NOTE: Under this system a user who wants to start a new MMS group must first join an arbitrarily-named-room@bridge.component.tld and then invite their cheogram JID contacts *to that room* -- attempts to invite cheogram JIDs to any other MUC (including temporary ones created by using UIs to add a user to an existing 1:1 conversation) will result in Historical Cheogram usage by accident.

Option 2: Open World

This version is more complex, harder to do outside of Cheogram, and may result in different unexpected results. Nevertheless, it is also more powerful and generic, and so I will describe it here.

This is basically an upgrade for Historical Cheogram where any Cheogram JID that is in a MUC (where these are normal "in the wild" MUCs) will receive a Group MMS for any groupchat message received from a MUC they are in. The Group MMS would come from the phone number of the ofrom sender (though that won't work in public, cloaked MUC...) if they have one. If the ofrom sender is a different Cheogram JID we assume they sent it as Group MMS and this recipient has already got a copy. If the ofrom sender has no associated 1:1 route, or if their route does not support Group MMS, or if their JID is not known, then we send from The Cheogram Phone Number and prement nickname as per Historical. If the reicipient is the only cheogram JID in the MUC, or if there are non-cheogram-using JIDs in the MUC then The Cheogram Phone Number is added as a recipient also, to force Group MMS + to show that there are "other participants" not shown on the MMS side.

In the simple case where the criteria for option 1 are met, this will result in identical UX on the MMS side and nicer UX on the XMPP side (any MUC full of cheogram JIDs may be used). Inviting a non-cheogram JID will result in Historical-style messages in the group, but won't break entirely, and if the group is primarily Cheogram JIDs everything will still run smoothly. If a Cheogram using JID (with a 1:1 route set) is added to the MUC, their phone number will be added on the Group MMS side seamlessly. Only in the case of a MUC with many non-cheogram JIDs who are also not Cheogram users will something like the Historical Cheogram really show up with basically the historical UX.

I have not given too much thought to how much of this could be acheived by a seperate component outside of Cheogram, so if this option is desired more thought may be needed.

MUC (last edited 2020-251 00:38:30 by d50-92-76-47)