XMPP Council - 2016-09-21

it is time

0) Roll call

Yay

Here

Present

Peter sends apologies

here

I'm not aware of any new items to vote on today

1) Date of next

sbtsbc?

wfm

wfm

AOB here.

2) AOB?

Yes!

I'm wondering if there's anything we can/should do to unblock OMEMO. It's languishing in protoXEP because it's based around the proprietary OWS protocol.

There's been the suggestion to change it to be based on Olm; does the Council agree this is a way forward?

sounds sensible

Has Olm been audited? I know it's roughly the same thing but using a different curve or IV or something, but I'd like to see a public audit (which OWS has, IIRC)

i don't think it has, don't know if the matrix people plan on doing that

SamWhited, It's a different IV. And yes, OMEMO has been audited, but I would imagine the audit holds.

Going with Olm seems promising, yeah

I don't like the idea of switching and "imagining" that an audit holds :)

I do like the idea of Olm, but since both OMEMO and TextSecure have had separate audits, I don't think we should consider switching unless we can be sure what we switch too has also been audited

Well, more specifically, if merely changing the IV breaks the security in some way, then the audit is really missing something.

If that's the only difference that's fair enough

same goes for changing one curve with another curve with the same security

(note that I haven't read the Olm spec, I'm just asking)

I don't know enough about either protocol to make an informed decision (right now)

SamWhited, Axolotl^WOWS is a no-go - it's not an open standard and specifically is precluded from being reimplemented without legal threats.

Is the differing IV purely for legal reasons?

for making-moxie-happy reasons

I don't know the details, but that's my impression - the same patch that changed the IV in Olm also removed any mention of "Signal".

I'm not suggesting that we stick with Axolotl, just that we don't recommend a switch until the new thing has been audited too (if appropriate); recommending a switch when we know the thing that was audited has been changed seems reckless (though, that might not be the case, I'm just hesitant since I haven't read the spec)

I think using the OWS protocol appears to be a dead-end, so I think we've nothing much to lose by switching

i think having an audited solution shouldn't be a requirement for an experimental XEP

I think we should switch, and chase for some expertise

I don't think it should be a requirement, but when we have something that's widely used (more or less) already it seems poor to recommend changing that (which is effectively what we're doing by publishing an experimental XEP, even if we don't intend it people will take it that way)

Then again, I'd also love to see OMEMO published

having it published and easier to implement will result in even wider usage

Indeed, if you speak to client devs, it's holding back adoption

Well, we *could* document Axolotl, based on the Olm documentation and the audits.

I despise the GPL for this reason… I suppose having something out there is better than nothing

And my concerns might not even be valid if that's really the only change

Olm isn't GPL afaik

I don't see any license at all on the Olm page; do we know we won't have a problem with them later too?

olm seems to be Apache https://matrix.org/git/olm/tree/LICENSE

That's the implementation; what about the spec itself? Can developers reimplement it? I think the concerns with Axolotl are specifically that we don't want to depend on a proprietary spec

Or does none of this make sense and I don't understand copyright law?

SamWhited, We can approach Matrix and ask.

Sounds reasonable

SamWhited, according to Thijs Olm's spec looks more implementable than Signal's non-spec https://mail.jabber.org/pipermail/standards/2015-December/030727.html

Tobias: Yah, I'm reading it right now, they've done a good job of documenting it

SamWhited, The concerns with Axolotl are that there is no spec, and the sole implementation is GPL, and the copyright owner seems litiginous about perceived reverse engineering.

and Olm is safe from that?

Yup, and Olm appears to be much better about those things, but I'm nervous that I don't see a license and that changes were made that have not been audited (nor have any of the implementations to my knowledge, though that's potentially not within the scope of the XSF)

that I don't see a license on the spec itself, that is

I think next step here then is contacting Matrix to clear this up?

Would you mind doing that Dave Cridland?

I think that's sensible, yes

I'll add a summary of the arguments (just quoting Dave and my last statements) and an action for Dave to follow up in the notes (assuming he agrees)

AOAOB?

I'll do that, yes.

no AOB here

I think we should deprecate message archiving as discussed on the list, but everyone seems to disagree. Just wanted to bring it up here since it's the councils decision to take a vote or not, I think.

I think the main reservation is that there are implementations of it in the wild, and MAM doesn't replace all its features - and some people may require those features

To me that feels like a strawman argument; those implementations won't stop working because the XSF stops recommending that people use an old protocol which (as far as I can tell) is mostly unused by new implementations

so it depends on what the implications of deprecating it are deemed to be ("never ever implement this" is too strong)

In my mind deprecating it just means new implementations aren't recommended, which seems sensible and the root of the issue (in my mind)

Prosody gained a new implementation of it a year or so ago, I think - as a compatibility layer onto our MAM store

for interop with some clients

And for interop people can continue to implement it

even if it's deprecated

and some folks may just need some of the features it supports that MAM doesn't

That said, I don't feel *strongly*

and they can keep using them (or maybe deprecating it will encourage them to work on MAM and update it to fit their needs)

That's my worst nightmare ;)

Heh, fair enough, I don't know what those features are and we may not accept them (in which case they can keep using message archiving)

MAM explicitly doesn't support some features of the archiving XEP

You all know how I feel though; I feel the same way about this as I do about privacy lists. Having two options is just confusing; we should recommend one and let people use the other if they really need too and know what they're doing.

There is an argument that those features could become new XEPs

I actually maintain a XEP-0136 implementation. I think the right first step is to sort out that compliance XEP such that MAM is the expected archiving solution.

SamWhited, I definitely agree with that - we don't want confusion

For the record, this isn't just theoretical, this came from an issue being opened about someone wanting history and sending a link to message archiving

MattJ how close are we to Draft for MAM?

|<-->| this close

Dave Cridland: I think MAM is the only thing listed in the compliance suites right now; I'll definitely fix that if nto.

I'm actively working on the new revision, just slower than I'd hoped

What remains to be done for MAM? Is there a TL;DR I can stick in the notes?

I'm going to be away in a week or two, so I'm hoping to submit it before that

SamWhited, just put that I need to submit the new revision

Wilco

uses stanza-id, etc.

If it's that soon, lets do the draft feedback for MAM first and then consider deprecating 136?

Makes sense

Sounds good to me

Excellent

thanks all

Lance, thank you

SamWhited, btw: https://github.com/ChatSecure/ChatSecure-iOS/issues/376 also has Axolotl/Signal/Olm discussions you might be interested in

Thaks Lance

Thanks Lance

Dave Cridland: Daniel pointed out on the mailing list that there's a different Olm document than I was looking at which dedicates it to the public domain, so my concern was indeed not valid.

My concern about the spec anyways

ah, it's even in the document I was looking at (probably generated from that rst file), I just didn't see it. It's under "IPR"