User:Jwi/Application 2022

Metadata

Name

Jonas Schäfer

Profession

DevOps Engineer

JID/Email

jonas@zombofant.net, jonas@wielicki.name (both work as Email and JID)

Nicknames

jonas’ (in MUCs), horazont (on GitHub and IRC), jssfr (on GitLab and IRC)

Company

CLOUD&HEAT Technologies GmbH

Note: When contacting me via XMPP, please send a short message along your subscription request, because I get quite a bit of SPIM and have stopped accepting unsolicited subscription requests without any context. Please avoid the use of OMEMO because not all of my clients support it.

XMPP Background

I used to be mainly in the realm of client development, though I have started to touch on the server side of things in the past year. I started actually using XMPP in about 2010, and soon began to develop "bots" which perform several tasks based on SleekXMPP. The versatility of XMPP I learnt about in that process hooked me for the protocol.

In 2014 I decided to start developing an XMPP library (aioxmpp) and client (JabberCat, very incomplete) on my own. The client is targeted for the Desktop user while the library has no specific target audience and is intended to be usable for about every client scenario. I am very interested in the quality of the XEP specifications, because this is essentially the only resource developers have when writing code for XMPP entities.

I am also part of the XMPP Council for the third time this term and serving as the Chairman for the second time.

Since 2018, I also run the Jabber Chat Room search engine on search.jabber.network.

In 2020, I started the free public monitoring service for federated XMPP servers.

General attitude

• I think that the distinction of XMPP (the protocol) and the applications making use of it for various use cases (such as chat clients, IoT things etc.) is a double-edged sword, but an important one.

Many of the vocal people in our community associate XMPP with chat, exclusively. This is problematic for two reasons: Firstly, this excludes non-Chat use-cases such as IoT and secondly (and more importantly), it makes it tempting to use XMPP as a brand for chat applications, which I consider a suboptimal approach.

Mind that my knowledge is only about the instant messaging applications of XMPP, hence that is where my focus will be on.

• Instant message routing issues have come up less in the past years, however, we are still missing a proper solution due to lack of deployment and implementation of the IM-NG XEP. I welcome further developments in that regard.

• Next to onboarding, proper device and authorization management is a thing XMPP is lacking in comparison to other similar protocols. Currently, the only standardized way to gain access to an account is SASL authentication (typically with a password or a certificate). There is no standard way to restrict the permissions of individual clients and revocation of individual device access is, in the open federated network at least, still a niece feature.

Why should I vote for you?

Ever since my first year in the XSF, I have been active member of the Editor team, as you probably know if you read standards@ ;-). I intend to continue this work to help the standards process. Also, I’m a member of the XMPP Council (also see my most recent application for that). Not renewing my membership would probably remove me from my council role, so if you’re unhappy about what I’m doing there, now is your chance.

Still, I’d like to continue to work in both roles to help the XMPP standards community.

Aside from that, I intend to further contribute to the standards process, but as per usual, this doesn’t require a membership.