Did anyone have a look at https://xmpp.org/extensions/xep-0459.html#future to see what should be promoted?
belonghas left
Ge0rG
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?
Alexhas left
jonas’
I like PRs
Ge0rG
anything to add in the revision history, or just the content itself?
Ge0rG
Not sure how many other Council members are still pending their vote for advancement
emus
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?
emus
previous states could be archived somehow?
Ge0rG
emus: because archiving old version of XEPs is hard.
millesimushas left
Ge0rG
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
sonnyhas left
sonnyhas joined
Alexhas joined
Alexhas left
Alexhas joined
georgeorwellhas joined
emus
Ah ok, sorry. Did not knew it.
Agreed
mjkhas left
malthehas joined
mjkhas joined
belonghas joined
Guushas joined
sonnyhas left
archas left
archas joined
archas left
archas joined
sonnyhas joined
archas left
archas joined
Wojtekhas joined
archas left
archas joined
archas left
millesimushas joined
archas joined
sonnyhas left
sonnyhas joined
archas left
archas joined
archas left
archas joined
archas left
archas joined
lorddavidiiihas left
archas left
archas joined
archas left
archas joined
archas left
archas joined
millesimushas left
archas left
archas joined
archas left
archas joined
kyemxdenhas joined
archas left
archas joined
lorddavidiiihas joined
belonghas left
chronosx88has left
chronosx88has joined
archas left
archas joined
archas left
archas joined
archas left
archas joined
archas left
archas joined
millesimushas joined
archas left
archas joined
archas left
archas joined
belonghas joined
archas left
Ge0rG
marc: would you be opposed to issuing a Last Call on XEP-0401?
archas joined
Sam
The fiscal host blog post was merged a few days ago, but it never showed up. Is the website broken?
Sam
(or something about the post maybe?)
jonas’
someone needs to poke it manually currently because of docker/travis changes
Zash
Does it work locally?
Zash
Did someone poke iteam about deploying?
Sam
Seems to work locally
archas left
archas joined
archas left
archas joined
antranigvhas left
antranigvhas joined
MattJ
I'll deploy the website now
Sam
Thanks
archas left
archas joined
MattJ
Done
archas left
archas joined
archas left
archas joined
archas left
archas joined
archas left
archas joined
Ge0rG
jonas’: https://github.com/xsf/xeps/pull/1110
Ge0rG
Holger: does ejabberd implement any of XEP-0379, XEP-0401 and XEP-445?
archas left
archas joined
archas left
archas joined
Holger
Ge0rG, no.
beanhas left
archas left
archas joined
Ge0rG
Holger: do you have plans to?
archas left
archas joined
phrykhas left
archas left
archas joined
antranigvhas left
archas left
archas joined
Holger
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 😕
Holger
I might do that, but not right now.
archas left
archas joined
Ge0rG
Holger: I wasn't unhappy with 0389, I was not expecting anybody to implement it any time soon
MattJ
Same here (I was just typing that)
Holger
🤷♂️️ whatever.
archas left
archas joined
archas left
archas joined
Holger
Just saying I think we have 0 lines of "Snikket code" right now (while I was wrongly assuming we did, before) ...
Ge0rG
Holger: XEP-445 is an alternative mechanism to 0389, so you could have clients use either.
Holger
Yeah.
Holger
I'm not complaining about anything, mind 🙂
MattJ
You don't even have the ad-hoc commands?
archas left
archas joined
Holger
No.
archas left
Holger
(Unrelated to '389 vs. '445, I know. I just had wrong assumptions about the state of affairs 🙂)
archas joined
COM8has joined
MattJ
np
babacbhas left
babacbhas joined
jgarthas joined
COM8has left
bung
Now is XMPP has received funds?
archas left
archas joined
Holger
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.
archas left
Yagizahas left
Yagizahas joined
archas joined
Holger
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.
> 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
intosihas joined
marchas joined
belonghas joined
ti_gj06has left
xsfhas left
xsfhas joined
marchas left
marchas joined
nycohas left
nycohas joined
marchas left
marchas joined
marchas left
archas left
archas joined
archas left
archas joined
archas left
archas joined
marchas joined
archas left
archas joined
archas left
archas joined
archas left
archas joined
malthehas left
archas left
archas joined
intosihas left
intosihas joined
marc0shas left
marc0shas joined
marc0shas left
marc0shas joined
pjnhas left
pjnhas joined
alacerhas joined
emushas left
antranigvhas joined
antranigvhas left
antranigvhas joined
Daniel
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
marc
Ge0rG: what was changed in 401?
marchas left
Guus
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.
alacerhas left
alacerhas joined
Ge0rG
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?!
antranigvhas left
Guus
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.
Ge0rG
Daniel: what's your proposal?
Zash
So should I again mention that maybe there should be two documents, one "current best practices" and one "future vision"q✎
Zash
So should I again mention that maybe there should be two documents, one "current best practices" and one "future vision"? ✏
ti_gj06has joined
Guus
Yes please mention that again.
Zash
"that", again 🙂
archas left
archas joined
soundconcepthas left
soundconcepthas joined
marchas joined
marc
I'm not up-to-date, sorry
Guus
ba-dum tissshhh
Daniel
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
archas left
archas joined
Daniel
However there is also value in being a bit more stable with the list of xeps
Daniel
I guess that's what I'm saying. Just thinking out loud really
Guus
Are we adding XEPs to the new compliance suits that didn't exist in the year before?
Zash
We didn't, unless something happens at the last minute
Guus
chat isn't that new. You'd think that the set of functionality that's deemed "sensible" does not change much year over year.
Zash
There's only a single change between 2021 and 2022, in that XEP-0156 is now required
archas left
archas joined
euandrehhas left
Ge0rG
Zash: I proposed more changes just a few minutes ago
Ge0rG
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
Ge0rG
The exception is 0441 which was already part of 0313 before
Ge0rG
Some notable 0313 history... https://github.com/xsf/xeps/pull/547
Ge0rG
Can we get into our time machine and just merge that change back in 2017 please?
marchas left
Ge0rG
marc: history of my proposed changes is https://github.com/xsf/xeps/pull/874
debaclehas left
Ge0rG
(looks like it got lost in gitlab)
Kev
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.
Daniel
I promise that once we have MUC-PAM you want mam to store groupchats
petehas left
petehas joined
Ge0rG
Daniel: yes, and that will be defined in the MUC-PAM XEP and not be part of 0313
marchas joined
Ge0rG
Daniel: even if we made 0313 say "MUST NOT store groupchat", a later spec could easily override that
Ge0rG
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
soundconcepthas left
soundconcepthas joined
marc0shas left
marc0shas joined
Ge0rG
But I sound like a broken record again.
Zash
Ge0rG: querying or filtering errors is a thing one might think about
Ge0rG
Zash: is anyone even storing errors?
Zash
Prosody (trunk)
werdanhas joined
Kev
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.
soundconcepthas left
Ge0rG
Kev: given its wide use, advancing it is obviously not solving any problems beyond Council and the XSF looking incompetent about our process.
debaclehas joined
emushas joined
soundconcepthas joined
pasdesushihas left
pasdesushihas joined
MattJ
If we're not going to advance stuff in wide use, I question the entire process :)
ti_gj06has left
Ge0rG
MattJ: but wouldn't it make sense to compare what we advance with what's actually implemented?
kyemxdenhas left
kyemxdenhas joined
malthehas joined
wgreenhousehas left
wgreenhousehas joined
intosihas left
xeckshas left
xeckshas joined
belonghas left
kyemxdenhas left
kyemxdenhas joined
intosihas joined
georgeorwellhas joined
marc
Ge0rG, I thought the new version of 401 referers to the new XEP that defines "your IBR" approach? I don't see this reference
malthehas left
Ge0rG
marc: yes, that PR was never merged
larmahas left
sebastianhas left
sebastianhas joined
intosihas left
intosihas joined
archas left
archas joined
archas left
archas joined
larmahas joined
marc
Why is that?
jgarthas left
Ge0rG
marc: I think it's because I used gitlab and because we have too few editors
marc
Okay, because that would be necessary before we can move 401 to stable IMO
davidhas left
davidhas joined
Ge0rG
marc: I agree with that. Would you want a Last Call after https://gitlab.com/xsf/xeps/-/merge_requests/33 is merged?
Guushas left
marc
Yep
andrey.ghas joined
lorddavidiiihas left
chronosx88has left
belonghas joined
intosihas left
Mhdyrihas left
chronosx88has joined
intosihas joined
me9has left
Ge0rG
jonas’: ⬆️ would you like to get a github PR of that tomorrow?