Ge0rG: My preference is always having a live discussion here to kick things off, but am not opposed if that's what people want.
Ge0rG
We had two weeks for a list discussion
SamWhited
We can always have a live discussion, but we might as well get the voting started so that we're not pushed for time
Kev
Yeah, but we sucked.
Ge0rG
Kev: do you think another week is going to change that?
Kev
Ok, that's 2:1 in favour of starting now with 1w expiry, so I'm ok with that. Can we make that 1w+1d?
Kev
So the voting period ends with the end of term.
SamWhited
Sounds good to me
Ge0rG
8d is okay
Kev
Cool.
Kev
3) https://xmpp.org/extensions/xep-0357.html
Advance to Draft?
vanitasvitaehas left
vanitasvitaehas joined
Kev
I'm on-list or next meeting.
SamWhited
I'm on-list. Re-reading this one I just don't think I have the necessary background knowledge to really have a good opinion.
Ge0rG
-1 because the high priority topic hasn't been addressed. I liked the stripped stanza proposal very much.
Kev
I'm very much in favour of allowing pushing the real data through, BTW.
Ge0rG
The current XEP is much better than half a year ago, but the feedback from the list last August wasn't addressed
Kev
Privacy is needed to be supported, but it's also useful to allow users/deployments to make the tradeoff of utility vs. privacy.
Ge0rG
Kev: a tri-state of none / stripped / full will make that possible
Kev
Yes.
Ge0rG
Was suggested some months ago
Kev
I'm aware I'm the caretaker of 357, so I probably need to put the time in here.
Kev
Goodness knows what time, but I shall try.
SamWhited
That seems overly complicated to me, but I am for allowing data
Kev
4) https://xmpp.org/extensions/xep-0359.html
Advance to Draft?
Ge0rG
The current status quo of hard coding "you have a new message" into the server module config is... non-ideal
Ge0rG
I've submitted some feedback to 0359 yesterday, and would like to see it addressed, but won't block it on that matter. +0 without a change or +1 if it's properly addressed
Currently, the examples in the XEP are missing the feature, right?
jonas’
are you talking about #715 or #716?
SamWhited
-1; I agree that it's weird to always include it even though it's obvious that it's supported, but I don't see the need to modify a final XEP and add optional behavior. My recommendation to implementations is to just follow the standard as its written, weird quirk and all, and if you need to check disco support make this assumption yourself.
Zashhas left
jonas’
that’s the most sensible word I heard about that so far, SamWhited :-)
SamWhited
I apologize for not replying to the list about this; I meant to do so earlier.
Ge0rG
Will accepting 715 make the examples consistent with the standard and include the feature everywhere?
jonas’
Ge0rG, the former, yes. the latter, haven’t checked.
Ge0rG
...and increase the number of examples where it's included?
jonas’
yes.
jonas’
if it is councils wish that the feature shall be in every disco#info/disco#items example in that XEP, I can do that upon merge.
jonas’
s/do/ensure/
Kev
I need to catch up, but I'm not keen on making any non-vital changes to 30.
Kev
Or any substantial non-vital changes.
SamWhited
Indeed; even in the state we're in today where everything ignores this, it's probably not going to break anything as is.
Ge0rG
I'm not sure we need to have it in all examples of all XEPs, I'd rather add a note to 0030 that the feature might not be present in *examples* but needs to be implemented
SamWhited
A little non-normative note seems reasonable.
Ge0rG
Yes, and it wouldn't change the normative text.
SamWhited
Although I don't think it's necessary either, but that would probably be for the next council to decide.
Ge0rG
So it's an editorial change.
Ge0rG
I don't see the need to hunt all XEPs for compliance
SamWhited
That's true, I'd be happy for the editors to just make that change
Kev
Sounds like time to move along, to me?
SamWhited
*nods*
Kev
9) Date of next
Kev
SBTSBC?
SamWhited
WFM
jonas’
Ge0rG, SamWhited, please propose wording.
Ge0rG
jonas’: can you remind me tomorrow around noon?
jonas’
Ge0rG, not really
Ge0rG
+1W WFM
pep.
/send_delayed "tomorrow around noon" poke Ge0rG
Kev
10) Yay, double-figures. AOB?
SamWhited
"Note that this may be omitted in examples in the XEP series"
lnjhas left
SamWhited
s/may/is sometimes/
Ge0rG
Kev: did we have any expired votes to recast?
Ge0rG
Open votes from last week?
Kev
https://github.com/xsf/xeps/issues/717
Is the only open one from last week, I think.
Ge0rG
SamWhited: s/this/the disco#info feature /
jonas’
I think the expired stuff was already covered
Kev
(And which I need to deal with)
Kev
The expired stuff is what Tedd put on the agenda, I believe. I've not checked the SoD to verify.
Ge0rG
I have started working on the Moved XEP but it turned out to be a huge mess, implementation wise.
Ge0rG
There's a rendered version of a preliminary proposal on my private server, but nothing official yet. Will submit it to the next council
Kev
Thanks.
Ge0rG
The only reasonable way I see is to use messages instead of presence, but I'm not clear yet whether we need messages from the old account or from both
Kev
Moved is a bit of a nightmare if you want to do anything automatically because you need your server to also do things automatically (like link MAM archives) and all sorts of horrors follow from entities causing your archive to be rewritten.
Kev
AOAOB?
SamWhited
none here
Kev
I'm hearing a silence of 'no'.
jonas’
-
Kev
So, thanks all.
Kev
<<EOF
SamWhited
Thanks
Ge0rG
Kev: we can solve Moved with a permanent roster annotation
Ge0rG
Is there precedent for roster annotations?
Kev
Ge0rG: I find your ideas intruiging and I wish to subscribe to your newsletter.✎
Kev
Ge0rG: I find your ideas intriguing and I wish to subscribe to your newsletter. ✏
jonas’
Ge0rG, MIX.
jonas’
and it’s a horrible precendent, IMO.
Ge0rG
Kev: you can rent my services at only 180€/hr... 😢
Ge0rG
Yes, MIX is a mess.
Ge0rG
But a Moved message will only be retained for so long, if at all.
jonas’
(I’m not saying the concept of roster annotations is a horrible precedent, but that particular implementation is)
Ge0rG
If you have MAM=contacts, and the old JID is removed, will your server purge the Moved message?
jonas’
probably not
jonas’
would be terrible if it did
jonas’
both for how MAM works, and for users
Ge0rG
Did I mention that implementing Moved on top of real life XMPP is a mess mm✎
Ge0rG
Did I mention that implementing Moved on top of real life XMPP is a mess? ✏
Kev
FWIW, roster annotations have been a thing we've been discussing for well over a decade.
Kev
MIX is just the first time we had a concrete use for them.
Ge0rG
Kev: but it never happened?
Ge0rG
Moved would be a concrete use case.
lnjhas joined
jonas’
IMO, the easierst for both clients and servers would be a namespaced element within the roster <item/>
Ge0rG
A PEP tombstone would be another possibility, but less flexible
jonas’
(regarding the general concept of roster annotation?)✎
Ge0rG
jonas’: that would be a roster annotation, right?
jonas’
(regarding the general concept of roster annotations) ✏
jonas’
Ge0rG, yes, that’s my point (just clarifying; I understand you’re probably behind latency)
Ge0rG
jonas’: and I'm approaching the next coverage hole. Also typing on a touch screen
jonas’
good luck
Ge0rG
Thanks. Looks like I survived the meeting well enough at least
jonas’
also, xsf@ maybe.
Ge0rG
If implementing roster annotations takes as long as persistent PEP, I'm out.