Ge0rGDid anyone have a look at https://xmpp.org/extensions/xep-0459.html#future to see what should be promoted?
belonghas left
Ge0rGjonas’: 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
Ge0rGanything to add in the revision history, or just the content itself?
Ge0rGNot sure how many other Council members are still pending their vote for advancement
emusGeneral unexperience question: Why do we always make it a new XEP? why not update the existing one each year? So referencing would be easier?
emusprevious states could be archived somehow?
Ge0rGemus: because archiving old version of XEPs is hard.
millesimushas left
Ge0rGemus: 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
emusAh 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
Ge0rGmarc: would you be opposed to issuing a Last Call on XEP-0401?
archas joined
SamThe 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
Ge0rGHolger: does ejabberd implement any of XEP-0379, XEP-0401 and XEP-445?
archas left
archas joined
archas left
archas joined
HolgerGe0rG, no.
beanhas left
archas left
archas joined
Ge0rGHolger: do you have plans to?
archas left
archas joined
phrykhas left
archas left
archas joined
antranigvhas left
archas left
archas joined
HolgerI 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 😕
HolgerI might do that, but not right now.
archas left
archas joined
Ge0rGHolger: I wasn't unhappy with 0389, I was not expecting anybody to implement it any time soon
MattJSame here (I was just typing that)
Holger🤷♂️️ whatever.
archas left
archas joined
archas left
archas joined
HolgerJust saying I think we have 0 lines of "Snikket code" right now (while I was wrongly assuming we did, before) ...
Ge0rGHolger: XEP-445 is an alternative mechanism to 0389, so you could have clients use either.
HolgerYeah.
HolgerI'm not complaining about anything, mind 🙂
MattJYou don't even have the ad-hoc commands?
archas left
archas joined
HolgerNo.
archas left
Holger(Unrelated to '389 vs. '445, I know. I just had wrong assumptions about the state of affairs 🙂)
archas joined
COM8has joined
MattJnp
babacbhas left
babacbhas joined
jgarthas joined
COM8has left
bungNow is XMPP has received funds?
archas left
archas joined
HolgerIt'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
HolgerBut 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.
Ge0rG> 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
DanielGeneral 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
marcGe0rG: what was changed in 401?
marchas left
GuusDaniel: 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
Ge0rGmarc: 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
GuusThen 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.
Ge0rGDaniel: what's your proposal?
ZashSo should I again mention that maybe there should be two documents, one "current best practices" and one "future vision"q✎
ZashSo should I again mention that maybe there should be two documents, one "current best practices" and one "future vision"? ✏
ti_gj06has joined
GuusYes please mention that again.
Zash"that", again 🙂
archas left
archas joined
soundconcepthas left
soundconcepthas joined
marchas joined
marcI'm not up-to-date, sorry
Guusba-dum tissshhh
DanielNothing 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
DanielHowever there is also value in being a bit more stable with the list of xeps
DanielI guess that's what I'm saying. Just thinking out loud really
GuusAre we adding XEPs to the new compliance suits that didn't exist in the year before?
ZashWe didn't, unless something happens at the last minute
Guuschat isn't that new. You'd think that the set of functionality that's deemed "sensible" does not change much year over year.
ZashThere's only a single change between 2021 and 2022, in that XEP-0156 is now required
archas left
archas joined
euandrehhas left
Ge0rGZash: I proposed more changes just a few minutes ago
Ge0rGAlso 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
Ge0rGThe exception is 0441 which was already part of 0313 before
Ge0rGCan we get into our time machine and just merge that change back in 2017 please?
marchas left
Ge0rGmarc: history of my proposed changes is https://github.com/xsf/xeps/pull/874
debaclehas left
Ge0rG(looks like it got lost in gitlab)
KevI 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.
DanielI promise that once we have MUC-PAM you want mam to store groupchats
petehas left
petehas joined
Ge0rGDaniel: yes, and that will be defined in the MUC-PAM XEP and not be part of 0313
marchas joined
Ge0rGDaniel: even if we made 0313 say "MUST NOT store groupchat", a later spec could easily override that
Ge0rGOn 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
Ge0rGBut I sound like a broken record again.
ZashGe0rG: querying or filtering errors is a thing one might think about
Ge0rGZash: is anyone even storing errors?
ZashProsody (trunk)
werdanhas joined
KevFWIW, 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
Ge0rGKev: 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
MattJIf we're not going to advance stuff in wide use, I question the entire process :)
ti_gj06has left
Ge0rGMattJ: 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
marcGe0rG, 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
Ge0rGmarc: 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
marcWhy is that?
jgarthas left
Ge0rGmarc: I think it's because I used gitlab and because we have too few editors
marcOkay, because that would be necessary before we can move 401 to stable IMO
davidhas left
davidhas joined
Ge0rGmarc: I agree with that. Would you want a Last Call after https://gitlab.com/xsf/xeps/-/merge_requests/33 is merged?
Guushas left
marcYep
andrey.ghas joined
lorddavidiiihas left
chronosx88has left
belonghas joined
intosihas left
Mhdyrihas left
chronosx88has joined
intosihas joined
me9has left
Ge0rGjonas’: ⬆️ would you like to get a github PR of that tomorrow?