User:Daniel/Council 2023
About me
My name is Daniel Gultsch. I’m self employed and work full time on XMPP related projects. One of my publicly known projects is the open source Android client Conversations but I also do consulting and contract work for commercial projects.
XEPs
There are currently four XEPs that bear my name:
- XEP-0363: HTTP File Upload
- XEP-0398: User Avatar to vCard-Based Avatars Conversion
- XEP-0411: Bookmarks Conversion
- XEP-0454: OMEMO Media sharing
Security
I concern myself with security in the open source ecosystem and have over the years documented a couple of vulnerabilities in various open source clients.
- CVE-2015-8688: Gajim Roster Push Attack / Message Interception
- CVE-2018-6591: Converse.js leaking information about which rooms are bookmarked
- CVE-2019-16235+: Multiple Vulnerabilities found in Dino
Council work
I've previously served on Council for six, non-consecutive terms in 2017, 2018, 2020, 2021, 2022 and 2023. In the last two years I've acted as the council chair.
A majority of the votes in day-to-day council operation are going to be two things: Accepting XEPs as experimental and moving XEPs from experimental to stable. The criteria in XEP-0001 leave room for interpretation and different people have interpreted them differently over the times. So if you are going to put me into Council you should know how I’m (generally) going to vote on these issues.
Accepting a XEP as Experimental
I’m a believer of providing a stable base for anything people want to work on. To be accepted as experimental a XEP doesn’t have to be perfect. I’m also open to giving a number to XEPs that I personally don’t agree with or find otherwise controversial. I believe that there is room for exploring different solutions to the same problem. However I think that a XEP has to be implementable to be accepted. In the past Council has accepted XEPs that were just a bunch of TODOs or otherwise contained a lot of placeholders. I believe that an independent developer has to be able to look at a XEP and start implementing it.
Moving XEPs to Stable
There are currently a lof of XEPs stuck in experimental that are widely implemented and a working fine for a lot of people.
If we are going to consider experimental as a lower quality just-provide-a-stable-base kind of stage (see previous section) we need to move those XEPs that are widely implemented (and are obviously working for a lot of people) on to stable to make them distinguishable from XEPs that are not fit for use.
There is a chance that one or even all of the XEPs I used as examples above are not the most beautiful things the XMPP has ever come up with. But that doesn’t change the fact that these XEPs are different to the average lower quality experimental stage XEPs. The life cycle state of those XEP has to reflect that.
If we promote those widely used but arguably not 100% perfect XEPs to stable now and come up with a better solution later we can still obsolete them.
It is irritating that our Compliance Suits which are basically lists of XEPs to implement for a good & modern IM experience point to XEPs that then say »Please don’t implement me in production«.