XMPP Council - 2018-11-14

Ge0rG, do you still agree with MattJ’s assessment after the recent update?

jonas’: from a skim of the XEP, it looks like it's still relying on MUC message semantics

huh, ok

jonas’: unless there was another update since yesterday

not that I knew

So I'm torn between documenting a hack that works, more or less, and got implemented because somebody wanted pictures on a MUC, and doing it right.

AFAIR, all avatar XEPs have drawbacks, and there's no really good specification.

yes

the PEP-based avatars for users seem to work rather okay, except that they don’t allow for multiple different MIME types in pubsub.

Let's allow that then?

Let's have multiple nodes, each with multiple items!

Or multiple items in both nodes with whatever

I'm on mobile today, so semi present. Can't chair, but will try to swipe fast enough

'tis time, 'tis time.

Daniel's the only one who can't today, I think, from the last minutes.

o/

Do we have a Dave?

Kev: you are chairing?

I can if Dave's not here.

My train is delayed, and I'm in it

1) Roll call ✏

I'm here, Sam, Ge0rG. Daniel apologies, I think Dave's missing.

Sorry, I was desperately trying to close off my last meeting.

Fully here now.

2) Agenda

Tedd sent out a bunch of suggestions around LC items. ✏

Rather than going through them now, I think it'd be more effective if we agreed to give feedback to each on-list in the relevant threads.

What do people feel about that?

And to then have a concrete vote on each next week, with a 1-week timeout instead of the normal 2-week. ✏

next week is too late.

(On the basis that last week is our last chance this term)

(for a vote with 1w timeout?)

That seems reasonable to me; as long as we don't let them roll over to the next term which always means they're forgotten about.

Isn't that our last week with a 1 week timeout?

Ah, is my timing a week out?

the 22nd is next week, thursday

Yes, I think you're right.

Ok, in that case I suggest exactly the same plan but s/1w/1d/

What about voting today with 1w instead? ✏

We still end up with 1 week for on-list

Ge0rG: My preference is always having a live discussion here to kick things off, but am not opposed if that's what people want.

We had two weeks for a list discussion

We can always have a live discussion, but we might as well get the voting started so that we're not pushed for time

Yeah, but we sucked.

Kev: do you think another week is going to change that?

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?

So the voting period ends with the end of term.

Sounds good to me

8d is okay

Cool.

3) https://xmpp.org/extensions/xep-0357.html Advance to Draft?

I'm on-list or next meeting.

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.

-1 because the high priority topic hasn't been addressed. I liked the stripped stanza proposal very much.

I'm very much in favour of allowing pushing the real data through, BTW.

The current XEP is much better than half a year ago, but the feedback from the list last August wasn't addressed

Privacy is needed to be supported, but it's also useful to allow users/deployments to make the tradeoff of utility vs. privacy.

Kev: a tri-state of none / stripped / full will make that possible

Yes.

Was suggested some months ago

I'm aware I'm the caretaker of 357, so I probably need to put the time in here.

Goodness knows what time, but I shall try.

That seems overly complicated to me, but I am for allowing data

4) https://xmpp.org/extensions/xep-0359.html Advance to Draft?

The current status quo of hard coding "you have a new message" into the server module config is... non-ideal

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

I'm list/next meeting on this as well.

I'm on-list for this one as well

5) https://github.com/xsf/xeps/pull/692

I am, again, onlist/next meeting.

+0

on-list

6) https://github.com/xsf/xeps/pull/693

OL/NM

on-list

+0; pub-sub is something that I just don't feel confident enough with to review it no matter how many times I re-read it.

This is so productive! ✏

7) https://github.com/xsf/xeps/pull/715

OL/NM

on-list

+1

8) https://github.com/xsf/xeps/pull/716 https://mail.jabber.org/pipermail/standards/2018-November/035434.html

OL/NM

It's asking for discussing, right?

discussion didn’t happen

council needs to make a decision

Currently, the examples in the XEP are missing the feature, right?

are you talking about #715 or #716?

-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.

that’s the most sensible word I heard about that so far, SamWhited :-)

I apologize for not replying to the list about this; I meant to do so earlier.

Will accepting 715 make the examples consistent with the standard and include the feature everywhere?

Ge0rG, the former, yes. the latter, haven’t checked.

...and increase the number of examples where it's included?

yes.

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.

s/do/ensure/

I need to catch up, but I'm not keen on making any non-vital changes to 30.

Or any substantial non-vital changes.

Indeed; even in the state we're in today where everything ignores this, it's probably not going to break anything as is.

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

A little non-normative note seems reasonable.

Yes, and it wouldn't change the normative text.

Although I don't think it's necessary either, but that would probably be for the next council to decide.

So it's an editorial change.

I don't see the need to hunt all XEPs for compliance

That's true, I'd be happy for the editors to just make that change

Sounds like time to move along, to me?

*nods*

9) Date of next

SBTSBC?

WFM

Ge0rG, SamWhited, please propose wording.

jonas’: can you remind me tomorrow around noon?

Ge0rG, not really

+1W WFM

/send_delayed "tomorrow around noon" poke Ge0rG

10) Yay, double-figures. AOB?

"Note that this may be omitted in examples in the XEP series"

s/may/is sometimes/

Kev: did we have any expired votes to recast?

Open votes from last week?

https://github.com/xsf/xeps/issues/717 Is the only open one from last week, I think.

SamWhited: s/this/the disco#info feature /

I think the expired stuff was already covered

(And which I need to deal with)

The expired stuff is what Tedd put on the agenda, I believe. I've not checked the SoD to verify.

I have started working on the Moved XEP but it turned out to be a huge mess, implementation wise.

There's a rendered version of a preliminary proposal on my private server, but nothing official yet. Will submit it to the next council

Thanks.

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

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.

AOAOB?

none here

I'm hearing a silence of 'no'.

-

So, thanks all.

<<EOF

Thanks

Kev: we can solve Moved with a permanent roster annotation

Is there precedent for roster annotations?

Ge0rG: I find your ideas intriguing and I wish to subscribe to your newsletter. ✏

Ge0rG, MIX.

and it’s a horrible precendent, IMO.

Kev: you can rent my services at only 180€/hr... 😢

Yes, MIX is a mess.

But a Moved message will only be retained for so long, if at all.

(I’m not saying the concept of roster annotations is a horrible precedent, but that particular implementation is)

If you have MAM=contacts, and the old JID is removed, will your server purge the Moved message?

probably not

would be terrible if it did

both for how MAM works, and for users

Did I mention that implementing Moved on top of real life XMPP is a mess? ✏

FWIW, roster annotations have been a thing we've been discussing for well over a decade.

MIX is just the first time we had a concrete use for them.

Kev: but it never happened?

Moved would be a concrete use case.

IMO, the easierst for both clients and servers would be a namespaced element within the roster <item/>

A PEP tombstone would be another possibility, but less flexible

jonas’: that would be a roster annotation, right?

(regarding the general concept of roster annotations) ✏

Ge0rG, yes, that’s my point (just clarifying; I understand you’re probably behind latency)

jonas’: and I'm approaching the next coverage hole. Also typing on a touch screen

good luck

Thanks. Looks like I survived the meeting well enough at least

also, xsf@ maybe.

If implementing roster annotations takes as long as persistent PEP, I'm out.

shouldn’t be as hard

Not sure it's about being hard.

https://xmpp.org/extensions/xep-0145.html