[Summit] Notes on day 2 discussions on MIX, MAM, PubSub, Pipelining, and other things

Steve Kille steve.kille at isode.com
Sat Jan 30 12:09:04 UTC 2016


This note is looking to capture my understanding of MIX related decisions and actions from day 2.   The MIX discussion spilled over
into MAM and PubSub and other things.   So this note is looking to capture additional areas where I took notes (esp in light of
Bear's request in the MUC for summary).      This note is not capturing areas where I was not involved in discussions (E2E) or areas
where I don't feel competent to record things.

Notes not in strict chronological order, as we went back and forth on areas.

1.  Goffi went over some concerns on using MAM with PubSub.   A key observation is that MUST requirements in MAM may be over-ridden
by negotiation in new XEPs that extend MAM.   This approach alleviated concerns with MAM as a base.

2.  For MIX,  MAM will always be used to access items on nodes.     This arose from a discussion noting that both MAM and PubSub
could be used to access different information, and concern around implementation difficulties in some products.   The direction is
in part because it will be cleaner to specify a single MIX access mechanism for messages.   Also the mechanism in pubsub for
fetching items isn't sufficient and would need an update, which would be hard to achieve given the widespread deployment of
XEP-0060. The MAM approach of returning items separately is desirable, and so this will be the single approach for MIX.  The desire
to change pubsub 'get items' came up in the discussion over MAM with XEP-0060 (Item 1), and in this later discussion this seemed
like a reasonable solution for both MIX and possible future adoption for generic XEP-0060 (although probably standardised external
to XEP-0060).

3.  If there is an ability to "modify state", history and "current state" are different.   For example if a message is 
retracted.  The history will include the original message and subsequent changes.  "current state" will only include "how things
ended up".     MAM access will be given an option to show "full history" or "current state". The expectation is that MAM will be
used in two 'modes' when accessing pubsub node items, configured by a (standardised) flag in the data form - to fetch either
'current items' (equivalent to what pubsub get items currently does) and the history (what MAM currently does).  It's important that
the 'full history' includes retracted items, as those item IDs may be needed for synchronisation, but it is possible that a service
might replace the actual content of the retracted message such that the original content isn't available in the archive.

4.  A new "retract message" operation will be added to MIX based on XEP-0060 retract.

5.   Need to expose MIX create rights, so that client can see whether or not to expose channel creation UI.  To be addressed in MIX

6.  There was a general discussion on Threading, Mentions, and References.   It was agreed that these would all be addressed by a
new "References" XEP.   Kevin Smith took the action to write an initial XEP, which is now submitted.

7.  This will use a single reference mechanism, with a URI for external elements such as files, internal elements such as FDP forms,
MIX messages (proxy jid/channel),  users (jid).

8.  Threading is a desirable capability for MIX Channels and for Blogs which is already used extensively in some systems.

9.  MIX compatibility with MUC was discussed and no significant issues identified.

10.   Proxy JIDS can be added to roster.     This enables a user to reference a MUC member in their roster without knowing the real
jid. MIX server will do rewrites as messages go through to maintain privacy.   This will be optional to implement, and may be
configured off.

11.  A MIX channel can be configured to disallow PMs.

12.  The standard invite mechanism has the inviter get a token from the MIX channel and then pass to the invitee. Unlike MUC, it is
possible for a user's server to unilaterally add them to a MIX channel. This will be useful for organisations that want to put users
into policy-determined channels automatically, without requiring client interaction

13.   There was a detailed discussion on optimizing connection round trips.   Once TLS is established, there is significant
opportunity to use pipelining and reduce round trips.  Version information provision (e.g., rosters) can also reduce data
requirements.   Some ideas were discussed in the room.  Tobias Markmann has taken the action to write up the current situation, to
facilitate discussion that will lead to specification of new protocol.


More information about the Summit mailing list