Revision 1 as of 2017-157 21:37:53
Start documenting the complexities of group texting
Historical Cheogram + MRMMS
|Deletions are marked like this.||Additions are marked like this.|
|Line 25:||Line 25:|
|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.
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.
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.
To support multiple groupchats containing the same SMS user this requires one phone number per chat.
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.
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).
More complex mappings to MUC or chats containing a mix of XMPP, SMS, and multi-recipient MMS users should be delegated to Cheogram.