XSF Discussion - 2020-04-03

Hmmm anyone knows on top of their mind which clients do, even rudimentarily, support Bits of Binary? ✏

Probably Pidgin

pidgin I think indeed

IIRC Gajim had that as well

poezio?

movim probably

We really need DOAP..

DOAP is dead.

Long live DOAP

what is dead may never die

We do, every client, server or library dev who reads this and hasn’t filled it yet, please send a PR against one of the three JSON files here: https://github.com/xsf/xmpp.org/tree/master/data

Link Mauve, I meant on xmpp.org..

That we actually start using it. Maybe somebody(tm) will manage to fix the thing someday

pep., Pelican wasn’t happy with my use of python3 back then, is this fixed now?

Don't ask me

Link Mauve: I managed to get something with py3 then told you about it

I don't know pelican

Zash, oh, on xmpp.org?

I completely forgot about that. :x

Link Mauve: Build of the xmpp.org website repo in local docker

Without the python2 version like (IIRC) travis is doing?

Link Mauve: No clue about travis. I had this uncommitted in the website repo: http://paste.debian.net/1138215/

on your py3 branh

With a nice multistage build

Nice.

Orrrrrrrrrrrrrrrrrr was the py3 thing something with the xeps?

(the xeps repo is python 3 only, I’m pretty sure of that)

And git wants to merge stuff, why :(

Long time! Damn

I hope everyone is safe! :)

Huhu at google pulling out SOAP over XMPP when searching for DOAP

🤸‍♂️

Google knows you want it

DDG gives me relevant results

It's still a thing? 🙂

I for some reason thought DDG was dead or st ✏

their XMPP service is dead

> their XMPP service is dead I guess that's why then

Does anyone see a problem with restricting MAM retention configuration to a period specified in days?

not off the top of my head

Fine by me

https://xmpp.org/extensions/xep-0004.html#protocol-results - does anyone implement this??

it was a pain, but aioxmpp supports it

and I’m pretty sure that any client implementing XEP-0055 does

Fun

that’s one of the key reasons I rant against '4

What on earth does this mean? > For <iq/> stanzas, the root element qualified by the "wrapper" namespace in a form of type "form" or "submit" MUST be returned in a form of type "result".

-EPARSE

> https://xmpp.org/extensions/xep-0004.html#protocol-results - does anyone implement this?? Meaning 'reported' fields and items? Openfire does.

> For <iq/> stanzas, the root element qualified by the "wrapper" namespace in a form of type "form" or "submit" MUST be returned in a form of type "result". I think that means that your IQ result must have a child element matching the one in the request?

Ah, that would indeed make sense, I think

Some of the semantic hand-waving in XEP-0004 makes life hard to e.g. provide a simple "here's the data" and "here's an update to the data" flow

Similarly weird is how MAM queries use iq type=set

what

iq type=get retrieves the form, iq type=set executes the query

aha

why?

XEP-0004 specifies that, for a start (form submission must always be type=set)

What's wrong with that?

fun

It was also argued by some that this is entirely sensible, since you are performing an action on the server

I ignore that in '433 :)

isn’t retrieving a form also performing an action?

or retrieving the list of MUCs?

Yeah, I don't buy it either

So in a hypothetical form-based MAM preferences thing, if I obeyed XEP-0004 it basically needs two different "wrapper" elements, one for the current preferences and one for making changes

<iq type=get> is supposed to be whatsitcalled, like HTTP GET

not changing state

and a MAM query is indeed not changing state

It's fetching stuff

Myeah, sure

the reverse thing would then be that type=set may change state

Yes

But then everything's state. "Sending the results of the query you just submitted" is a state.

don’t tell that to the REST folks

lollo

avete visto lollo?