➡ Carbons are dead. Long live Carbons! ⬅—official campaign slogan, 2021
- Georg Lukas
- Ge0rG in the usual MUCs
- XMPP identifier: firstname.lastname@example.org
- Employer: rt-solutions.de GmbH (Germany)
This is my fifth application for Council, where I have served since 2017. I have a progressive agenda to make XMPP suitable for the Instant Messaging of today, especially on mobile devices.
I'm a client developer (https://yaxim.org) and a server operator of a mid-sized public server. I have experience with designing and implementing network protocols, and I've done some work on XEPs in the past (see below).
I usually have strong opinions. A clearly written and unambiguous specification is paramount to consistent implementations on the client and server side. XMPP has many corner cases caused by loosely written, imprecise specifications. These make debugging of user problems harder than needed (and often cause those problems in the first place). When elected to Council, I will work hard to reduce the number of these corner cases and to specify well-defined behaviors for those that can not be removed.
I am also in favor of adding UX implementation guidelines into XEPs, because normal users are confused when every client looks and behaves in different ways.
Jabber (the IM ecosystem) needs many usability improvements. My ongoing activities in that regard are:
- Easy XMPP: improve onboarding, UX, MUCs, etc
- Make onboarding of new users easier with the Easy XMPP Invitation landing page and XEP-0445: Pre-Authenticated In-Band Registration
- Share links for automatic roster approval with XEP-0379: Pre-Authenticated Roster Subscription
- Allow the creation of pre-configured accounts XEP-0401: Ad-hoc Account Invitation Generation
- Easy XMPP: The Challenges on our blog
- Maintenance of the Compliance Suites: 2019 2020 2021
Fix the Multi-Client Story
There are many edge cases in setups where a user runs a mobile client plus a desktop client on the same account. Messages are still lost, different things get delivered to online clients and stored into MAM/offline storage, encryption fails, etc.
We need to evaluate our current situation with regards to the base protocol, how it is used, XEPs related to multi-client operations, etc. Then we need to make a clear mission statement for how we want the system to work in the future. Finally, we need to change our protocols in a way that doesn't break backward compatibility, while providing more robust support for modern use cases.
Topics to address:
Get Rid of Spam
XMPP spam is getting more and more prevalent. We have some obvious and some more complex tasks:
- Improve default server setups to prevent IBR / mass-flooding: Jabber Spam Fighting Manifesto
- Improve server admin contact Infos (use XEP-0157)
- Improve detection and blocking of inbound spam messages / presence: Ask me about mod_firewall (prosody)
- After blocking the advancing of XEP-0280 in 2015, 2017, 2018, 2019, 2020, and 2021, I accidentally shepherded it into "Stable"
- XEP-0445: Pre-Authenticated In-Band Registration
- XEPs have a scary looking way to list known related CVEs
- Mandatory Carbon rules
- Death of the legacy GroupChat 1.0 protocol
- XEP-0379: Pre-Authenticated Roster Subscription
- XEP-0401: Ad-hoc Account Invitation Generation (Some high-level / conceptual contributions)
- XEP-0410: MUC Self-Ping
- What's Broken in XMPP, Summit 2018 edition - the talk I gave at the XSF Summit 2018