User:Jwi/Application 2019

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 out of 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 first time this term.

General attitude

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

(This section hasn’t changed much in the last year.)

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.

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.

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 application for that).

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.