XSF Discussion - 2021-09-29

Did anyone have a look at https://xmpp.org/extensions/xep-0459.html#future to see what should be promoted?

jonas’: CS'22 links to inbox/ibr-token instead of xep-0445. That's a minor editorial change, do you want to get a PR?

I like PRs

anything to add in the revision history, or just the content itself?

Not sure how many other Council members are still pending their vote for advancement

General unexperience question: Why do we always make it a new XEP? why not update the existing one each year? So referencing would be easier?

previous states could be archived somehow?

emus: because archiving old version of XEPs is hard.

emus: we have this discussion every year, and the TLDR is: we have a process for XEPs, so we use that process even if it's not perfectly suitable for CS, but making a new process for CS would be harder

Ah ok, sorry. Did not knew it. Agreed

marc: would you be opposed to issuing a Last Call on XEP-0401?

The fiscal host blog post was merged a few days ago, but it never showed up. Is the website broken?

(or something about the post maybe?)

someone needs to poke it manually currently because of docker/travis changes

Does it work locally?

Did someone poke iteam about deploying?

Seems to work locally

I'll deploy the website now

Thanks

Done

jonas’: https://github.com/xsf/xeps/pull/1110

Holger: does ejabberd implement any of XEP-0379, XEP-0401 and XEP-445?

Ge0rG, no.

Holger: do you have plans to?

I had a go at understanding this stuff just a few days ago (thanks to MattJ for explaining things). So if I got things right, marc's idea was to consume tokens based on XEP-0389 (in order to solve other problems, such as password recovery, in the same go). He has a patch for that. I take it you guys were unhappy with the '389 approach and went for '445 instead. AFAICS I'd mostly have to throw away his patch and start from scratch to go that route 😕

I might do that, but not right now.

Holger: I wasn't unhappy with 0389, I was not expecting anybody to implement it any time soon

Same here (I was just typing that)

🤷‍♂️️ whatever.

Just saying I think we have 0 lines of "Snikket code" right now (while I was wrongly assuming we did, before) ...

Holger: XEP-445 is an alternative mechanism to 0389, so you could have clients use either.

Yeah.

I'm not complaining about anything, mind 🙂

You don't even have the ad-hoc commands?

No.

(Unrelated to '389 vs. '445, I know. I just had wrong assumptions about the state of affairs 🙂)

np

Now is XMPP has received funds?

It's probably not rocket science, but does require a bit of thought, esp. the failure paths (token valid, registration fails and whatnot) with different DB backends.

But I see there's quite some interest and I do have some motivation to give into that demand, eventually 🙂 I see how the functionality can be nice to have.

bung: what

https://xmpp.org/2021/09/the-xsf-as-a-fiscal-host/

OH SORRY

> If the <field/> element type is anything other than "fixed" (see below), it MUST possess a 'var' attribute that uniquely identifies the field in the context of the form (if it is "fixed", it MAY possess a 'var' attribute). So the recent disco#info result on this room was a protocol violation indeed

General Compliance suite ramble: we have like 2ish clients that kinda come close to implement it completely. If we keep moving the goal post we will never have more clients that actually implement the whole thing

Ge0rG: what was changed in 401?

Daniel: the document could also be used by third parties creating a proprietary client, as a guideline to 'how to do sensible things with XMPP' - but otherwise, yes, not having public clients that adhere to it is not ideal.

marc: nothing, it should just get advanced from Deferred to Stable. But I'm looking at it and see things that got moved into 0445, so looks like my last PR wasn't merged?!

Then again: most of the developers that I'm talking to tend to read up on the documentation of the API of whatever library that they're using, and not-so-much XEPs. Sadly.

Daniel: what's your proposal?

So should I again mention that maybe there should be two documents, one "current best practices" and one "future vision"? ✏

Yes please mention that again.

"that", again 🙂

I'm not up-to-date, sorry

ba-dum tissshhh

Nothing I'm just rambling. But maybe some form of stablilty. We started to have annual compliance suits but this somehow seems to put us under the pressure to put something new in every year

However there is also value in being a bit more stable with the list of xeps

I guess that's what I'm saying. Just thinking out loud really

Are we adding XEPs to the new compliance suits that didn't exist in the year before?

We didn't, unless something happens at the last minute

chat isn't that new. You'd think that the set of functionality that's deemed "sensible" does not change much year over year.

There's only a single change between 2021 and 2022, in that XEP-0156 is now required

Zash: I proposed more changes just a few minutes ago

Also we do have a "Future Developments" section that developers can use to look for exciting new things, and I'd normally not suggest bypassing that for new XEPs

The exception is 0441 which was already part of 0313 before

Some notable 0313 history... https://github.com/xsf/xeps/pull/547

Can we get into our time machine and just merge that change back in 2017 please?

marc: history of my proposed changes is https://github.com/xsf/xeps/pull/874

(looks like it got lost in gitlab)

I have proposed in the past, I Think, that we have a document that defines what we think is needed to implement a decent client/server, and we version it rather than year it.

I promise that once we have MUC-PAM you want mam to store groupchats

Daniel: yes, and that will be defined in the MUC-PAM XEP and not be part of 0313

Daniel: even if we made 0313 say "MUST NOT store groupchat", a later spec could easily override that

On the other hand, making servers store groupchat without a clear way to query for that data or a clear use case is not a sign of a good protocol design

But I sound like a broken record again.

Ge0rG: querying or filtering errors is a thing one might think about

Zash: is anyone even storing errors?

Prosody (trunk)

FWIW, I’d be fine with not advancing MAM and leaving it until we’ve sorted all the XMPP2 type decisions we need to make, but I understand the desire to advance it given its wide use.

Kev: given its wide use, advancing it is obviously not solving any problems beyond Council and the XSF looking incompetent about our process.

If we're not going to advance stuff in wide use, I question the entire process :)

MattJ: but wouldn't it make sense to compare what we advance with what's actually implemented?

Ge0rG, I thought the new version of 401 referers to the new XEP that defines "your IBR" approach? I don't see this reference

marc: yes, that PR was never merged

Why is that?

marc: I think it's because I used gitlab and because we have too few editors

Okay, because that would be necessary before we can move 401 to stable IMO

marc: I agree with that. Would you want a Last Call after https://gitlab.com/xsf/xeps/-/merge_requests/33 is merged?

Yep

jonas’: ⬆️ would you like to get a github PR of that tomorrow?

Ge0rG, yes