# XMPP Summit 25 ## Day 1 ## Push 2.0 [Link to draft proposal](https://pad.nixnet.services/s/GPBR4xa4k)  ([Source](https://cerdale.zash.se/s/ACKJrpXUEylvT6932R63SV_f/DSC02748.JPG)) - Can we just compress the stanza? Custom dictionary? - Can servers consider a user who is registered for push notification as "online" for presence purposes? - Something more or less already accomplished today by using XEP-0198 and extending it's timeout to start only after the first push was sent - Should we run XMPP push to WebPush proxies as sidecars next to servers (extdisco? like STUN/TURN) ### WebPush Suggestion from Daniel to support or even adopt only WebPush as the protocol from the XMPP server to the push server. This could relieve the client developer from needing to run a gateway for e.g. web apps (you still need one for APNS/FCM due to the credentials). XMPP servers would need to do HTTP client stuff. Server developers in the room not keen, but not a deal-breaker. However, some of the more advanced WebPush features such as delivery receipts (not actually implemented by Mozilla currently) may increase complexity - server devs feel that they would want to externalize this kind of thing. That might as well be over XMPP, which takes us back to where we started. Therefore, agreement to keep the protocol as XMPP-only for now. In the special case of WebPush-native clients, shared or server-local options could be developed which would not require the client developer to maintain a gateway. ### Push on iOS Some discussion occurred around push/background restrictions on iOS. Thilo (developer of Monal) wrote up his perspective, which is [available on wiki.xmpp.org](https://wiki.xmpp.org/web/Push_notifications). ## Lightning Talk: XMPP Providers - https://providers.xmpp.net/overview/ - Getting disco features - which gateways are available? (IRC, ActivityPub, etc.) - does the pubsub service support XEP-0XXX? - Issue: https://invent.kde.org/melvo/xmpp-providers/-/issues/85 - How do you test the registration success? - We just test if its open for registraton - Issue: https://invent.kde.org/melvo/xmpp-providers/-/issues/86 - ActivityPub - with ActivityPub, instances have a strong focus on communities (e.g.: people having interest in FOSS, LGBT+ friendly, German speaking, etc.). There moderation is also a major topic (to avoid harassment, harmful content, etc.), and you can follow message from the instance only. So the choice of instance is really important, and we should take inspiration from there and provide informations on moderation policy, and a short sentence describing the purpose of the instance in human friendly way, ToS is also something important to retrieve. - We track the legalNotice already - https://invent.kde.org/melvo/xmpp-providers#criteria - Issue: https://invent.kde.org/melvo/xmpp-providers/-/issues/91 - Suggestion to offer rating by users - Issue: https://invent.kde.org/melvo/xmpp-providers/-/issues/88 - Track user deletion policy - Issue: https://invent.kde.org/melvo/xmpp-providers/-/issues/89 - Detecting if server uses [XEP-0004: Data Forms](https://xmpp.org/extensions/xep-0004.html) for registration. (e.g. not all clients support that but they may want to use providers list. This information would allow them to filter this list.) - Issue: https://invent.kde.org/melvo/xmpp-providers/-/issues/90 - Tim: please work with complience suites for the technical side of the provider evaluation - Yes we do already! ## Spaces - Discovery - Index on space component (e.g. pubsub node, disco items) - Admin - Roles - [Hats](https://xmpp.org/extensions/xep-0317.html) - There is a difference between being allowed to join a MUC and being on the member list "There is a MUC domain. Spaces will be addressed on a 'spaces' domain. You join a space using some new mechanism (iq:register?). You're now in the space. You can do 'discovery' in that space to find out which rooms you are able to join on it." Spaces contain: - A structured list of MUCs/Pubsub nodes/whatever - An ACL, supporting roles (hats) - MUCs/microblogging pubsub nodes etc. request from space whether user is allowed to join Spaces support: - Searching ([iq:search](https://xmpp.org/extensions/xep-0055.html)) and paging members of a space - Searching (MUC messages, microblogging content) etc. (via MAM?) ## MUC/MIX - We should "backport" the good parts of MIX into MUC, regardless of whether we eventually migrate to MIX or not - The server could join for the bare JID to make message fanout/dedup cleaner - Could likely be fully backward-compatible - "Legacy" clients who are not joined the "legacy" way could be confused by receiving messages -> one potential solution: make supporting clients signal their support via disco and have the server only fanout to those clients - Similar in parts to IM-NG - Presence spam is one of the biggest problems of MUC; proposed solution by Marvin is to signal the MUC (while joining) to not send presence to the client, and the MUC signalling it understood the request in the presence response. Additionally, add a new API to fetch the presence manually. Fully backward-compatible. Matthew puts a protoXEP for this on his TODO! - The compatibility layer between MUC and MIX is a deal-breaker for Matthew (it's extremely difficult to do right, and without it Matthew doesn't want to support MIX) - Consensus is to kill MIX (not one person's decision!) - Or not? The implementation experience of MIX is smooth, for use-cases without backward-compatibility in mind it is clearly preferable. - References: - [XEP-0045: Multi-User Chat](https://xmpp.org/extensions/xep-0045.html) - [XEP-0369: Mediated Information eXchange (MIX)](https://xmpp.org/extensions/xep-0369.html) - [XEP-0289: Federated MUC for Constrained Environments](https://xmpp.org/extensions/xep-0289.html) ## Saturday action items *Written from Matthew's memory* - Write spaces discovery XEP (~Kev?) - Write spaces admin XEP (~Kev?) - Try again to implement MIX, provide feedback (~MattJ) - Update XEP-0317 Hats with Prosody's implementation, drop the ad-hoc stuff and focus on display/syntax only (~MattJ) - WebPush send profile in Push 2.0, incorporate other feedback and submit (~MattJ) ## Day 2 ## WebPush Are we sure we don't want to use WebPush between the XMPP server and the push gateway? (potentially the client developer, or potentially direct to browser vendors) Consensus from server developers in the room is that staying with XMPP is preferable - however this does not mean that WebPush can't be implemented "locally", still. For example, as an internal or external component. We will still define a WebPush send profile for Push 2.0, so some of this may become clearer then. ## MAM - Reference from Ralph: https://ralphm.net/blog/2019/09/09/fastening ### Collations Clients that don't store the full history locally (so-called "partial knowledge" clients) would significantly benefit from a way to discover the annotated state of a message fetched from history. Messages may be modified/annotated by, for example: - Message correction - Reactions Fastening was an attempt to make a generic framework for this, but consensus is that there are too many special cases to make a generic approach worth it. Instead, servers will need to explicitly support collation of specific payload types. ## Lighting Talk: State of Pubsub, Improvements, and What to Do Now - [XEP-0470: Pubsub Attachments](https://xmpp.org/extensions/xep-0470.html) - [XEP-0475: Pubsub Signing - XMPP](https://xmpp.org/extensions/xep-0475.html) - [XEP-0476: Pubsub Signing: OpenPGP Profile](https://xmpp.org/extensions/xep-0476.html) ## Threaded Messaging - URL: https://kumi.tube/w/1LQQp5Uia4u8Pdojxen1y8 - [XEP-0201: Best Practices for Message Threads](https://xmpp.org/extensions/xep-0201.html) - Messages can start threads on their own (thread id) - Messages can reply + new thread - Within a thread (preserving thread id), you can reply, those are not thread forks - We don't use <thread/> 'parent' attribute Need to figure out collations. You want to collate on the thing that is either the first thing with the thread id, or if that thing is a reply-to, collate on that original message. Add thread-id filter to MAM. If we want to start a thread from another message (e.g. a threadless one, or one in a different thread) we can select a new thread id, and include a reply-to to indicate which message the thread is rooted to. Clients may render reply-to as a quote. Sometimes you may want to start a thread without this semantic. Proposal is to define a new element which references the root message `<i-want-to-start-a-new-thread from='message-id'/>` or something similar. This may or may not be included with a reply element too. ## Lightning Talk: What happened to XMPP in Dutch Healthcare And what happened to the Digital Service Act - Follow and participate in the "More Instant Messaging Interoperability" MIMI IETF discussion: https://datatracker.ietf.org/wg/mimi/about/ _____ ## Feedback on XSF Summit 25 and FOSDEM **What was good?** - It was possible to talk with everyone from the XMPP Team. Exchange ideas, learn more about XMPP and it's projects. **What can we do differently?** - Posters: Maybe some more and bigger "fancy" well designed posters to catch the peoples attention at the FOSDEM. - Hotel: find preferred hotel earlier and try to negotiate better room rates. - Sponsors: ask for sponsoring earlier. Many paricipants are not backed by a company and the travel costs can be significant for them. **What stopped us?** - Organisation: Started to late and communication could have been done better