XSF Discussion - 2019-10-14

flow: do you have a suggested wording for the MIX reference(s)=

flow: before you answered my mail, I made it look like this: https://op-co.de/tmp/xep-0423.html#future

Regarding the Compliance Suite: It lists "Private XML Storage", but what for, actually? I mean, private xml storage is no end in itself. bookmark storage previously used it, but the current version of the XEP doesn't, so what does XEP-0049 even do in there?

lskdjf: it's still used for bookmarks by some clients, because transition and backward compatibility are hard

also because pep bookmarks (except bookmarks2) don’t give a real benefit

and there was massive lack of server support for private and persistent pep until a year ago or so

and the compatibility transition requirements of Bookmarks2 are abysmal

it's actually used by pretty much all clients ^^ perhaps make it clear that this is really just about bookmarks backwards compatibility, then? Maybe by putting it into the same row as "Advanced Group Chat"?

Ge0rG, you might want to reference https://xmpp.org/extensions/attic/xep-0048-1.0.html then instead?

Private XML storage was widely used for client settings back in the day, but I don't know if anything still does that

"I don't know if" is not a good rationale to move it, or is it?

Do you need stronger opinions?

Zash, you mean for storing it's own settings? that would have nothing to do with compliance, then.

lskdjf, storing settings on the server

an advanced server needs to support it, no matter what a client does with it

Ge0rG, maybe a nice parallel to "Future development" would be to document what stuff we are trying to deprecate also

MattJ: indeed, but I'm not sure how to style that, also -ETIME

Ge0rG, also you didn't remove vcard-temp (at least from the core client) yet. A few days ago I got the impression you were on board with doing that. Did someting change?

lskdjf: I have no clue on how relevant vcard-temp still is

vcard4 is Proposed, and has been for some months now :(

(At least it's better than most other XEPs in the CS)

I think vcard-temp is still very relevant.

sadly

vcard-temp is implemented by every server and just about every client

Kev: is it core-relevant or advanced-relevant?

Core, I think.

and vcard4 is implemented by one server, and possibly nothing else

because avatars became advanced somehow. I hope nobody noticed.

You would struggle to implement an interoperable client/server without it.

And avatars need it, which are certainly core.

Does that mean it needs to be Client core/advanced?

Heh.

Kev: as I said, User Avatars are advanced ;)

Conversations doesn't have vcard-temp and it's (one of) the most popular clients. So not having vcard-temp can't be too bad.

> And avatars need it, which are certainly core. Kev: well clients can implement vcard avatars without displaying/parsing other vcard-temp information.

And for the record I also think avatars should stay in Core Client.

Only read-only.

I'm slowly losing track of all the things. Maybe this is due to the other things I need to work on in parallel, plus the timeline being tomorrow

lskdjf: why are avatars more important than 0392?

"more important" is IMHO a wrong way to compare those two things. Mandating UI in the compliance suite is simply a very bad idea and not the task or competence of the council. It's not part of the protocol, it's UI/UX design. avatars on the other hand are part of the protocol and it doesn't matter how or where you display them.

...or if you display them at all

I somewhat disagree with this analysis

if I don't display avatars, do I need to support them at the protocol level?

I agree with lskdjf here fwiw

luckily, I'm not wearing my Council hat here, but my XEP author hat ;)

I think Ge0rG's question is valid. Since 392 covers a fallback for avatars, it doesn't seem unreasonable to argue the case for it if you argue for avatars.

lskdjf, in any case, that should probably be expressed on the ML

I'm not sure I agree with it, but I think the argument is sane.

Kev: it's not a fallback, because you often need to display both the name and the image, but other than that, yeah.

lskdjf: yes, please write it to the ML.

Ge0rG: The bit about fallback avatars is a fallback for avatars :)

Kev: a fallback for fallback avatar fallback?

Can we agree on moving vcard-temp into "User Avatar Compatibility" or are there other use cases for it?

Ge0rG: I think there's one argument that, irrespective of the optimal thing, it might be least contentious, if you want things through smoothly on a short timescale, to put comments in the future direction section, and not change too much that's likely to bikeshed.

Clients tend to use vcard-temp + xep-0153 for avatars?

I think vcard-temp is core, because of the avatar requirement.

> if I don't display avatars, do I need to support them at the protocol level? Ge0rG orcourse not. but then you're not compliant. the difference is: "User Avatars" mandates that you should _have_ a feature. Somewhere, somehow. If I have to cascade through 3 menues to get there, that's client choice. But "User Name Coloring" tells the clients _how_ to do a UI feature. That's a difference.

I think vcard-temp is advanced for all other use. It's not obsolete because vcard4 "isn't used".

Kev: as I said, Avatars got demoted to Advanced by a strange mishap.

Using this year as an opportunity to rectify that seems sane :)

I have no idea why heated debates always happen in the last days before the new CS XEP is getting proposed.

We literally had a year to figure all that out.

that's the first time people look at them :)

Because everything happens last-minute when dealing with busy people.

I'm also slowly starting to feel why previous editors of the CS vanished.

indeed

lskdjf: I'm not sure whether we read the same version of 0392.

> Implementations may colorize the participants of a conversation with an individual color to make them easier to distinguish. > In such cases, the color SHOULD be generated as described in the Generating a color section.

> Implementations SHOULD allow the user to turn off any colorization completely.

lskdjf: also I'm curious what your actual problem with 0392 is, besides of it being out-of-scope of the XSF powers.

lskdjf: that said, I really don't see the principal difference to avatars. I'd even argue that avatars are worse than 0392, because their transmission consumes additional network capacity

GeOrG, I think the main issue is that quiet some XEPs on the list are on CS for the first time and many probably did not expect them to end up there given that they are still in their early days. I am currently writing a lengthy mail for the ML explaining why I think the color generation is flawed and imposes accessibility issues if used as suggested (which is rarely done, fortunately).

larma: I think the main goal of CS is to provide a useful selection of what to implement, to authors. I've done a review of the existing XEPs and considered some more for addition.

larma: jonas’ and I will be very interested to hear about the accessibility issues of 0392, and I hope we can improve that.

As far as I know, there are actually very few existing clients implementing the 3.2 usecase of 0392, where lack of contrast is a significant issue (it doesn't really matter for avatars, because avatars don't matter)

Fwiw I feel some general uneasiness about trying to put in a lot of new xeps last minute

larma: lack of contrast between the colored nickname and the background / theme of the client, or between different names?

first, second wouldn't be an accessibility issue

larma, for background contrast, there is https://xmpp.org/extensions/xep-0392.html#impl-bgcolor ✏

we can adapt the factors in https://xmpp.org/extensions/xep-0392.html#algorithm-bg if they’re not good enough for accesibility

also please note that all implementations SHOULD have an OFF switch for text colorisation for accessibility reasons ✏

Daniel, yeah.. lots of friction in a short period of time, not good.

We need to add some time to allow for dissipation

if only we didn't have Council election in a month, followed by re-org, followed by Christmas.

it will be impossible to finish this in 2019 if we don't vote on advancing before the reeleection.

I'm not sure when I volunteered to do CS-2020, but I'm sure it was early this year.

so everybody had enough time to propose changes.

The fact that nobody suggested changes could be seen as being fine with the status quo

Or that no-one's particularly enthusiastic about the suites.

Also

Or that no-one's particularly enthusiastic about XMPP.

I'm more enthusiastic about XMPP than I am about the suites.

It seems to be causing some friction now. So apparently people do care about the CS

I didn't mention caring, I mentioned enthusiasm ;)

I think we'd be better off not publishing them (in their Compliance Suite form, at least), but if we have to publish them I don't think we should get them wrong.

Kev: I think we tried very hard to have a phone conference type of thing happen to discuss alternative ways to do CS

I think compliance suites are a good thing. But I'd be careful about them becoming a simple _include all_

Sorry, I got to run now. I really hope I'm going to read your specific feedback on list, tomorrow.

Ge0rG: you're not attending at the Munich Meet up, right?

jonas’, yes I have read the XEP and the background color correction algorithm presented there is pretty bad

larma, suggestions welcome

How is it bad?

And regarding the last minute changes, I'm very sorry. I didn't factor in the time for the Last Call, also was very busy the last weeks (and still am). I really hoped to have this ready sooner

re 392, it's not perfect, but I haven't seen perfect yet, at least it's specified, it's better than whatever dino is using for instance

I'm in an IRC chat using biboumi with about 40 people, dino has about 4 different colors total shared across everyone, conversations uses 392 and at least has about 10 different colors instead

(I'm a little colorblind so that's how it looks for me, I haven't actually sampled RGB colors lately)

it's pretty hard to get it right, when jonas’ was playing with the algorithm, if he applied it to one set of usernames it'd look perfect, but then applied to another set, really bad, no idea

Daniel, pep. and me look almost identical in here. Well, that's life

Ge0rG, can you remove XEP-0223 from the list? It is Informational, there is nothing clients or servers need to do to implement it, so you are always compliant...

larma: isn't it useful to know for implementing bookmarks?

Isn't it required by bookmarks then?

> It is RECOMMENDED to use Publish-Subscribe (XEP-0060) [4] for data storage, specifically through the use of personal data nodes hosted at the user's virtual publish-subscribe service as described in Best Practices for Persistent Storage of Private Data via Publish-Subscribe (XEP-0223) [5] and illustrated in the following sections.

There's no XEP for "Full blown PubSub on your own JID", XEP-0163 specifies a minimum subset.

and it's again mentioned in the security considerations

XEP-0222 and 0223 talk about fancy things you can do with a slightly bigger subset

Does '163 actually specify a protocol? Should it too be Informational?

Or should 22[23] be Standards Track?

0060 is where everything is defined anyways, but you can't implement all of that

You can, no? But it's probably not required for most use-cases

All of '60? No that's impossible. First you have to implement half of it, which is a huge task. Then you have to implement half of the remaining part, also a huge task. Then half of the remaining, still a huge task.

... etc

Well I was thinking it makes more sense to require bookmarks 2 support if we require bookmarks 2 support. It doesn't add any value (at least for client developers) to know they should implement XEP-0223, because there is nothing in XEP-0223 that can be implemented.

larma: You could not do '222 or 223 with Prosody prior to version 0.10.

So there was *something* that was implemented.

because #persist_items ?

and access models

Zash, Yeah, for servers it might make sense, for clients it doesn't

on the other hand bookmarks 2 is nothing a server needs to handle if they do XEP-0223

larma: There is still a step between the absolute baseline defined by '163 up to what 222/223 describes

Like, dealing with publish-options

I agree, but still it's servers implementing 223, clients implement bookmarks 2 which relies on servers implementing the 0060 subset outlined in 0223

So, my point is, pointing to '223 in the compliance suite is a short-hand for pointing to specific features in 0060

what I mean is, we want servers to implement 163/223, but if a client only has a function to fetch bookmarks 2, that's fine, it doesn't need to be able to do anything generic for 163/223

I think you want publish-options with access model = whitelist

larma: there is also this thing about Bookmarks 2 not requiring backward compatibility.

Ge0rG, yeah that should be added, and I think it is in the submitted PR

(that JC just reviewed btw)

And even then, we can't demand bookmarks 2 right now, because inertia.

Under Futures maybe, but it seems way too early for a compliance suite spot

It's been just a few hours since I was told not to add controversial specifications at the last minute.

Zash: it's in Future already 😉

Ah

Can you re-post the link please?

> https://op-co.de/tmp/xep-0423.html

Thanks

Ge0rG, FWIW, I do really like your proposed compliance suites. Even though I don't see the point in mentioning all the single MIX XEPs, as it appears to create a lot of noise for no benefit. But besides that, it comes close to the "map of the xep jungle", which provides guidance about the current state and the probable future of XMPP, that I always asked for :)

just for info, there are still open issues with bookmarks 2 - 0060 needs changes - bookmarks2 XEP needs many additions - servers dont implement the requirements needed to use the XEP correctly

https://github.com/xsf/xeps/pull/835 ^, as mentioned in the other channel

Also for 0060: https://github.com/xsf/xeps/pull/840

and for server issue: https://github.com/processone/ejabberd/issues/3044

and of course we need conversion mods :)

so long road i would say

flow: have you checked the updated MIX list?

Well 402 can be used standalone once this is pushed

So it would make sense in some setups already

Maybe not for the "open network" (whatever that would be called)

"reality"

Ge0rG, when did you update it? You understood that I am arguing that there shouldn't be a MIX list at all but just a single reference to xep369?

flow: around the time you wrote your response. I just wondered whether this new approach is better. People need some way to discover the other MIX parts

Ge0rG, minor thing but why is the web section before the im section?

Zash: it was that way before

And should MLS be mentioned among the E2EE things?

Zash: is there a XEP?

Ge0rG, is XMPP-Core a XEP?

Zash: is there an RFC?

Internet Drafts, https://datatracker.ietf.org/wg/mls/documents/

~Experimenal or so

"Future things to keep an eye on" maybe. Not sure.

I also wish for more XEP-0288

Ge0rG, last time I looked at xep369, it did a very good job at pointing out the other MIX parts, if this is not the case, then this should be fixed in xep369 and not in the compliance suites

Zash, an XMPP+MLS I-D would be better

flow, I imagine that, or an equivalent XEP, might get written at some point

I don't have issues with the compliance suites pointing to MLS, but it should be clearly spelled out that there is no XMPP+MLS thingy yet

"On the horizon" something sometihng header maybe?

otherwise people may desperatly search for it because the compliance suites gave them the impression that such a thing exists

No idea what timeframe MLS might be ready in

+ when XMPP-flavored MLS appears on the market

If it's a time frame of over a year, which it most likely is, there is no reason to put it into CS 2020

XEP-0286: Mobile Considerations, what does it mean to support that?

Zash: nothing

Informational XEP in CS is kinda odd.

What's a server meant to do with Direct MUC Invites?