XMPP Council - 2020-09-30

I don't think I'll make it, but I'm +1 on the CS2021 XEP

And on-list for the other items

1) Roll Call

Here

Hi

Hello

Hi everyone

Ge0rG sent apologies, so moving on

2) Agenda Bashing

Assuming nothing

3) Editor’s Update

- New ProtoXEP: Compliance Suites 2021 - LC for XEP-0411 extended until 2020-10-14 after the original extension got lost in the void.

yeah, no idea what went wrong with that email, this one seems to have passed through

4) Items for Voting

(sorry for being terse today)

4a) PR#986: XEP-0277: pubsub#type MUST be set in bare PubSub URL: https://github.com/xsf/xeps/pull/986

I am on-list, I didn’t have the chance to read into what pubsub#type even is :)

I saw daniel comment that this is Experimental and thus not our thing to approve

what Zash said what I said

(actually Deferred, but still)

right, so this is not an item for vote, but an AOB

since pep. explicitly asked for guidance

let’s move it there and discuss it then, thanks for the hint

ack

4b) PR#988: XEP-0060: Add integer-or-max datatype to use with Data Forms Validation URL: https://github.com/xsf/xeps/pull/988 Note: The idea behind is to formally define the behaviour of the max-items field in PubSub.

!

As I said on the list; I'd be willing to +1 this unless someone really wants to put this somewhere 60-agnostic

but i'm not even fully sure that 122 is a better place

Assuming the schema magic is sane, +1. It would be nice if the registry was working ;)

'122 wouldn’t be a better place I think ✏

'60 is "fine by me", though not excellent

New XEP?

so the only way to make it it agnostic is a brand new XEP?

Zash, seems like overkill if I ever saw one

which is overkill. so 60 it is?

I did think about making it a new XEP just to define the type, and then edit 0060 to use it :/

I’m on-list nevertheless, I want to understand if that schema stuff is right first

Not sure what's best

I got the gut feeling that it isn’t

jonas’: oh glob

anyway have my official +1

jonas’, got it from https://www.w3.org/TR/xmlschema-2/#union-datatypes

and then have someelse block it if they feel like it

I would’ve expected dwd to have a strong opinion here (subtle ping)

pep., Your thought is that it needs an edit to '60 either way? I think that's probably right, so we might as well have the registration there too.

On the schema, it looks right to me.

yeah 0060 needs editing in any case I'd say. Because I need to give meaning to the type

For each field using it

If you want it Generic, shouldn't it have a 'min' enum too?

pep., Yes, seems right.

Zash, Is min not equivalent to zero in any case?

dwd: only if it's unsigned

Zash, not against adding it, but yeah I'd say it's likely to be 0

right..

Is it?

Oh.

'integer' is

signed.

Sorry

Is there an unsigned integer type?

I can’t think of a use case for 'min' and I rather not add something unless we have an explicit use

and infinite..

dwd, we can make one

But I'd think there is one already

Ugh.

And the semantics here is that 'max' is always whatever the acutal max is, even if you reconfigure it in the thing defining it?

daniel, if I split the thing into its own XEP I guess it might make sense

Zash yes

This feels like the sort of grinding down in detail that would be best done on the list. But anyway, I'm +1, but if you find improvements that's also good.

which is actually what I like about that

Zash, want to cast a vote?

+1

I'm also fine with this not needing a "min". If we want to expand later we can by having an integer-or-min-or-max or something.

let’s move on then

4c) Proposed XMPP Extension: Compliance Suites 2021 URL: https://xmpp.org/extensions/inbox/cs-2021.html Abstract: ... you know it ...

+1

+1

(I apologise for not having the strong opinions jonas’ hoped for).

+1

+1

swift

5) Pending Votes

a few on #983 from last week

me including, but then again, two people vetoed already

any need for discussion about that one?

oh, it’s the URI one

the author agreed in the meantime that URI encoding should be used and we’re done

6) Date of Next

You effectively pre-veto'd it.

+1w wfm

let me check

+1 to +1w wfm.

dwd, and by that you can see how awake I am today :D

+1w wfm

+1w wfm

neat

7) AOB

let’s insert the PR#986

-> https://github.com/xsf/xeps/pull/986

my stance doesn’t change (I need to read into this before I can provide guidance), but maybe someone else can

Opinion: This is good.

as I already said in the comments. _seems_ good to me. but i'm not an expert on microblogging. maybe someone else out there is using this on a different node for reasons?

it should really be left to the authors imho

note that pubsub#type is *not* the node ID

most of the authors I haven’t seen much around here lately

Yeah that's on purpose. The node ID is generally set to a UUID I think in Movim and/or Sàt

I think it's maybe a SHOULD and not a MUST. But I'd be curious as to what the authors say, as well as the Movim guys who (I think) use this heavily.

When not on PEP

edhelas seemed to approve: https://logs.xmpp.org/xsf/2020-09-30?p=h#2020-09-30-030be57f8039269d

and pep. said goffi did too

Oh, that's good then.

right. yes. just shows how not of an expert on microblogging I am

but if the two only implementors agree…

The #type field isn't super-well-defined tho

But experimental, so if those who want this want it this way, that's fine by me.

what is the benefit of using the pubsub#type?

Zash, true

is that something you can filter on when finding pubsub nodes?

jonas’, Discovery I guess.

The only thing that's normative about pubsub#type is "payload type"

The rest is somewhere in an example

AIUI it's meant to be an URI / namespace representing the payload type

jonas’, I don't think so, it's just that there might be multiple nodes using microblog on the same pubsub component

So you can't set them all to the same value

… to the same node ID

makes sense

but how does it help any entity then?

Theoretical filtering abilitity?

right

and maybe for showing stuff in a pubsub node directory or something

jonas’: microblog support for search.jabber.network !

of course :)

in that case a SHOULD should be fine?

If we ever did disco#search, it'd be useful.

yeah, so, I have little idea about microblogging. we’ll have to ping the authors anyway, but if the implementors agree, that’s already a good thing

Yeah, RFC 2119 expert comment on the MUST plz

daniel, any concrete reason why a MUST would not be desirable?

daniel, I feel that if it's a SHOULD in microblog, it makes this change moot. I said to Zash earlier "the XEP becomes unusable without the MUST the second another spec uses pubsub + atom"

Well, is it an absolute requirement for interoperability?

(because no, microblog is not just pubsub+atom)

how about we delegate that MUST/SHOULD debate to the authors?

hah

jonas’, i got the impression that it is a discovery/search thing? so if i don’t need it to be found

I mean, my gut feeling is SHOULD, but I'm not the expert here, and if those who are think if this is missing there's concrete interop harm then MUST it is.

but i'm really what ever on that

jonas’: sounds reasonable

daniel, I'm thinking if it's on the well-known node ID then it probably doesn't add value.

dwd, yes

then I’d like to move on to 7b

But I susp[ect this is bikeshed.

dwd, daniel, note that the text says that it’s not needed if on the well-known node ID

only if it isn’t

either way

pinging authors, moving on

I'm right then in my previous assertion. :-)

there might be other well knowns

7b) Message Styling It was not advanced and the author disagrees with Council. What to do next?

daniel, not defined in microblog

formally, we should Reject it, right?

which one is message styling again? :-)

Was Sam an outlier on this on the list, and did the community feel that the Council proposal was reasonable?

the one by Sam ✏

unclear

daniel, 393

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

there was lots of discussion I was not in the mood for reading *again* yesterday

Yeah, fair.

I think we should do sometihng about the status of '393

it is dangling in LC for a while now, and I’d like it if next council wouldn’t have to formally re-call it

sorry I wasn’t prepared to have that discussion

So, in general terms, our documents are meant to match our consensus as a group (not just Council, but everyone).

at the same time, I don’t feel like I can take it to go through that right now, so it’d be good if someone else was available to take that task

can someone share a link to the thread?

or the name/date

daniel, one second

it’s a minutes thread

[Standards] Council Minutes 2020-05-27

link in another second

thanks that's probably enough

https://mail.jabber.org/pipermail/standards/2020-May/037495.html

nice, pipermail doesn’t let you click next on that one

https://mail.jabber.org/pipermail/standards/2020-June/037496.html this may do

So if Sam, as author, is in the rough here, then he gets to say "I told you so", and not much else. But if there's no clear(ish) consensus, rough or otherwise, from the group on the way forward then that's not much help.

Because it goes into June

right. if I recall that thread correctly there wasn’t a clear community consensus

some (rightfully) hate the xep a lot for not being xhtml-im

but it also doesn’t try to be

quick question: can we extend by +10min to bring this to a more useful ending?

i personally probably would not vote to reject it

yes

shure

(Interjecting) ISTR there were some quite sensible suggestions made to make this a better imperfect solution to an impossible problem, which should probably have serious thought. Around opt-ins and the like.

right. those changes (if we want them to) could be made by simply taking the XEP over instead of rejecting it

I also wasn't ready for this :P

pep., nobody ever is for a re-iteration of message {styling,theming,formatting}

Iirc even the opt-in/out mechanisms wouldn't really help

not making an argument for or against those signaling/opt-in/opt-out changes

daniel, yes

pep.: IIRC, the mechanisms couldn't make this a perfect solution to the impossible problem.

But did solve some of the issues.

But I don't have this swapped in at the moment, sadly.

nobody has

one thing not addressed is "how do I have both a styled version and a fallback without adding ugly * everywhere"

for example, spectrum2-discord currently makes user @mentions bold with xhtml-im

eta, this is not about completely re-doing Styling

right

we have about one month left to properly bring this to a close.

I mean as an informational document '393 is pretty good

Oh, that's an interesting thought.

the best way forward I can come up with is if everyone of us (council) wades through that thread and tries to extract the community consensus and then we act on the mean of that

the Informational track has been proposed before for '393

eta, I want to disagree :p

Sorry, I'm forgetting things in my old age.

I do not recall who strongly opposed that though; might’ve been sam, might’ve been me.

(which really says something)

I'd rather have that somewhere hidden / locked-away never to be seen again

I think I've aged about a decade in the last 6 months (I suspect I'm not alone)

I think someone said we can’t change tracks

I mean it is a hack

but it's a relatively okay one

but i'd be fine with keeping it informational and roughly as is

like vcard-temp

daniel, we can do everything, if we ask board for a '1 override (and they grant it)

eta: oh no u didn't!!1

I honestly don't know that there's community consensus, even rough, to do anything at all. Including doing nothing.

i mean we can try to go through the thread again. but something something vocal miniority and haters gonna hate and stuff

so at some point we probably just have to decide something

Oh, it looks like <unstyled/> has already made it in. Which, again, I'd forgotten. That improves things significantly, I think.

or let the next council deal with it :-)

OK, so, I’ll set up a bunch of votes for next week: 1. Should we find a way to move '393 to Informational and keep it there? 2. If the previous vote should fail, should we take ownership from Sam and rewrite '393 with a mandatory and explicit opt-in? 3. If the previous vote should fail, should we accept '393 as-is? 4. If the previous vote should fail, should we reject '393 as is or accept it as Draft?

> Oh, it looks like <unstyled/> has already made it in. Which, again, I'd forgotten. That improves things significantly, I think. +1

I don';t think there was consensus for explicit opt-in, actually.

can we agree on that list? and also on everyone swapping this in so that we can bring it to a close?

Gonna need to stock up on 🍪

yes

dwd, there wasn't indeed :/

Also popcorn.

I’m not sure if the positive response is to popcorn or my list

my 'yes' was regarding your list

I *think* there might be (very) rough consensus to have it with an explicit opt-out, and publishing it. Though whether as Informational or Standards Track, I don't know.

I put the votes on next week’s agenda

(Don't want to derail the meeting, so ignore this for the moment, but I think there is a strong argument for having a this-is-marked-up, which is not necessarily used for opt-in, because it allows you to strip the formatting, knowing that's what it is, ending up with something more $OTHER_MESSENGER (and more useful, I believe) - maybe not a hill to die on, but I think there isn't a reason it would be bad to tell people it's marked up)

and now I’d like to step away from this, and I also think that we can’t find a solution right now and here

any other AOB?

Kev, yes, and an argument for opt-in

Kev, https://mail.jabber.org/pipermail/standards/2020-June/037506.html I found reasonably compelling.

dwd: I *think* he's looking at using an opt-in, there, which has pros and cons, as opposed to simply an announcement that something is marked up?

I’m taking this as a no

8) Ite Meeting Est

thanks everyone

Thank you jonas’

There were questions in #988, but I guess I'll poke people on xsf@ later on

Ah, no, he does address the third state towards the end.

Re datatype prefix

dwd: But he's not addressing it from a point of view of it being a known state. Maybe if I called it <strippable/> it would make the point more clearly. So you have three possible states of <strippable/>, <unstyled/> and nowt. ✏

I guess I'm less annoyed about the XEP but more about its adoption. Devs thinking this is actually a good solution

Kev, A point you indeed raised in the thread.

Oh, did I? How refreshing for me to be consistent :)

move that to xsf@ maybe?

pep.: isn't the adoption one client

yours?

And one client that copy pasted the code

Kev, I'm basically finding myself on the same rollercoaster I suspect I was on when I first read the thread.

Kev, And also, June feels like years ago.

What the ... that was THIS YEAR?

Which is actually slightly frustrating because Dino and Gajim render it slightly different

But not different enough

Time flies like an arrow (fruit flies like a banana, though).

(unless either of them 'fixed' this recently)

daniel, IIRC, Psi implemented (basically) this about a decade ago.

With emphasis on _basically_

You mean yet another variant?

XHTML-IM wasn't that bad

I think Psi was the first XMPP client to do this.

Gajim also had something like this since time immemorial

pep., Part of Sam's intent here was to unify the variants, in fairness.

eta: That's the upsetting thing, XHTML-IM *wasn't* that bad.

The idea is the same. But the exact implementations vary

Which can be annoying in certain cornor cases

eta, The problem with XHTML-IM was that virtually every implementation had security flaws.

https://mail.jabber.org/pipermail/standards/2020-June/037514.html I think the point I made there still stands, basically, although I had no idea it was only three months ago I raised it. ✏

dwd, I think my bitterness about 393 is mostly due to the fact that this came up right after XHTML-IM was "killed", and proposed as some kind of replacement that it isn't

I don't recall the time line being in that order

And the irony in literally everything else (outside XMPP) uses something like XHTML-IM, but embedded in JSON

yeah

yeah exactly

Zash: Ah, although with one major difference, I think.

dwd: this is only because people just shoved the XHTML into a webview or something stupid

Zash: Not duplicating the body (maybe that's only a concern for us, but it's a major concern when you have two different representations that could have completely different content, shown to different users)

like if you tree walk the XHTML you don't have this problem

Kev: Matrix duplicates the body.

eta: I think it's more than that. You can be trying quite hard to not be stupid, and still fall foul of things.

And also tripples it if you make a correction iirc.

I think the fault here is that xhtml-im was too broad and invited doing exactly that (putting it in a web view)

daniel, too broad? there's a nice whitelist there

Or more limited scope (same feature set as 393) could have prevented that

Kev: yeah, okay, stupid is an unnecessarily caustic word :)

eta, Yes, but while we know what people are meant to do, and even designed XHTML-IM to support same, nobody did it that way at first.

pep.: it has css

daniel: tbf, the css also has a whitelist

CSS1 yeah

But I'm not gonna write an css parser

but something that is actually XML based instead would be bettee

r*

I strongly suggest to move this to xsf@

like even if it's <bold>whatever</>

When the alternative of putting it an a web view is so easy

jonas’, I'd just try to kill the chat :p

pep., I could, but it’d take down xsf@ with it :>

*disband*

(both!)