User:Jwi/Council 2022

This is my (Jonas Schäfer) application for the XMPP Council for the term 2022/23. The election page is at Board and Council Elections 2022.

Contact info / meta

I’m Jonas Schäfer. You can find me in XMPP related MUCs as jonas’, or can contact me via XMPP or email. More contact info and meta can be found on my user page.

I am currently employed as Team Lead for a bunch of DevOps Engineers at CLOUD&HEAT Technologies GmbH.

This is my fifth application to the Council. You can look at my 2018, 2019, 2020, and 2021 applications.

Who am I / What are my qualifications?

• I served in Council for four terms, the two of them as Chair.
• I have served as an Editor in the XSF for five years now, though it has been troublesome recently. 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:
  1. 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.
  2. 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.
  3. XEP-0394 (Message Markup). Attempt to provide a replacement for the deprecated XHTML-IM. I gave this one up for someone else to fix.

Goals

Primary Goals

• 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.

Background Goals

• 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)

• Attend the meetings as reliably as possible: This has worked quite well in the past year again. There have been occasions where I wasn’t able to attend, but most of them have been communicated well ahead of time.
• Judge contributions to XEPs where Council has to decide about the acceptance for the bettering of the protocol: There hasn't been much I remember, but I think this mostly worked out.
• 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 tried to live the more inclusive approach and bring things to Experimental to work on, rather than bouncing ProtoXEPs.
• 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): I think in the past term, this went mostly smoothly.