Kevin Smith for Council 2018

Revision as of 14:45, 1 November 2018 by Kevin (talk | contribs) (Created page with "== Me == I'm Kev. I work for [ Isode], where I'm responsible for the various server and client XMPP projects/team. == My Aims == For the past several years...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search


I'm Kev. I work for Isode, where I'm responsible for the various server and client XMPP projects/team.

My Aims

For the past several years I've been trying to drive towards using XMPP for 'modern' messaging. Starting with my 'multi-client story' document a number of years ago, working through stanza forwarding and MAM, trying to ensure Carbons can work sensibly as part of the 'big picture' (we're not there yet), bind2 to bring them all together, and in the near future the missing part of an unread-sync XEP, as well as MIX to attempt to address the shortcomings of MUC, and References for richer content. This has more recently, and more trendily, been called "XMPP 2", with the routing rules document sent out at the summit this year, and it's stuff that I think is important for us to be working hard on (and is my main focus at the moment in the protocol world). So I want to push at continuing this.

My Past

I've been "doing XMPP" since before it was called XMPP. In that time I've (non-exhaustively, although exhaustingly) been project lead for the Psi client, worked on SleekXMPP, co-authored XMPP: The Definitive Guide for O'Reilly, served (mostly because I'm daft) in more Council terms than anyone else, chaired Council the most terms, co-started the Swift client, worked on the M-Link server, helped with several of the Brussels summits, reviewed an obscene number of (proto)XEPs, written several XEPs, been GSoC admin and mentor assorted times and generally been Quite Involved with XMPP.

What Council Means

Some thoughts on what it means to be on Council, to me, and therefore what you can expect:

  • Attend the meetings (as much as possible)
  • Read the standards discussion on the mailing list, contribute where appropriate
  • Review all protoXEPs
  • Let through XEPs to Experimental as long as they're not obviously harmful/broken, or needlessly duplicating existing protocol
  • Provide guidance in the standards process