Dave Cridland for Council 2017

Particulars:

I am Dave Cridland, dwd@dave.cridland.net, and I am employed by Surevine Ltd. I work on Various Things, but around 90% of my current workload is specifically working with XMPP. The remaining 10% is spent doing my expenses. I have the full support and indeed encouragement of Surevine Ltd to stand for Council, and while my views are inevitably informed by the issues I encounter in my work, I don't intend to represent Surevine.

I am also a Director of the Igniterealtime Foundation, the holding Foundation behind Openfire, Smack, and various other projects, and also the nominal "Project Lead" for Openfire (though Guus, Sean and Daryl really do all the hard work).

I have previously served on both Board and Council for the XMPP Standards Foundation.

I have worked on the code of either three or four servers (depending on what counts as a server), and three (or, maybe, four or even five) client libraries, and occasionally have messed about with entire clients. Sometimes even to their benefit.

Aims this year:

Much to the surprise of many of us, XMPP has ended up as the Old Man of instant messaging. My personal aims this year are to modernise and really push the protocol suite. Over the past couple of years I've become less concerned with backwards compatibility, in part because a considerable amount of the remaining clients are actively developed.

In particular, by the end of this (calendar) year, I'd like to see solid progress on Two Factor Auth, 1-RTT session startup, and MIX. Most of these I'm personally working on (and, quite honestly, have no need to be on Council to address).

Concerns:

As a community, we made excellent progress on a number of difficult issues a while ago by concentrating on basic interoperability instead of getting bogged down by details.

Examples are CSI, Carbons, Hints and so on - all these work just fine without precise rules on exactly what stanzas are handled how. Instead, these protocols focused on getting raw interoperability - a client issuing a CSI "inactive" doesn't need to behave any differently with a server that does deep stateful stanza inspection versus a server that pauses traffic on very coarse rules. The benefit of this is both that a simple implementation is simple to do, and that it gives servers the opportunity to differentiate on quality of implementation.

Since then, we've got worryingly close to trying to specify every behaviour rigidly. I don't think this benefits us as a community nearly as much as its proponents think it will, and I feel that at best it falls foul of Carl von Clausevitz's famous (but usually misquoted) truism that the enemy of the good plan [or, indeed, protocol] is the dream of the perfect one.

I appreciate that different cases seem important to different people, and I'm absolutely as guilty as everyone else of homing in on some probably irrelevant issue. But I think we all need to stop and focus somewhat better on making things both simple and functional, and perhaps not try to solve every problem at once.

As a result of this, and losing momentum in other areas (like MIX), I don't feel like we've made very much useful progress this past year. As I served on Council, I have the share the blame for this - but I'd like to fix this next year.