XSF Discussion - 2020-01-02

Maybe the right answer is not "have an easy but ugly way to stuff JSON into XMPP", but "have an easily accessible short book on how to properly XMPP"?

Maybe title it "The definitive guide" or something?

dwd: 1) Why not `send_json(wrapper_xmlns, wrapper_name, payload)` and tell people to put their company URL as xmlns and wrapper_name becomes ~datatype. 2) what about pubsub? :D

Ge0rG, I think you'd still need a relatively consistent API so you got the same results in each library. Otherwise interop - the thing that should be a given with XMPP - becomes hard.

Implementation notes?

Zash, (1) Might work, I agree. But how do you tell your library to listen for those? (2) Yeah. You could stuff UDT into pubsub, I guess. But realistically that's getting "hard". I bet more people would be using pubsub if we did that, though.

FWIW we (Prosody) already shove JSON (in JSON containers) over pubsub for reasons.

Zash, Also on (1), how would you structure the XEP-0030 stuff consistently?

Zash, For sure. And I have no doubt at all that you don't need UDT at all.

Verse has a nice `client:hook_pep(xmlns, callback)` API, tho for PEP.

`hook_udt(xmlns, name, stuff...)` something something I don't know, API design is hard.

Yes, some libraries have good ways of doing things aligned with UDT's goals easily. But even when they're good, they're inconsistent.

That PEP hook call magically adds the correct +notify flag too. A UDT API could do something similar.

And then you're recreating your whole library API on top of UDT?

Zash, That is, thus far, what UDT says to do. The only different is that I hardcoded you `name` argument.

and xmlns

and disco prefix

Zash, Sort of. I made the payload element a fixed XMLNS and added another, really.

Zash, And that mostly because I felt it was easier to specify, write a schema for, and write code for.

Zash, In particular, UDT has the advantage that "unknown UDT" is identifiable as UDT. Which might be useful during development.

I guess, but it seems an un-XML/XMPP-ish thing.

It is, though less un-XML/un-XMPP than stuffing things into convenient pre-existing slots with wildly different semantics.

On a scale from WebDev to XMPP dev, how un-XMPPy is it? :P

Well. I would argue that it's minimally conformant to XMPP. It's not ideal for any specific circumstance, but it's not harmful either. So while it's idiomatically "impure", I don't think it's actively wrong.

So while the correct answer to the question "Should I use UDT for X?" is probably always "No", the answer is probably always "Yes" if they didn't ask the question in the first place - and that seems to be the usual case.

Also, I'm enjoying that UDT is generating all the discussion, which will allow the much-more-complex MAMFC to get a number without any scrutiny.

But Fallback, which I was hoping would generate more conversation, is not. Boo.

Ye ol' bike shed vs nuclear power plant issue?

Yes, indeed.

Zash, re xmlns/name in the API: I agree with dwd that it’d be better to be able to detect UDT as UDT without having to know the specific use-case

at least as payload. the disco feature could indeed be separate

0. Welcome

Hi all. Who do we have?

!

(here, for the minutes)

Guus sent his regrets.

Seve, MattJ ?

hmm

Well, I didn't really expect much of a turnout the day after new years, so we should be declare a non-meeting

sure

Usual time next week?

Yes

can you do that? :)

nyco: I am a well-trained percussionist.

can you unpercussion?

that anti-drums, isn't it? :)

That's classified.

https://upload.movim.eu/files/1ab8cd5d50a081e2fdf8ce43dca3047f8bd49889/9IYxN32uq9GpJMcTcZJ17oqCdMwxmEfQRu5nAN6g/58D8_HdTS_qlpKc9ZuMYuQ.gif

nyco, Banging an anti-drum is the same as unbanging a normal drum, I believe.

And unbanging an anti-drum?

nyco, Never do that, Obviously.

Hey, sorry about skipping the meeting... I was unexpectedly somewhere without phone signal or wifi

Well, I lie. There was wifi, and it required mandatory selling of your soul to various marketing agencies, along with your email, postal address and date of birth

The privacy policy was pretty clear on that

That's meant to be a creative outlet, you are supposed to make up a persona

I failed the test then

Yes

Yes, the turing test is based around real people not reading privacy policies and such.

Boris Johnson has signed up to a number of free WiFi services around here.

One can only assume those technology lessons really helped.

brace for impact. I just deferred 21 XEPs. It was overdue.

Ooof

(I’m going to post a reply on the deferral of OMEMO so that nobody thinks that this is a political move)

Cover up!

heh

politics everywhere!

end-of-mailstorm

Thanks

now that I’ve an allocated slot for catching up on XSF work (tuesday evenings), I should be able to run deferrals more regularly

it’s also much less frustrating now that I found out that I can simply docker push.

jonas’, My problem not yours, but it'd be really helpful if the mailstorm for deferred hadn't coincided with a couple of updates. I was wondering how XEP-0426 had been deferred already for a moment...

dwd, not just your problem, which is why I specifically and manually sorted the updates to the end of the mailstorm

otherwise they would’ve been mixed

will be better in the future since there’ll be fewer deferrals

jonas’: massive amounts of appreciation for the massive amount of work that you perform!

(aka: I just opened my mailbox)

Guus, please, also clap for pep., who’s been doing most of the editor work in the last months

the deferrals was literally just running a script

Also, there are plenty of others that put in massive amounts of work - these emails just happened to catch my eye today. That's not to say all other work is equally appreciated.

I'm only using jonas’' scripts

flow, Have you done anything in Smack for SASL2?

dwd, nope, I have a major redesign of the connection mechanism to pave the way for ISR and the like ahead of me

flow, Oh? Any timeframe?

the classical "when it's done", i have already forked a branch and did some thinkering. It's a high priority item of my does-not-pay-the-bills todo list. But SASL2 is a subsequent job, and I still don't like that SASL2 and Bind2 are unnecessarly coupled

dwd, it sure would speed up the implementation if I implement do SASL2 without Bind2 and vice versa

https://xmpp.org/extensions/xep-0078.html but not a weird iq-like thing!

I didn't think Bind2 was coupled with SASL2 currently.

Oh and did we figure out how security-related the normal SASL stream restart was?

And whether it's safe to get rid of it

Yeah. It's important if you have no TLS (or do not trust it) and you do have a SASL security layer.

Which basically nobody does. We could insist that we do a stream restart if and only if there's a security layer inserted by SASL, or something.

Or don't trust the XML parser (maybe it has its own buffering or somesuch)

I think that only matters with a security layer, again.

> dwd> I didn't think Bind2 was coupled with SASL2 currently. that's great then, but please make it the other way around too

flow, Meaning?

dwd, possible I am talking about stuff that did not (yet) went into the xep(s). do you remember the discussion for last year's summit?

We talked a lot about a lot of stuff. (Hence the discussion in Council earlier). But yes, my overall thinking is that binding should end up as part of the SASL2 flow, because why not? Saves an RTT.

dwd, that is fine, but if my memory serves me right, then I think it could be done optional

I believe jonas’ aggreed with me, maybe he remembers more

IIRC it was just a minor thing, like the placement of an element as child vs sibling, that would make a huge difference

skimming over the xeps doesn't help me to recall what it was exactly, and potentially we discussed at the summit stuff that is not yet in the xeps

dwd, sasl2 states "the main distinction is that initial-response data is held within an element", but isn't the initial response also within an element in sasl1?

and what's the benefit of "A SASL2 success always includes the authorization identifier"? Don't you learn that also when binding?

maybe return the authentication identity here, and not the authorization identity?

The initial response is bare within the authenticate element, whereas it's in a child element in SASL2 so we can add other stuff there.

And yes, you do learn the authzid in bind, but it's nice to have it sooner (especially if you need it for something else).

The authcid isn't always a string (for TLS/X.509/EXTERNAL it's the certificate).

true

Oh, that's a thing for IBR2 to deal with too

not sure about the "it's nice to have it sooner part"

Funky cases where sasl username ≠ jid localpart

otoh, if bind2 only returns the resourcepart, then it's probably a good idea to return the jid in sasl2

Or! Stream restart and the server gives you a JID in the stream header

No need to bind at all

And yes you may remember that I'm against imbuing resources with semantics

but it appears that bind2 returns the full jid, and hence if you use sasl2+bind2 the sasl2 <success/> nonza will contain redundant information and waste bandwith. terrible!

(just kidding)

Or TLS client certificate auth with resource in it, instant ready to use session!

session in a can

dwd, I am still confused about "the main distinction is that initial-response data is held within an element, so the "=" special case no longer applies.", in sasl1 the initial response data is also the textual content of an element and here we have the '=' special case

ahh, now I get it, if <initial-response/> is non existent then there is no data

if it carries the empty string, then the initial response data is zero-length

ok, time to go to bed

Zash, What if the TLS cert had an ISR token in it?

What if?

And when do we get encrypted ClientHellos so all those TLS client cert things become realistic and not privacy nightmares?

Don't we already have those in TLS1.3?

Or what about them password based TLS key things?

dwd, nope

Didn't Big Cloud get those deferred until .. soon I hope?

Cloudflare says they have it. But does that mean only if I use their DNS over HTTPS thing?

It as in Encrypted SNI. But what about other ClientHello bits, like client certificates or whatever

Ah, yeah, ESNI is only enabled with DoH. D'oh!

Yea and esni doesn't protect ALPN either