-
edhelas
emus can I borrow this? 😃
-
emus
> emus can I borrow this? 😃 what exactlt? ^^ xD
-
dwd
FYI: https://github.com/xsf/xeps/pull/864
-
jonas’
oh, a thing
-
Zash
a thing!
-
dwd
A thing indeed. Might get a couple more out today.
-
jonas’
scary
-
flow
dwd, nice job not escaping '>', although I wonder if I could have resited not having "evenness" (escaping '<' but not '>')
-
dwd
I generally hand-write XML that way. Seems easier to type. :-)
-
flow
uhh, and the indentation of 'section1' from "Protocol Elements" onwards is off
-
flow
nice idea to make the namespace definition an entity, I don't think I have seen that before
-
flow
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 >, but that is probably just me
-
dwd
I'm hoping it renders OK!
-
dwd
Grumble. I just realised I need to change my email in xeps.ent again...
-
dwd
But anyway, (2): https://github.com/xsf/xeps/pull/865
-
dwd
flow, this continues discussions about ad-hoc JSON handling in libraries that we had some months back.
-
dwd
Sorry, jonas’- lots of work for the Editors today: https://github.com/xsf/xeps/pull/866
-
jonas’
I’ll take care of that
-
pep.
I'm on it
-
jonas’
oh ok
-
pep.
I was reading the xeps
-
jonas’
pep., I can do it too if you’re busy at or around 36c3
-
pep.
ok. I can do other things for sure (always :p)
-
pep.
Thanks
-
jonas’
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
-
jonas’
aaagh
-
jonas’
wrong remote
-
dwd
jonas’, pep.- https://github.com/xsf/xeps/pull/867 - This one's tiny, but I'm hoping to get one more out as well.
-
jonas’
dwd, so after #867, we have to expect one more?
-
jonas’
if so, what’s the ETA?
-
jonas’
does it make sense to wait for it to batch the docker build?
-
dwd
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.
-
jonas’
okay
-
jonas’
then just the three
-
jonas’
dwd, all done
-
dwd
Speedy! I'll have to write more...
-
Ge0rG
Makes me a bad conscience re 0401
-
dwd
Almost got Inbox ready, but I think I'll spend another day to make it less ProtoProtoXEP.
-
jonas’
dave motioning to nuke OMEMO -- interesting :)
-
jonas’
dwd, for me not to miss your agendum it’s probably good if you CC me
-
jonas’
if you want to make this a vote right away
-
Ge0rG
https://github.com/xsf/xeps/pull/870 is for marc
-
flow
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
-
jonas’
flow, which was promised years back when it was accepted into Experimental state?
-
jonas’
I don’t believe this is going to happen due to the lack of action to this point.
-
dwd
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.
-
flow
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
-
Ge0rG
Also everybody is using the siacs namespace. Everybody expect the fork developers who did a global search & replace.
-
flow
jonas’, I am also not sure if you can infer the future from the current and past "lack of action"
-
jonas’
past performance is still the best predictor for future behaviour
-
flow
the small sprint of every stock chart would disagree with that
-
flow
*print
-
jonas’
being the best predictor does not mean it’s a good predictor tho
-
dwd
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.
-
lovetox
dwd but what does that mean for a crypto spec that is not a standard
-
lovetox
does the XEP has to specify the whole thing
-
flow
lovetox, no, but it should ideally be able to point to an open standard
-
dwd
Specify it, or reference it. Not sure why OMEMO gets a pass here, nothing else has.
-
flow
IMHO it was fine while the axolotl protocl was just a github wikipage which some magic numbers
-
lovetox
i think back then there was nothing published
-
dwd
Right, which was why it was originally rejected.
-
flow
but after the double ratched was made an open standard, there is really no reason why we should build omemo on top of that
-
lovetox
basically its a wrapper for XMPP around the openwhistersystem libs
-
dwd
lovetox, Sure. And so was the RTMP spec, and we rejected that for that reason.
-
dwd
Not to say you can't do OMEMO, or RTMP. But the XSF isn't the place for them.
-
lovetox
dwd, im not arguing against rejection, i just wanted to get some insight how the new XEP would have to look like
-
lovetox
there is a new XEP planned anyway
-
lovetox
there was month of discussion about the current xep on the list
-
lovetox
if you remember
-
dwd
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.
-
lovetox
i think for the crypto stuff references could be added now
-
lovetox
but the real problem was the protobuf wire protocol
-
lovetox
which is under GPL
-
lovetox
so people argued its impossible to implement it in their not GPL projects
-
moparisthebest
for one moment assuming that's true, so what?
-
moparisthebest
why should I or anyone else care whether non-GPL software can implement a XEP
-
moparisthebest
that sounds like a "your problem" not a "my problem"
-
lovetox
this rules out many clients
-
dwd
moparisthebest, No, it means that the specificaiton isn't open.
-
lovetox
and we strive to make protocols that everybody can implement
-
moparisthebest
GPL isn't open ?
-
dwd
moparisthebest, We don't mandate any license for software implementing our specs. Why should we?
-
moparisthebest
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?
-
dwd
moparisthebest, "A ton of work" is absolutely fine. If it's impossible, that's a whole other problem.
-
dwd
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.
-
flow
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
-
flow
I wouldn't oppose that FWIW, but I feel like others would disagree
-
dwd
moparisthebest, Or, to put it another way, what makes mandating the GPL for a particular specification different from mandating any other license?
-
flow
And I wonder what we have actually written down regarding that
-
flow
or if it's just a grey area within the XSF and XEPs process
-
dwd
flow, We mandate that our specifications must be implementable by an OSI-approved implementation in order to reach Final.
-
dwd
flow, In general, Council has taken that to mean that if that's precluded, we should reject the XEP (or ProtoXEP) early.
-
moparisthebest
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
-
flow
dwd isn't the gpl osi-approved?
-
Ge0rG
moparisthebest: the main complaint is probably that the only specification is a GPL source code
-
dwd
moparisthebest, OK. From the XEP, how would I go about writing a non-GPL one? There's no references, no spec, etc.
-
Daniel
Fwiw - as one of the people who pushed for omemo a couple of years ago - I'm fine with rejecting it
-
Daniel
It's not a good standard
-
moparisthebest
dwd, clean room reverse the implementation? :)
-
moparisthebest
again, the how is a "you problem" not a "me problem"
-
dwd
moparisthebest, SO you agree there's no specification then?
-
moparisthebest
I'm just speaking in general
-
dwd
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.
-
dwd
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?
-
moparisthebest
I think so
-
dwd
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.
-
moparisthebest
Accept as draft right? They can't reach final without a open implementation I guess
-
moparisthebest
There is no similar "must have a closed source implementation" clause
-
Ge0rG
I also disagree with having XEPs that require reverse engineering
-
dwd
Oh, I tell a lie. We don't require either implementation to be open source.
-
dwd
Oh, yes, we do. FOund it - it's a little buried. We stipulate at least one should be GPL/LGPL or OSI.
-
dwd
Still, I think the intent there was to ensure that we didn't preclude open-source imeplementations, not that we mandated them.
-
moparisthebest
I guess I'm saying I don't see anything where the xsf should evaluate the license and or patent implications of a xep
-
moparisthebest
We require open source implementation to move to final and that's it
-
moparisthebest
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
-
dwd
OK. My view is firmly that we shouldn't devote time and effort to something we know cannot reach Final.
-
moparisthebest
I don't think anyone here is qualified to judge license/patent implications world wide anyway, why even try?
-
Ge0rG
moparisthebest: luckily, some of us live in regions where you can't patent code
-
moparisthebest
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?
-
Ge0rG
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
-
jonas’
moparisthebest, 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.✎ -
jonas’
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. ✏
-
jonas’
in fact, there has been a non-GPL implementation in pure python which converted to GPL for that reason
-
jonas’
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.
-
jonas’
Syndace might be able to give more details and confirm or reject my memory.
-
lovetox
jonas’, its because of the wire protocol
-
lovetox
its not published, so the only way to reimplement it is to look directly at signals code
-
jonas’
lovetox, that’s exactly what I said
-
jonas’
or tried to say at least
-
lovetox
but i think he factored the protobuf stuff out into a own python package
-
jonas’
ah, so that’d make sense why it can become MIT
-
lovetox
https://github.com/Syndace/python-omemo-backend-signal
-
Ge0rG
Luckily, moxie is well known to be welcoming of alternative implementations and forks
-
jonas’
luckily
-
moparisthebest
Looking at the gpl code isn't the only way
-
moparisthebest
That's what clean room reversing is for
-
moparisthebest
Though I'd agree the xep should document it
-
jonas’
moparisthebest, how’d you do that? look at what happens on the wire and reverse engineer that?
-
jonas’
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.
-
jonas’
in any case, it’s not something I’d like to try in court
-
jonas’
looks like a grey area where the one with the better lawyer wins the case, especially in jury-land
-
moparisthebest
jonas’, https://en.wikipedia.org/wiki/Clean_room_design
-
moparisthebest
anyway I don't think the XSF should concern itself with how various implementations might fare in court
-
marc
Ge0rG: thanks, feel free to ping me again in a couple of days, I'm still at the Congress
-
Ge0rG
marc: your OK is required to merge that pr
-
marc
Ge0rG: I know, that's why I said what I said :)
-
Ge0rG
marc: well, I'll have to wait then. thanks :)
-
Syndace
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".
-
Syndace
And sadly it is not only the wire format, even though that's like 90% of it.
-
marc
Ge0rG: how can I put my OK?
-
marc
I need a rendered version :)
-
marc
I'm on mobile
-
Ge0rG
marc: https://op-co.de/tmp/xep-0401.html at your service. Significant changes in §3 (last example), and §5.5
-
marc
Ge0rG: is this 'sending an arbitrary iq' normal in XMPP?
-
Zash
I would argue than something sent before resource binding should not be considered a stanza, much less an iq stanza, for security reasons.
-
Ge0rG
Zash: I would argue that what I've moved forward with, ignoring your advice, is not too ugly and sufficiently workable
-
Zash
Ugly hacks do usually work, or there would be no point.
-
Ge0rG
yes