From XMPP WIKI

1035: Agenda Bashing



Compression

MUC Room Avatars

MIX

OAuth Authentication

<moved/>

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 -> 3 Dimensional (messages, types of metadata / what type of annotation, meta values) having a summary of e.g. reactions ("110 people ♥"), 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 & 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) -> 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

