Difference between revisions of "Daniel Gultsch for Council 2019"

Jump to navigation Jump to search
(Created page with "== 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...")
 
 
(4 intermediate revisions by the same user not shown)
Line 1: Line 1:
== About me ==
== 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 [https://conversations.im Conversations] but I also do consulting and contract work for commercial projects.
My name is [https://gultsch.de 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 [https://conversations.im Conversations] but I also do consulting and contract work for commercial projects.


=== XEPs ===
=== XEPs ===
Line 9: Line 9:


=== Security ===
=== Security ===
I concern myself with the security in the open source ecosystem and have over the years documented a couple of vulnerabilities in various open source clients.
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.
* [https://gultsch.de/gajim_roster_push_and_message_interception.html CVE-2015-8688]: Gajim Roster Push Attack / Message Interception
* [https://gultsch.de/gajim_roster_push_and_message_interception.html CVE-2015-8688]: Gajim Roster Push Attack / Message Interception
* [https://gultsch.de/converse_bookmarks.html CVE-2018-6591]: Converse.js leaking information about which rooms are bookmarked
* [https://gultsch.de/converse_bookmarks.html CVE-2018-6591]: Converse.js leaking information about which rooms are bookmarked
Line 17: Line 17:
I've previously served on Council for two terms in the years 2017 and 2018.
I've previously served on Council for two terms in the years 2017 and 2018.


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 ''draft''. 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 issue.
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 ''draft''. 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 ===
=== Accepting a XEP as Experimental ===
Line 27: Line 27:
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 draft to make them distinguishable from XEPs that are not fit for use.
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 draft 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 over 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.
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 ''draft'' 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«.
180

edits

Navigation menu