XMPP Council - 2023-08-30

I'm going to be on my mobile phone during the council meeting later so I'm checking the pending votes now...

Ge0rG: you are still pending on muc token invites. The meeting is your last chance to vote

Nothing else pending

daniel: thanks for the reminder, I've finally taken the time to go through the proto-XEP, and I have questions.

pep.: re MUC token invite, it reminds me very much of XEP-0401 (I happen to have had some time to consider a similar use case, inviting for an account instead of a room membership). Is there a reason to implement this via custom IQs instead of ad-hoc commands? The token request could be completely implemented using XEP-0401 syntax (if extended with optional time limit / count attributes). Token management could also be mapped to ad-hoc commands probably, without new protocol. You only need to define the form fields, command names and feature, plus the token-as-room-password part.

It's time

1) roll call

👋️

(bonus points for offering the token creation feature to all clients that implement ad-hoc already)

ohai

o/

We don't have an agenda this week so I'm just going to jump to date of next and AOB after quickly asking Ge0rG for his vote

2) pending votes

Ge0rG on muc token invites

You had feedback but does this block this being accepted as experimental?

daniel: I'm very much inclined to -1 based on the above question.

the proto-XEP complies with the formal requirements, but IMHO it creates redundant protocol that could be solved by ad-hoc commands with just a bit more boilerplate.

OK... Overlap imho isn't a blocker.

Anything can be done with adhoc commands

I see value in defining the use cases, but I'd love to see the custom IQs replaced by ad-hoc, or at least a good rationale for not using them.

Okay, in that case I'm +1, and I'm strongly urging the authors to either change that to ad-hoc ASAP or to provide a rationale for why-not, and I'd defer the -1 for a later stage of the XEP process.

OK. Thanks

3) date of next

+1w wfm

+1w may not work for me, we'll see

being the narcistig guy I am, I of course want to see the XEP-0401 syntax reused 1:1

+1w wfm

it looks like I'm blocked +1w and +2w

(I have thoughts on ad hoc commands Ge0rG. But now that the xep has been accepted maybe put your criticism into a mail to the standards list after it has been published and I'll respond with my thoughts on ad hoc commands)

(as noted earlier I'm on my phone and the council meeting is probably not the best venue for this anyway)

daniel: I might forget that, so feel free to push me into writing that mail as you deem appropriate :)

> it looks like I'm blocked +1w and +2w Noted

4) aob

Looks like none

5) close

Thank you all

Thanks daniel

Thanks daniel

thanks daniel

Ge0rG, just my opinion on ad-hoc: I think it makes sense to use ad-hoc for usecases where clients that just implement plain disco + ad-hoc (= without understanding the details of the protocol) will still get reasonable user experience. Otherwise, it makes very little sense to use ad-hoc instead of just plain IQ. Now the question remains what is reasonable user experience. Looking at XEP-0401, the expire field in the result form for creating a user invitiation is already beyond of what I would consider reasonable user experience (because it contains data that would be displayed to endusers in a naive client but is not end user readable). Also the form lacks labels, but I blame that on the fact its still experimental (well, it seems it was proposed)

larma: I agree there is probably no reasonable way to implement time-delta in ad-hoc, unless you just ask for days.

I'm not a proponent of ad-hoc in general, and I'm pretty sure somebody convinced me to use it in 0401, but maybe it wasn't too bad after all

I could well imagine having two or three ad-hoc commands along the lines of "Create a one-time invitation link" or "Create an unlimited inivtation link"

My client shows a 401 invitation as: > Invite web page: https://yax.im/i/#yax.im%3fregister%3bpreauth%3d... > Invite URI: .... > Invite valid until: 2023-09-06T15:23:25Z

and that's not too bad.

It's fine for you. If you show that date string to a non tech person, they're gonna be confused

yes, you'd have to convert it to local time and representation.

But if you are a naive ad-hoc client, you don't know that this thing is meant to be a date.

but the protocol is still usable

nothing stops a client from handling specific ad-hoc commands specially to give them a nice UI

basic IQ protocols don't degrade as nicely as ad-hoc commands do ✏

sure, my point was that if the protocol *requires* that the client has special handling to have a reasonable UI, using ad-hoc doesn't add any benefit over plain iq

'401 is not such a case though

401 is a borderline case, because users can just ignore the confusing expires field

I'm not saying that 401 shall not use ad-hoc

I was just picking an example from the XEP that I had just opened in my browser 😉

can we go back in time and add "date", "time" and "datetime" to 0004?

"no"

Can we just replace 0004 with "current HTML form draft"

With both client and server dev hats on, I'd rather avoid specs using adhoc :)

can we just replace XML with XHTML?

I here one should use CBOR or Protobuf these days instead of XML

Kev: so you'd always go with custom protocol?

I'm not saying 'always' as there's never a good reason to use adhoc, but I would generally default to not using it, rather than defaulting to using it.

Handling of the XML structures isn't the pain point in pretty much any XEPs, whereas any time you have to touch adhoc you find some sort of pain.

Ad hocs commands should only be used if you want to show them through 'dynamic' UI. Meaning 'specifying' ad hoc commands rarely makes sense in my view.

Hyperbole, but it's not far from the truth.

If you plan to use a custom UI an actual protocol is always easier to implement

So kinda/sorta what Kev said 😉

I understand that we cannot fix the pain points in 0004.

And fwiw I hate that 401 uses ad hoc 😂

Still, I think that specifying an ad-hoc command in a fashion that allows it to be used both by dynamic UI in legacy clients and by custom UI in modern clients is a Good Thing™

When M-Link added 191, we also added an equivalent adhoc to do the same thing.

Then later we were able to drop the adhoc interface, and were glad of it.

I think that's a more sensible approach than specifying protocols to use adhoc.

I see, I'm way too idealistic

Since '0004 is a separate XEP, I don't see any reason why you couldn't pass any other kind of payload in ad-hoc

Nothing at all is a legitimate payload used for some parameter-less commands already

Zash: you can pass any kind of payload, but you need a defined data type for it to be properly processed. and you need it twenty years ago

Tho at some point you just have a more complicated iq protocol :)

There are already extensions to XEP-0004 field types, such as XEP-0221.

Unrelated to that, on the topic of invite tokens. I've been looking at OAuth 2.0 *a lot*, and it's basically all just passing tokens around and trading tokens for other tokens. So. Uh. It's all just tokens, all the way down!

... down to the password

Which is a token

Oh no

So.. I see many voices against adhoc. What to do?

I see people who dislike ad-hoc, but not so much substantial arguments against it. I suppose I'll have to withdraw my threat of -1ing and you can go on

Is there actually anything that says there shall be no overlaps? Why would a XEP get a -1 for that? It's not like there aren't many file transfer xeps, or avatars, or bookmarks, or whatever. What changed?

I'm sure there are overlapping RFCs too, not reusing whatever "pieces" have been defined here and there. (Since we're kinda following what IETF does?)

pep.: the wording is 'does it fill a gap in the xmpp'

And it's something to take into account before moving to stable.

Maybe not a hard blocker. But something to take into consideration

And while we have overlapping xeps currently hopefully not a lot of them are stable or above

You mention avatars. But vCard for example is historical (IIRC)

vcard-temp?

Furthermore personally I don't necessarily agree that 401 and muc token overlap

One thing to think about is that we have a few cases of premature genericness

Only a few?

Yeah I wouldn't say overlap either, but I'm happy to say they're related. And I have been wondering if it's possible to make it so that a token allows to either create an account and allow in the MUC, or if the user already has an account then just allow in the MUC :x

Heh. Yeah. Things like Fastening.

Things that later turn out to be too generic and doesn't account for all the edge cases you find when you actually implement and deploy. So it might be better to wait with that until we have a bunch of similar protocols to think about wether they can be merged.