Difference between revisions of "Georg Lukas for Council 2017"
(Created page with "= Contact Info = * '''Georg Lukas''' * '''Ge0rG''' in the usual MUCs * XMPP identifier: '''[xmpp:email@example.com firstname.lastname@example.org]''' * Employer: [https://rt-solutions.de/en/home-2/...")
Revision as of 12:51, 3 November 2017
- Georg Lukas
- Ge0rG in the usual MUCs
- XMPP identifier: email@example.com
- Employer: rt-solutions.de GmbH (Germany)
This is my first application for Council. I have a progressive agenda to make XMPP suitable for the Instant Messaging of this decade (even if it's a bit late).
Jabber (the IM ecosystem) needs many usability improvements. My ongoing activities in that regard are:
- Provide a unified glossary to developers and users, hiding complexity where possible
- Easy XMPP: improve onboarding, UX, MUCs, etc
- XEP-0379: Pre-Authenticated Roster Subscription
- Easy XMPP: The Challenges on our blog
- Solve the "Jabber" vs "XMPP" name clash
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
- Improve server admin contact infos
- Improve detection and blocking of inbound spam messages / presence