User:Jwi/Application 2020

Metadata

Name

Jonas Schäfer (formerly Wielicki)

Profession

DevOps Engineer

JID/Email

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

Nicknames

jonas’ (in MUCs), horazont (on GitHub 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.

XMPP Background

I am mainly in the realm of client development. 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 second time this term and serving as the Chairman for the first time.

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

General attitude

I think XMPP as an IM application (Jabber) still has two main issues: On-boarding and Message Routing.

(This section hasn’t changed much in the past two years, unfortunately, though we are making progress on the onboarding front.)

On-boarding

Especially compared to other modern IM solutions, Jabber is inconvenient to set up (cf. Easy Onboarding). The work which is being done in the area is promising, and I like to participate in those discussions. We need to massively simplify the on-boarding process of non-Jabber users. Concrete goals in the protocol realm I see which need addressing: device management (add/remove devices without having to type passwords), establishing means for account/password recovery, inviting users with as few interactions as possible even to servers which do not offer public registration and standard and well documented interfaces for managing account metadata and configuration.

Message Routing

This is a big one. The routing (and archiving) rules for messaging have grown historically and are often only vaguely defined, leading to interesting (inter-)operability issues. While the idea of only vaguely defining rules in order to allow for wiggle-room for experiments is in its core not bad, the fact that Message Routing is an insanely complex problem makes vague rules frustrating to developers of both clients and servers (not to mention, their users when something goes wrong). The complexity isn’t exactly alleviated by the fact that they touch the very core of an IM solution: being able to deliver messages reliably. I think the issue deserves a proper solution which considers all modern use-cases alike—which is a very difficult problem.

On the less protocol-as-written side, I think we have to work out a few kinks in our standards process. The vast amount of Experimental specifications which are already widely deployed, as well as specifications which haven’t even made it to Experimental and are still deployed on many devices is a massive issue. We’ll have to work out how to improve our standards process in this regard, possibly by modifying how the states work or by introducing another non-standard document track (for documents such as OMEMO Media Sharing).

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