XSF Discussion - 2019-12-30

emus can I borrow this? 😃

> emus can I borrow this? 😃 what exactlt? ^^ xD

FYI: https://github.com/xsf/xeps/pull/864

oh, a thing

a thing!

A thing indeed. Might get a couple more out today.

scary

dwd, nice job not escaping '>', although I wonder if I could have resited not having "evenness" (escaping '<' but not '>')

I generally hand-write XML that way. Seems easier to type. :-)

uhh, and the indentation of 'section1' from "Protocol Elements" onwards is off

nice idea to make the namespace definition an entity, I don't think I have seen that before

dwd, it sure is easier to type, but I feel like it causes me a little headache when reading the XML as my brain searches for the closing &gt;, but that is probably just me

I'm hoping it renders OK!

Grumble. I just realised I need to change my email in xeps.ent again...

But anyway, (2): https://github.com/xsf/xeps/pull/865

flow, this continues discussions about ad-hoc JSON handling in libraries that we had some months back.

Sorry, jonas’- lots of work for the Editors today: https://github.com/xsf/xeps/pull/866

I’ll take care of that

I'm on it

oh ok

I was reading the xeps

pep., I can do it too if you’re busy at or around 36c3

ok. I can do other things for sure (always :p)

Thanks

is it just me or does `git fetch origin refs/pull/$prID/head:$branchName` not work anymore? I get fatal: couldn't find remote ref refs/pull/865/head

aaagh

wrong remote

jonas’, pep.- https://github.com/xsf/xeps/pull/867 - This one's tiny, but I'm hoping to get one more out as well.

dwd, so after #867, we have to expect one more?

if so, what’s the ETA?

does it make sense to wait for it to batch the docker build?

Yeah. Aiming to document a standards-based (and fastening-aware) variant of https://mongooseim.readthedocs.io/en/latest/modules/mod_inbox/ - but you can kick off builds as you see fit. I don't know I'll get this one done today anyway.

okay

then just the three

dwd, all done

Speedy! I'll have to write more...

Makes me a bad conscience re 0401

Almost got Inbox ready, but I think I'll spend another day to make it less ProtoProtoXEP.

dave motioning to nuke OMEMO -- interesting :)

dwd, for me not to miss your agendum it’s probably good if you CC me

if you want to make this a vote right away

https://github.com/xsf/xeps/pull/870 is for marc

jonas’, rejecting the current omemo xep is probably not the same as nuking omemo. The way I see it, an updated version which builds on the open double ratched standard could get the omemo xep into experimental again

flow, which was promised years back when it was accepted into Experimental state?

I don’t believe this is going to happen due to the lack of action to this point.

Rejecting the current OMEMO XEP is not an attempt to nuke OMEMO. It's just saying that the XSF isn't the place to work on something that isn't an open standard, and doesn't claim to be.

jonas’, I am not sure if it was promised, but a first step was at least tried in https://github.com/xsf/xeps/pull/460/files

Also everybody is using the siacs namespace. Everybody expect the fork developers who did a global search & replace.

jonas’, I am also not sure if you can infer the future from the current and past "lack of action"

past performance is still the best predictor for future behaviour

the small sprint of every stock chart would disagree with that

*print

being the best predictor does not mean it’s a good predictor tho

flow, XEP-0384 doesn't conform to our criteria for an open standard. I'm not interested in either the future or the past, but the present.

dwd but what does that mean for a crypto spec that is not a standard

does the XEP has to specify the whole thing

lovetox, no, but it should ideally be able to point to an open standard

Specify it, or reference it. Not sure why OMEMO gets a pass here, nothing else has.

IMHO it was fine while the axolotl protocl was just a github wikipage which some magic numbers

i think back then there was nothing published

Right, which was why it was originally rejected.

but after the double ratched was made an open standard, there is really no reason why we should build omemo on top of that

basically its a wrapper for XMPP around the openwhistersystem libs

lovetox, Sure. And so was the RTMP spec, and we rejected that for that reason.

Not to say you can't do OMEMO, or RTMP. But the XSF isn't the place for them.

dwd, im not arguing against rejection, i just wanted to get some insight how the new XEP would have to look like

there is a new XEP planned anyway

there was month of discussion about the current xep on the list

if you remember

The basic criteria is that anyone should be able to take the specification and implement the protocol from that and any references. Any dependent specifications should be at least as stable and open as ours.

i think for the crypto stuff references could be added now

but the real problem was the protobuf wire protocol

which is under GPL

so people argued its impossible to implement it in their not GPL projects

for one moment assuming that's true, so what?

why should I or anyone else care whether non-GPL software can implement a XEP

that sounds like a "your problem" not a "my problem"

this rules out many clients

moparisthebest, No, it means that the specificaiton isn't open.

and we strive to make protocols that everybody can implement

GPL isn't open ?

moparisthebest, We don't mandate any license for software implementing our specs. Why should we?

just seems to me like a lot of whining "well I have to do a ton of work to implement this in non-GPL software" tough, don't pick shitty licenses for your software then?

moparisthebest, "A ton of work" is absolutely fine. If it's impossible, that's a whole other problem.

moparisthebest, Also, note that most of the XMPP clients and servers aren't GPL. Could be that people disagree that anything other than GPL is shitty.

I am not sure if discussing GPL being free or not is the discussion we should have. The question is: Do we want XEPs the require implementation to be under a certain license

I wouldn't oppose that FWIW, but I feel like others would disagree

moparisthebest, Or, to put it another way, what makes mandating the GPL for a particular specification different from mandating any other license?

And I wonder what we have actually written down regarding that

or if it's just a grey area within the XSF and XEPs process

flow, We mandate that our specifications must be implementable by an OSI-approved implementation in order to reach Final.

flow, In general, Council has taken that to mean that if that's precluded, we should reject the XEP (or ProtoXEP) early.

I don't think a XEP can actually mandate code licenses, the complaints I tend to see are usually complaints about there only being a single GPL impl so far

dwd isn't the gpl osi-approved?

moparisthebest: the main complaint is probably that the only specification is a GPL source code

moparisthebest, OK. From the XEP, how would I go about writing a non-GPL one? There's no references, no spec, etc.

Fwiw - as one of the people who pushed for omemo a couple of years ago - I'm fine with rejecting it

It's not a good standard

dwd, clean room reverse the implementation? :)

again, the how is a "you problem" not a "me problem"

moparisthebest, SO you agree there's no specification then?

I'm just speaking in general

moparisthebest, OK, but the same argument applies to both STANAG 5066 and RTMP. One *can* (now) get a copy of STANAG 5066 and write an implementation, and it's a huge job, but possible. To write one from scratch for OMEMO requires information not in, or pointed too by, XEP-0384.

moparisthebest, But for RTMP, you'd need to clean-room Adobe's library. You might get sued by Adobe for doing so. Maybe that is (or was) possible. Is that a "your problem" and not an "our problem" too?

I think so

moparisthebest, OK, so your argument is that we should accept XEPs that depend on closed-source libraries. That is consistent, at least, but I'll disagree strongly.

Accept as draft right? They can't reach final without a open implementation I guess

There is no similar "must have a closed source implementation" clause

I also disagree with having XEPs that require reverse engineering

Oh, I tell a lie. We don't require either implementation to be open source.

Oh, yes, we do. FOund it - it's a little buried. We stipulate at least one should be GPL/LGPL or OSI.

Still, I think the intent there was to ensure that we didn't preclude open-source imeplementations, not that we mandated them.

I guess I'm saying I don't see anything where the xsf should evaluate the license and or patent implications of a xep

We require open source implementation to move to final and that's it

So rtmp for instance, ok for draft, then if someone reverses the library and makes an open source impl, it can be moved to final, otherwise it can't

OK. My view is firmly that we shouldn't devote time and effort to something we know cannot reach Final.

I don't think anyone here is qualified to judge license/patent implications world wide anyway, why even try?

moparisthebest: luckily, some of us live in regions where you can't patent code

right, so say a XEP can't be implemented in the USA for patent reasons, but it can be in Germany, should the XSF reject or accept it?

moparisthebest: I'm pretty sure you can't implement a chat app without violating a dozen of trivial software patents. That said, tracing patents is the opposite to checking for the existence of documentation for all parts of a XEP

moparisthebest, re " usually complaints about there only being a single GPL impl so far": no, there’s also the argument that you need data and code which is licensed under GPL to implement it. And since some of that is pretty unique to the implementation *and* there’s no spec to go by, any re-implementation of Signal is automatically a derivative of the GPL’d library, and thus, under GPL. or so the argument goes. ✏

in fact, there has been a non-GPL implementation in pure python which converted to GPL for that reason

https://github.com/Syndace/python-omemo though it claims it'll "soon" switch to MIT, I’m pretty sure it was non-GPL in the beginning and switched over to GPL at a later point; though that might’ve been before publication.

Syndace might be able to give more details and confirm or reject my memory.

jonas’, its because of the wire protocol

its not published, so the only way to reimplement it is to look directly at signals code

lovetox, that’s exactly what I said

or tried to say at least

but i think he factored the protobuf stuff out into a own python package

ah, so that’d make sense why it can become MIT

https://github.com/Syndace/python-omemo-backend-signal

Luckily, moxie is well known to be welcoming of alternative implementations and forks

luckily

Looking at the gpl code isn't the only way

That's what clean room reversing is for

Though I'd agree the xep should document it

moparisthebest, how’d you do that? look at what happens on the wire and reverse engineer that?

you might be violating the ToS of Signal with that, and if you don’t, the GPL may have a word of that and it’d still be a derivative of GPL’d code in some way.

in any case, it’s not something I’d like to try in court

looks like a grey area where the one with the better lawyer wins the case, especially in jury-land

jonas’, https://en.wikipedia.org/wiki/Clean_room_design

anyway I don't think the XSF should concern itself with how various implementations might fare in court

Ge0rG: thanks, feel free to ping me again in a couple of days, I'm still at the Congress

marc: your OK is required to merge that pr

Ge0rG: I know, that's why I said what I said :)

marc: well, I'll have to wait then. thanks :)

jonas’, lovetox: your assumptions/memories are correct. I published the library as MIT first and later switched to GPL, because it is a derivative work. I even modified the git history, so that there is no wrongly licensed code in older commits. I then split the "generic" OMEMO code and the signal-specific code, so that I can publish the generic code under MIT, which is what I mean by "switching soon".

And sadly it is not only the wire format, even though that's like 90% of it.

Ge0rG: how can I put my OK?

I need a rendered version :)

I'm on mobile

marc: https://op-co.de/tmp/xep-0401.html at your service. Significant changes in §3 (last example), and §5.5

Ge0rG: is this 'sending an arbitrary iq' normal in XMPP?

I would argue than something sent before resource binding should not be considered a stanza, much less an iq stanza, for security reasons.

Zash: I would argue that what I've moved forward with, ignoring your advice, is not too ugly and sufficiently workable

Ugly hacks do usually work, or there would be no point.

yes