XSF Discussion - 2019-11-04

After having written a Council application, and subsequently reading the other applicants’, I am hereby not applying this year.

I think there are much needed ideas in there, and will be happy to see how they pan out. :)

oh wow

a pep

I am amazed, this is going to be a fun election

Especially with multiple candidates running for both, this guarantees some i interesting vote dynamics. Will we need a second round?

> Link Mauve: Existing thing already using gloox? I'm starting to use and try to understand gloox. ✏

jonas’ [08:58]: > /me reacts with 👍 /me slaps jonas’ with a large trout

Is gloox still maintained? (as opposed to Swiften)

Ah, looks like it is, yes.

Kev, Swiften is not maintained any more?

Swiften is. I thought Gloox wasn't, but it is.

ahh, got it

I think there is just one developer. So, I will try to have a look into the code. Maybe I can help 🤷‍♂️

debxwoody, ah sure, so I pushed my (WIP, still segfaulting) code to https://github.com/linkmauve/bonzomatic/tree/xmpp

I might move to Swiften eventually, nothing is set so far.

I also don’t implement the Jingle part of SXE yet.

segfaulting XMPP client. What could go wrong?

Also once it doesn’t segfault anymore, I will probably upstream the SXE StanzaExtension so that other people can benefit from it, even if I end up not using gloox.

Ge0rG, segfaulting text editor, even worse.

Everybody knows that text editors are turing-complete and you MUST NOT open untrusted documents in them

Well, this one is a bit special, it compiles and executes the code the user is typing directly as its background.

It’s completely at the mercy of the OpenGL driver for proper behaviour.

The things that my imagination draws up in the intersection of XMPP, OpenGL and text editing are... weird

^^

I like mine too. :)

Oh, bonzomatic!

It didn't run on my machine 😞

Zash, it previously was in my plans to lower its OpenGL version for it to run on my netbook, before said netbook stopped booting altogether…

But there is no reason for it not to be able to target e.g. OpenGL 3.3 for snb users.

Hm, that was before I bought my new laptop, maybe it works there

Which OpenGL version do you have? It expects at least 4.1.

I guess because Apple will never go higher than that.

Hey Link Mauve! Is that a collaborative editor? I was looking for an editor to do "pair-programming" sessions. I found Atom + Github, but that requires Github stuff

vscode's sharing stuff for pairing is actually excellent.

The what now?

Zash: @me?

sharing is ~caring~ pairing?

( https://marketplace.visualstudio.com/items?itemName=MS-vsliveshare.vsliveshare was what I was talking about )

Kev: Yeah, I haven't seen anything like that in vscode. Plugin or whatsitcalled?

Cool

I typically use it by having an external video call on at the same time as a live share just for the code/terminal/debuggerer, although I believe it does have inbuilt audio stuff in a sister extension if you prefer.

Seve, https://www.saros-project.org/

Seve, it’s not, I’m making it into one.

(Sorry, had breakfast with my sister.)

flow: that's only with eclipse?

flow, larma, https://github.com/linkmauve/xeps/tree/xep-0234 contains some changes to fix Jingle-FT which imo will require a namespace bump. My plan is to then request a Last Call.

Link Mauve, already tracked/noted at https://wiki.xmpp.org/web/XEP-Remarks/XEP-0234:_Jingle_File_Transfer. Although I didn't see a specific change which would require a namespace bump, but I didn't had a close look

pep., there is also an intelliJ plugin IIRC

flow, Kev thanks for sharing

Seve, of course there is also gobby

https://github.com/gobby

flow, the main breaking change is in the current version, the addition of <hash-used/> and making it mandatory.

flow, sadly unmaintained. :(

Link Mauve, what is your motivation? (I did not know that tool but it is great if you are adding support for that :D)

But it may be a good base to build on top of SXE, I haven’t looked into that yet.

IIRC the wire protocol of gobby is also unspecified

Seve, writing shaders together with a friend. ^^

I once tried to compare it with SXE

Link Mauve, super!

Kev, do you happen to know which protocol they are using? Also the license isn’t one I recognise, and they don’t seem to publish the extension itself in their repository, only some documentation and code samples.

So I guess it is non-free?

https://marketplace.visualstudio.com/items/MS-vsliveshare.vsliveshare/license Doesn't read like an open source license to me

Yeah.

So not really usable for the purpose of writing a compatible text editor.

Link Mauve, I honestly don't see why your changes require a namespace bump. This is just clarifications IMO

Or "fixes" of where the XEP was inconsistent

"Clarification" :(

larma, problem is, if there previously were two ways to interpret a text, and there’s now only one, the two versions are not always interoperable

Can a thing following the previous version talk to a thing following the new version?

jonas’, in this case they are and it's not even a big deal

From the current XEP 234: > Either a <hash/> or a <hash-used/> element MUST be included when offering a file. [...] One or more <hash/> elements MUST be present when offering a file, but those elements MAY be empty if the hash has not yet been computed. [...] At any time during the lifetime of the file transfer session, the File Sender can communicate the checksum of the file to the File Receiver. This can be done in the session-initiate message [...] After the session-initiate message, this can also be done [...] In such a case however, the session-initiate message MUST contain a <hash-used/> element.

So according to current XEP the only strictly correct implementation by the text of the XEP of providing the hash later is to have both empty <hash/> and <hash-used/> which obviously makes little sense. The only example covering this usecase, Example 16, only has <hash-used/> and no empty <hash/>. To me it's obvious that the "One or more <hash/> elements MUST be present when offering a file, but those elements MAY be empty" is an artifact from before <hash-used/> was introduced. I don't see why clarifying this needs a namespace bump. As a side note: the introduction of <hash-used /> in 0.18.3 didn't bump the namespace

"have both empty <hash/> and <hash-used/>" -> "have both empty <hash/> and <hash-used/> in session-initiate"

Yep, that potentially could go without a namespace bump (if there are no other changes)

Although I am happy to hear if someone wants to argue why one is required…

larma, it’s not strictly about my changes, the namespace bump should have happened in 0.18.3 which introduced a new <hash-used/> element and made it a MUST where previously only <hash/> was to be there: “Either a <hash/> or a <hash-used/> element MUST be included when offering a file.”

Thus making it incompatible with previous clients which were requiring a <hash/>.

"previous clients requiring a <hash/>" = none?

I guess we could also waive it as an incompatible change made to an experimental XEP and not bump anything.

I haven’t done a field study about that, but I had an implementation (not used in any public client) which was doing that.

Clients following a version from before 0.18.3 will entirely ignore <hash-used/> as it wasn’t a thing back then, so these MUST can’t be followed by them.

I agree. But versions before 0.18.3 are not XEP compliant anymore and Experimental XEPs don't provide any notion of backwards compatibility to their previous versions.

Ok, then perfect. :)

Also, afaik both Dino and Conversations don't send hash/hash-used in session-initiate at all...

In case you are wondering, there is also good reason for that: When the file is encrypted using JET, the hash would be the *real* hash of the file, so this would leak information on the file contents to any MITM, which isn't really desirable

So if you wanted to update that, you could change the requirement of hash/hash-used to SHOULD with a note on that 😉

So it should be made optional?

Well it could also be considered in issue of JET

Or the acutal issue is that we don't have full stanza encryption 😉

Or of not using full-stanza encryption for Jingle too.

.

BTW, I added this table https://wiki.xmpp.org/web/XEP-Remarks/XEP-0234:_Jingle_File_Transfer#Current_implementations_checksum_behavior

great list of application for the next board & council

!

Thanks, Alex! :)

this’ll be a tough vote

Memberbot is online

o/

pep: thanks for the latest editor push :)

Sorry it took some time