Difference between revisions of "User:Jwi/Application 2021"

From XMPP WIKI
Jump to navigation Jump to search
 
Line 23: Line 23:
=== General attitude ===
=== General attitude ===


After not updating this section in the past [[User:Jwi/Application_2020|two]] [[User:Jwi/Application_2019|years]], I decided it needs updating.
After not updating this section in the past [[User:Jwi/Application_2020|two]] [[User:Jwi/Application_2019|years]], I rewrote it for this year.


I didn’t get around to do that yet, though.
* 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.
 
* A major problem of XMPP (as Chat) is still onboarding. Important work has happened regarding this in the past year and a half, which is great. We now need to push for better standards around that, including the ability to provide terms of service and privacy policy information during signup at a specific service.
 
* Instant message routing issues have come up less in the past year, 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.


=== Why should I vote for you? ===
=== Why should I vote for you? ===

Latest revision as of 15:50, 14 February 2021

Metadata

Name
Jonas Schäfer (formerly Wielicki)
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 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 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

After not updating this section in the past two years, I rewrote it for this year.

  • 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.
  • A major problem of XMPP (as Chat) is still onboarding. Important work has happened regarding this in the past year and a half, which is great. We now need to push for better standards around that, including the ability to provide terms of service and privacy policy information during signup at a specific service.
  • Instant message routing issues have come up less in the past year, 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.

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.