Some SGX support SGX/GroupMMS which is implemented 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 currently 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 member 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 received 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 XEP0033 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 recipient 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 achieved by a separate component outside of Cheogram, so if this option is desired more thought may be needed.