[Summit] Notes on XMPP Summit Day agreements on the MIX spec

Steve Kille steve.kille at isode.com
Fri Jan 29 11:17:21 UTC 2016


All,

This message is my summary of the key points we agreed today.     


The goal is to share what we discussed, both for those who participated yesterday and for the people not at the summit. If anyone
has any corrections or clarifications, please share them.   


Decisions, in approximate meeting order.


1.  MIX will reference  Pubsub Account Management (PAM) XEP.     Reference.   MIX will work better with PAM, but support of PAM is
not mandatory for MIX.   While PAM is not strictly necessary, it will lead to a better user experience

2.  No MIX changes or capabilities needed to deal with  "flapping presence".     XEP-0198 is the way to deal with this issue.


3.   When a server supports both MIX and MUC, the server may choose to have MIX users and MUC users on the same domain or on
different domains.    The spec will allow both approaches.  There are conflicts that will make it hard to do both at once, but
servers are free to do it if they want.


4.  Presence information sent from client to room will use presence stanzas and not XEP-0060.  This enables MIX room
to be added to the roster.


5.  Presence information sent from room to client will use presence stanzas and not XEP-0060.  This enables MIX room
to be added to the roster.

6.   Presence information read from the presence node will come back as presence stanzas.

7.   A MIX server MAY allow clients to subscribe to a presence node using XEP-0060.   If this is supported, presence will be
returned in XEP-0060 format.

8.   MIX chat messages will use groupchat message format and not XEP-0060 wrapping.


9.  Points 4-8 resolve the issues that were left up for debate in the XEP after the US Summit that were marked as needing list
discussion.   

10.   The semi-anonymous model is definitely required.   As a consequence of this, proxy jids are required.


11.    Proxy jids will be "per room".   The option to have proxy jids "per service" was discussed and it was agreed that this should
not be done.  One reason for this choice was privacy issues.


12.    Bare p roxy jids will have the syntax  "<room>+<generated identifier>@<mix domain>"


13.   Resources in proxy jids will be unpredicatable, mapping 1:1 with the actual jids.     There needs to be a security
consideration, noting that this avoids information leakage.


14.   It will not be prohibited in the XEP to change between a room being non-anonymous and semi-anonymous.    Note security
consideration that when going from non-anon to semi-anon, that some information cannot be hidden retrospectively.


15.   When joining a MIX room, a user can request state to be one of:
     - "anonymous"
    - "explicit non-anonymous"
    - "follow default room policy"

Rooms may enforce default or allow user to change.    On join, this will prevent user from joining if users requires anonymity and
room does not.   User preference needs to be noted, so that it can be honoured if room changes state.


16.   Proxy jids will always be used.


17.   There was discussion as to whether a form should be used to hold preferences and associated information on join.   Conclusion
was that a form should not be used in the initial join, and that if the MIX channel requires further information it will send a
form.


18.  Nick reservation across service (MIX domain) will be useful for some services, and it will be an option for MIX implementations
to provide this.   It was noted that some XEP-0045 services provide this.


19.  MIX rooms will be  in user Rosters.    Client can determine if a roster entry is a MIX room by  listing PubSub services using
PAM.


20.  MIX entries in the roster use one way presence.   The room gets presence from the user, but not the other direction.


21.   If user removes the channel's presence subscription from a MIX room,  the server may remove  the user from the room,
although this will not always be desirable/sensible.

22.   When there is an "ad hoc" chat between a group of users, the room for this will be left open.  Retaining the room will give a
reference for history and permits re-use.    A client may choose to re-use this room to continue a chat between the same group of
people.   If the same group of people is built up again, this will generally use a new room, because it may only be the same group
of people temporarily with the intention of imminently adding more.

23.   When a room is created for ad hoc use, the MIX server will pick the name.  The room should not be addressable or discoverable.
There will be a command to explicitly request such a room.


24.   Room Name  (title) can be changed.


25.   Change of room JID is not supported.   Although there are merits to the service, it does not justify the additional complexity
to achieve it.

26.    There will not be temporary rooms that are destroyed when all users are offline in the spec, as there are in XEP-0045.


27.   Servers may delete rooms according to local policy such as when there are no users.   There will often be good reasons to not
delete rooms in this situation.

 
28.  Need an Administrative mechanism to delete a rooms that does not require the administrator to be in the room.

29.  It was explains that invites are "two stage".   Inviter interacts with room to get an "invite token", which the inviters then
sends directly to the invitee.

30.   The term to use for what is "room" in XEP-0045 was considered.  The current draft uses "conversation".  The group
agreed that the only two sensible choices were "room" and "channel" .  The majority of the room preferred "channel" with a minority
preferring "room".   We will go with "channel" unless subsequent input (e.g., list discussion) suggests that "room" is preferred.   

In the talk today, people are using "room" and not channel.  


31.  The XEP-0045 terms "semi-anonymous" and "non anonymous" will be replaced with "jids hidden" and "jids visible".


32.   MAM related issues to be discussed tomorrow


Please let me know if I missed anything from the discussion that we need to record



Steve



- 






More information about the Summit mailing list