Minutes of the 2019 Summit: Day one

1035: Agenda Bashing


 * Compression
 * MUC Room Avatars
 * MIX
 * OAuth Authentication
 * &lt;moved/&gt;
 * Full Stanza Encryption
 * IDs
 * MUC Push
 * SPAM
 * Routing 2
 * Bind 2
 * SASL 2
 * Compliance Suites Marketing
 * Smart MAM (when archives contain more than just messages)

1050: Smart MAM


 * MAM may be full of metadata (reactions, references, etc.), you don't want to receive all that on login
 * 2 models when you use MAM: either get everything at startup and have a local cache, or get messages when you need them, and explore metadata if needed
 * MAM2
 * Receipt
 * Read (by them | by us)
 * Correction
 * Reactions
 * Polls
 * References
 * JIDs that changed
 * 2 Dimensional -&gt; 3 Dimensional (messages, types of metadata / what type of annotation, meta values)
 * having a summary of e.g. reactions (&quot;110 people ♥&quot;), and details on demand (who liked?)
 * for reactions
 * for 'read by', similar to 'received by'
 * How to define a generic format without having MAM being too smart
 * Ability to update/correct previous metadata (reactions, etc.)
 * Ability to query for selected metadata for a message ID (like query all reactions, corrections for ID foo)
 * Query by range (like when scrolling in a message window)
 * Nasty IDs (who creates them client? MAM? etc.?)

1150: MUC Avatars


 * There are plenty of avatar XEPs
 * Currently folks use vCard based ones with presence enhancements
 * Should use PubSub based stuff like PEP and MUC PEP

1155: Lunch break (back at 1300)

1325: BIND2 &amp; SASL2


 * Dave did a SASL2 implementation for Openfire, it works, but never created a PR
 * SASL2 needs 1 less round trips
 * BIND2 would be a post-authentication task of SASL2 (according to Dave)
 * SASL (Ok, Failure) -&gt; SASL2 (Ok, Continue (another step), Failure)
 * Discussions on ISR tokens pre authentication and so
 * Summary: SASL2 seems ready to go according to Kev.
 * Discussions on requirement of BIND2 and SASL2
 * SASL2 saves roundtrips because it does not require a stream restart
 * State of BIND2, MattJ mentions that there're lots of TODOs and FIXMEs in it. According to Kev it's ready to implement, though.

1405: OAuth


 * OAuth as a way to give other services access to a XMPP account
 * OAuth SASL mechanism already exists. But it's for authenticating XMPP accounts. (XEP-0235, see also XEP-0355 XEP-0356)
 * https://docs.ejabberd.im/developer/ejabberd-api/oauth/

1425: Break

1455: IDs


 * Problem: XMPP doesn't require IDs on presence/message stanzas. Minimal requirements on them, i.e. being unique per stream.
 * Ideally you want globally unique IDs ( like https://en.wikipedia.org/wiki/Universally_unique_identifier#Version_4_(random) )
 * Messages should have IDs that are unique enough so you can reference them and find them
 * One proposal: Rewriting and translating IDs on the server side (similar to NAT)
 * other proposal: IDs generated by clients from well known rules which can be verified by server (e.g. combination of hash of Stanza + some index of the stanza)
 * HMAC based IDs: HMAC(key=stream id, data=session management counter)
 * Change XEPs (references, message correction) use (sender bare JID + ID) instead of only (ID). Broken IDs are then limited to the sending bare JID. So you are referencing messages via (bare sender JID, ID) tuple

1550: Routing 2


 * MattJ started a routing implementation and is using Routing 2 ( IM NG ) as spiritual guidance
 * MattJ has currently nothing to discuss at the moment, but likely will when he's done

1555: MIX


 * Daniel started a protoype client implementation and has feedback on MIX putting stuff in the roster for presence to work
 * Ralph did an implementation without roster magic, instead using phone book
 * Dave's feedback on MIX is that there's a huge amount of work required to get even partional message only MIX functionality working
 * MattJ mention adoption problems because not only the hosting server needs to support MIX but also all joining users' servers need to support MIX
 * Kev's suggestion, servers always dual-host MIX/MUC. Users on severs that don't support MIX will join via MUC automatically.
 * Kev mentions joining users' server MIX support requirement can be dropped but would make implementing MIX component more complex.
 * MUC and MIX dealing with transient S2S outages
 * Jonas suggests to split out the MIX entries from the roster. this reduces the requirement of user account server support for that (except when presence is to be sent) and reduces the mixing of classic roster data with MIX services (pun not intended)

jonas’ (that’s me) says, re compression, https://github.com/horazont/aioxmpp/issues/249 contains numbers.

one more for IDs: http://logs.xmpp.org/xsf/2018-02-12/#16:14:23 TL;DR: some light discussion between me, kev, dave and saltybones about verifiably generating unique-ish IDs with an HMAC; could be used with daves on-list proposal at least for c2s IDs to prevent evilness. could even be used client-to-MUC if a nonce is transferred on MUC join