Sam Whited for Council 2020

About

• Name: Sam Whited
• Mail address: sam@samwhited.com
• JID: sam@samwhited.com
• Company: NS1

I am a former council member running again for 2020. This will be my third term on the council.

Overview

Though I haven't been involved very much over the past year I'd like to get back to my XMPP projects and start being more involved in the community again.

Aside from authoring XEPs, working on an XMPP client and server library, and participating in XSF discussions and other business, I have a few goals that I would like to specifically address while on the council. In the past my council work has involved cleaning up confusing duplicate XEPs and pushing for the advancement of XEPs which are widely used but still considered experimental, while that won't change this year, I think this work is largely done (with a few notable exceptions such as Carbons) so I'd also like to focus on the following areas:

Create Policies Around the Compliance Suites

I used to author the compliance suites, but stopped when I felt that our inability to publish suites for each year in a timely manner made the XSF and me as the author appear incompetent (and perhaps I was since I couldn't always convince the council to publish the suites in a timely manner).

To help solve this I would like to clarify the purpose of compliance suites, create a set of criteria for XEPs on the compliance suites, and create a process by which they can be advanced easily even if they're not absolutely perfect (since we'll have another shot at improving them next year), or by which previous compliance suites can be re-used if nothing has changed.

The exact mechanism by which this takes place, and the criteria for doing so are up for debate, but I'd love to get this discussion started and prod it along in my next council term.

The XSFs Role in the Public Jabber Network

There has been a great deal of discussion in the past about whether the XSF is purely a standards body or whether they should also guide the public XMPP network in terms of feature adoption, recommend XMPP related software, or otherwise act as a more general software foundation.

I would like to use my position on the XSF council to further this discussion. I see the councils role in this discussion as being a purely advisory one. We would facilitate discussion in the community, try to come to consensus among ourselves, and then make a recommendation to the board who would make any final decisions.

How I Vote

When voting to advance, I am somewhat liberal. If we move a spec to draft and major problems are found, a migration strategy to a new spec that fixes the problem can always be written. Currently too many specs languish in "Experimental" long after they are widely used and understood. My strategy can be primarily summed up as "is this of substantial value to the public Jabber network, or do a significant number of XMPP based services (public or private) already implement it? If so, and if there are no known major security issues, advance it."

However, view on accepting XEPs is somewhat more conservative than others "just get the text under XSF control as quickly as possible". While I like the idea of getting text under XSF control quickly, I believe we should be very cautious about accepting XEPs where a competing standard already exists. Competition is good, but our current process leads to confusion and incompatibilities among clients. Similarly I do not believe we should accept any XEP that still contains TODOs (though I often abstain from these votes when other council members feel strongly that an XEP should be brought under XSF control). XEPs, even in their initial form, should be something a developer can read and implement without having to skip over deliberate omissions and missing sections.

That being said, for initial acceptance and advancing I think it's important to take community members expectations and opinions into consideration, and this would be my guiding principal when making voting decisions.

My XEPs

I am currently an author or co-author on the following XEPs:

- XEP-0386: Mobile Considerations on LTE Networks
- XEP-0364: Current Off-the-Record Messaging Usage
- XEP-0366: Entity Versioning
- XEP-0367: Message Attaching
- XEP-0375: XMPP Compliance Suites 2016
- XEP-0377: Spam Reporting
- XEP-0378: OTR Discovery
- XEP-0383: Burner JIDs
- XEP-0387: XMPP Compliance Suites 2018
- XEP-0389: Extensible In-Band Registration
- XEP-0393: Message Styling
- XEP-0438: Best practices for password hashing and storage

And a few tangentially XMPP related I-Ds:

- Channel Bindings for SCRAM over TLS 1.3

- Best practices for password hashing and storage