This is my (Jonas Schäfer) application for the XMPP Council for the term 2021/22. The election page is at Board and Council Elections 2021.
Contact info / meta
I am currently employed as DevOps Engineer at CLOUD&HEAT Technologies GmbH.
Who am I / What are my qualifications?
- I served in Council for three terms, the last two as Chair.
- I have served as an Editor in the XSF for four years now. This has brought my attention to many parts of the XEP space and made me familiar with the XEP process itself.
- I am the main author of the aioxmpp XMPP library for Python. aioxmpp has been built from scratch (only on top of a SAX XML parser) and supports RFC 6120 through 6122, as well as many important XEPs, such as Stream Management. The process of writing this library has brought me close to the protocol and gave me lots of insights into the edge-cases.
- I am developing, hosting and maintaining the Public Chat Room search engine at search.jabber.network. This is a large-scale application interfacing with many different implementations (currently interfacing with 1586 domains), which has sharpened both aioxmpp and my sense for interoperability.
- I am also offering the free monitoring-as-a-service for XMPP operators at observe.jabber.network. This is a monitoring deployment where anyone can add their servers to receive emails in case they become unreachable from the internet and/or the federation. Including certificate expiry warnings.
- I am the author of three XEPs:
- XEP-0390 (Entity Capabilities 2.0): Replacement for XEP-0115 which fixes issues with hash agility, the insecure hash input generation and gives entities more power in caching disco#info responses. There is an implementation in aioxmpp (obviously :)), as well as an experimental implementation in prosody.
- XEP-0392 (Consistent Color Generation): Algorithm to generate a color value based on text; used to generate dummy avatars or color participants in a MUC. Has been deployed on Conversations, poezio and maybe others.
- XEP-0394 (Message Markup). Attempt to provide a replacement for the deprecated XHTML-IM. I gave this one up for someone else to fix.
- Make our contribution process more inclusive, especially for new contributors. Mediation between authors and Council and other teams/bodies of the XSF is crucial to not lose talent and new interest in the protocol. I think we can still improve here by providing more guidance to new authors and be more inclusive in our meetings. In the past, I explicitly pinged people who were not in the room when their work was being discussed to allow for clearer communication.
- Support the next council chair to allow for a smooth transition.
- Make our specifications more useful to new and existing developers. This means in particular:
- Ensure that identified edge-cases are well-defined in the specifications
- Document and/or standardise workarounds for existing issues and extensions to existing protocols, even if those existing protocols are already in Draft state (looking at you, XEP-0045).
- Improve the modern IM use cases. This means in particular:
- Work on solving the group chat use-cases. This means, among others, approving fixes and extensions to MUC, as well as monitoring and contributing to the development of MIX (which is still Experimental).
- Work on multi-device use-cases: Drive and support the development of IM Routing NG (XEP-0409), as well as improvements regarding configuration sharing between clients and with the server (think notification preferences).
- Take the different modern IM use-cases into account and consider how they interact and can be solved with our specifications. Some GNOME folks have used the terms Banquets vs. Barbecues for describing the two different flavors of group chats: anonymous, IRC-style, FLOSS-community chats (Banquets) and private, non-anonymous, family-type chats (Barbecues). There are implications in how to handle traffic for both of them w.r.t. notifications on the client, push and CSI. If XMPP is to cover both cases (and I think it should), we need to take those differences into account and make our specifications flexible enough.
My Role in Council (and evaluation of the past year)
So the past two years I served as Council chair. The routine I developed during my first term worekd quite well, however, it has started to break down in the second half of the second term. I attribute this to the repetitive but-not-quite-automatable nature of the tasks and I think a term of recovery is in order.
Aside from that, the same list as last year:
- Attend the meetings as reliably as possible: This has worked quite well in the past year. There have been occasions where I wasn’t able to attend, but most of them have been communicated well ahead of time and we found solutions for that.
- Judge contributions to XEPs where Council has to decide about the acceptance for the bettering of the protocol: I think this improved a lot compared to the previous year; relying on expertise of community members has been a good working method.
- Judge ProtoXEPs and vote for their acceptance if they are not harmful, have a goal which can be understood and do not duplicate existing protocol (with exceptions, e.g. accept two competing ideas to see their further development): I think I learnt a lot from the Reactions case here. I think we need to be less protective of Experimental and encourage, well, experimentation more.
- Comment on standards as they happen: I surely hope I voiced my opinion where I had something to contribute and shut up otherwise.
- Guide (new) contributors to XEPs in a way which is welcoming and avoids duplicate work (for example, make it clear politely when a contribution is going in a direction which is unlikely to be accepted by the Council): We do have problems in this area, see also my Goals section.