User:Jwi/Council 2018

Contact info / meta

I’m Jonas Schäfer, formely known as Jonas Wielicki. You can find me in XMPP related MUCs as jonas’ (formely jonasw), 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 DevOps Engineer at CLOUD&HEAT Technologies GmbH.

This is my first application to the Council.

Who am I / What are my qualifications?

• I have served as an Editor in the XSF for over a year 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. On top of that library, we’re working on a desktop XMPP-IM client.
• 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 am not really happy with it as it stands, and I am torn between retracting it and trying to fix it. However, XEP-wise my focus is currently on 0390 and 0392.

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