Difference between revisions of "Easy Group Chats"

From XMPP WIKI
Jump to navigation Jump to search
(Restored from backup)
 
m
 
(2 intermediate revisions by 2 users not shown)
Line 1: Line 1:
The 'classic' [https://xmpp.org/extensions/xep-0045.html Multi-User Chat] interface is strongly influenced by IRC (public chat room, semi-anonymous participants, dedicated owner/admins/moderators, explicit joining/leaving). This is not suitable for modern mobile messengers, where users rather want to have a "seamless" group for their family, one for their accordion youth club, etc.
The 'classic' [https://xmpp.org/extensions/xep-0045.html Multi-User Chat (XEP-0045)] interface is strongly influenced by IRC (public chat room, semi-anonymous participants, dedicated owner/admins/moderators, explicit joining/leaving). This is not suitable for modern mobile messengers, where users rather want to have a "seamless" group for their family, one for their accordion youth club, etc.


As part of the [[Easy XMPP]] initiative, we need to specify a "group chat" approach based on MUC (and possibly also applicable to MIX) that works between different clients.
As part of the [[Easy XMPP]] initiative, we need to specify a "group chat" approach based on MUC (and possibly also applicable to MIX) that works between different clients.
Line 51: Line 51:


* Do not expose the UUID to the user
* Do not expose the UUID to the user
* Show the room name from user’s bookmark first, if set ("Friendly Name")
* Show the room name from disco#info if set ("Family Christmas Plans")
* Show the room name from disco#info if set ("Family Christmas Plans")
* Show the list of participants as fallback ("Alice, Fred", exclude yourself)
* Show the list of participants as fallback ("Alice, Fred", exclude yourself)

Latest revision as of 00:15, 28 May 2020

The 'classic' Multi-User Chat (XEP-0045) interface is strongly influenced by IRC (public chat room, semi-anonymous participants, dedicated owner/admins/moderators, explicit joining/leaving). This is not suitable for modern mobile messengers, where users rather want to have a "seamless" group for their family, one for their accordion youth club, etc.

As part of the Easy XMPP initiative, we need to specify a "group chat" approach based on MUC (and possibly also applicable to MIX) that works between different clients.

Requirements are:

  • Single-click room creation with sane defaults
  • Automatic or one-click joining for invited contacts
  • Seamless upgrade from 1:1 chat to MUC (user invites another contact to an ongoing 1:1 conversation)

Nice to have features are:

  • Customizing of the room (name / description, logo / background image)
  • transmission of 1:1 chat history into MUC history

Prior Work

  • The MUC specification defines instant rooms, which are just a shortcut to accept the default MUC settings, which are not defined in the XEP :-(
  • Conversations auto-joins a MUC if it receives a mediated invitation.
  • ChatSecure will auto-join if the inviter is on the user's roster.

Swift Implementation Notes

In Swift, ad-hoc group chats are called 'impromptu', and they are implemented as follows:

  • UI is different from MUCs
    • Instead of the room name, the list of participants is shown
    • Presence changes are shown differently. Approximately "$user joined the conversation/chat" vs. "$user has entered the room as a moderator."
  • Inviter creates a UUID-named MUC on the local MUC component (a requirement for the feature)
  • Invitee auto-joins if it receives such an element
    • Impromptu MUCs are not saved in bookmarks
    • A local flag is maintained indicating them as 'impromptu' to trigger the special UI

Conversations Implementation Notes

Conversations generally has two different dialogs Join conference and Create conference. The first lets the user enter a JID (full jids are also possible) and behaves like every other XMPP client. Create conference let's the user specify a name (optional) which will later be set as a subject and choose participants.

  • Conversations creates random string (base36) for localpart and picks a MUC component from the users server.
  • Room is created a private and non-anonymous.
  • Generally for all conferences if there is no subject it creates a name from the participants ("Bob, Alice, Peter")
  • For non-anonymous and private mucs Conversations queries the member list (admin list, owner list) and also shows members that are offline (and uses this for the name creation)
  • Since ad-hoc groups are private and members only Conversations show the 'proper' title even if other participants didn't follow the invite yet.
  • Conversations generally follows all invites automatically (Might be revised to only follow invites from contacts)

Desired UX

Room Naming

The group chat needs to be properly identified in the roster list / rooms list.

  • Do not expose the UUID to the user
  • Show the room name from user’s bookmark first, if set ("Friendly Name")
  • Show the room name from disco#info if set ("Family Christmas Plans")
  • Show the list of participants as fallback ("Alice, Fred", exclude yourself)