XMPP Council - 2019-03-13

Do we have an agenda for today?

Nafaik.

There are pending protoxeps but maybe too late

If those didn't make it onto an agenda, I guess next week for them.

Yes, we do have https://github.com/xsf/xeps/pull/765

just in case you also have: https://xmpp.org/extensions/inbox/eax-cir.html

Yeah, no agenda, sorry - things are a bit mad for me at work currently.

I've been completely swamped for the last few weeks.

I have at least got out votes for the meeting two weeks ago just before they expire.

it is reassuring that we’re all being swamped at the same time at least

hasn’t been much better for me either, as you can probably guess by the editor latencies

the council is swamped, okay

I’ve also been both swamped, and got my main laptop stolen. :x

Oh, that's sucky.

I do have backups, but I need to get a new one asap.

And also a new passport.

Link Mauve, ouchie

Oh, that does suck, indeed.

So, anyway:

1) Roll Call

Here.

Link Mauve and jonas’ I assume are here - Ge0rG?

I am

Well, we'll move on.

2) Agenda Bashing

I see two ProtoXEPs, and nothing else.

I haven’t checked the editor inbox in the last 7 days, unfortunately.

(mostly)

I'm perfectly happy to get the two ProtoXEPs onto this meeting's agenda so we can at least hope to get them through quickly, even if many of us are on-list.

I agree with that

I think everyone onlisting is something to be avoided, and we should be aiming not to add things to the agenda during the meeting. But, majority rule.

Oh, and Jingle Message Initiation has been requested to move to Draft.

So a last call?

Kev, yes, but all these things have been posted to the standards@ list, so it's entirely our fault.

Kev, we could discuss this particular point in AOB, I have opinions on that.

dwd, they have been posted last night though, I can see his point ;-)

dwd: I used to monitor the calls, but since we get agendas in advance, these days I just wait for the agendas to come in.

3) Items for a vote

Kev, I find your faith in me worrying.

a) E2E Authentication in XMPP: Certificate Issuance and Revocation

https://xmpp.org/extensions/inbox/eax-cir.html

Well, if we rely on everyone working out what the agenda will be, there's little point sending out agendas :)

On-list.

on-list, obviously

On-list too.

I think I'm tentatively +1. Seems in-scope.

oooh

ooooh

(that’s for the anticipated (b))

What?

Oh.

I was just reading XEP-0001 regarding the next one

b) DNS Queries over XMPP (DoX)

https://xmpp.org/extensions/inbox/dox.html

This was an 1stApril wasn't it?

this should’ve been on the humorous track

and not ever reached council

according to '0001

I’m getting a call

They're not meant to reach us, indeed.

I genuinely do not know if this one is April 1 or not. But yes, I agree it's out of our scope.

jonas’, People call you about these things now? :-)

There have been people voicing concern that this isn’t any more humorous than the HTTP version.

And could even be more useful.

jonas’, If it *is* intended to be a joke - and I thought DoH was originally - then it's of the wrong Type.

dwd, yes

it is

> I would humbly suggest this might be accepted as a XEP on the first of next month, if council approves. ;) from https://github.com/xsf/xeps/pull/765

I messed that one up

Ah-ha.

No worries. We'll skip that then.

spoiling the fun though

to the minute-taker, please omit the discussion about (b) :)

Let's ...

right, that.

personally, I'd prefer it not be humorous track, but also released april 1st :)

don't know who ends up making that decision, just that it's not me

moparisthebest, in the end, it’s you

c) XEP-0353: Jingle Message Initiation

You as the author makes the decision on which track to go through.

if you say you actually want this on Standards Track and not Humorous...

it's no more or less serious than DoH, which is a real RFC :)

Oh, wait, are we going to consider this one properly then?

I’m afraid so

Oh. So I'll +1 DoX if you want it on Standards Track, but I'm going to be leaning on you very heavily to get some Security Considerations in place about privacy.

I'll on-list it, but I'm very much opposed to publishing on April 1st if it's not meant to be humorous.

I *mostly* copied them directly from Security Considerations on the DoH RFC, but yes I agree privacy stuff should be added

Kev, You can engineer that, of course...

OK, jonas’, Link Mauve - since we're actually voting, are you two also going on-list?

Yes, I will be.

Leaning towards +1 because it’s a valid usecase and seems properly written.

jonas’?

I'll assume he's trapped on the phone and will on-list.

So back to:

c) XEP-0353: Jingle Message Initiation

Andrew asked for this to be advanced to Draft, so we'd need to vote for Last Call.

Is there any author available to issue the last call?

Link Mauve, Good point.

Previously, we could have just done this if we wanted.

Or is Andrew becoming the shepherd? ✏

Now we're only allowed to if we determine it's abandoned.

dwd, sorry, I’m on call and got a page, that’s what I meant to say earlier

I’m on-list, defaulting to -1 otherwise.

regarding (b)

regarding (c), nothing wrong with LC I think

(For those not following, a recent change was made by Board to XEP1 to change it from Council being allowed to issue an LC whenever it wanted, irrespective of who asked, to only being able to issue one if an author asks, unless the authors have abandoned the XEP)

I'll follow-up with Andrew to see if he's willing to gether and process feedback, then.

So I think we're obliged to contact Peter and Philipp and ask if they've abandoned it. ✏

I'll do so.

Ta.

4) AOB

I know jonas’ had some aboutt agendums, but I assume that can wait and/or be discussed on the Council list.

Anyone else?

Newp.

5) Next Meeting

+1W?

Same time next week?

That's Wednesday 20th March, 1600 UTC.

6) Ite, Meeting Est

Thanks all.

I don't currently have anything stopping me, but the way things have been recently... yeah.

Kev, I know that feeling and truly sympathize.

Kev, so it's as-useful as DoH but with better performance (less RTTs), and has implementations that work, which is why I want Standards Track, but also like DoH it's a flagrant layer violation so I just thought it'd be funny to release on April 1st and have people forever more wondering "wait, is this a joke or not?"

but I can have an odd sense of humor, I'm not married to the idea :P

people wondering about a spec being a joke or not is generally not good for UX

jonas’, curious as to the default to -1, but if you are going to bring it up on list I can wait to discuss there too

moparisthebest, I don’t think either of DoH or DoX is a good idea

but I’m going to read the rationale and be convinced otherwise

well I can tell you right now if you don't like DoH you won't like DoX, they are for all intents and purposes identical

what purpose? browsers need this hack because they need to resolve, and an XMPP client doesn't need to resolve anything

not sure if trolling...

if anything an XMPP client needs to resolve much more? don't some resolvers still break on SRV etc

it needs to resolve that to open the stream

HTTP upload eg

not if it's hard-coded, like any DNS resolver will have to be

moparisthebest, you don’t need to hard code DNS resolvers

you learn them via DHCP or system configuration

Zash, isn't what an HTTP library should do?

and those are the ones that don't do SRV properly, or mangle responses etc, read DNS-over-TLS and DoH spec for all those reasons

that's just not true anymore jonas’ , android 9 hardcodes a DNS-over-TLS by default now, browsers hard-code DoH addresses etc

and we need that insanity in XMPP too?

moparisthebest, yes, because they suck

of course, we are forever trying to catch up to HTTP browser levels of insanity

so far that's not we but you 🙂

so, you are a XMPP client, you ask your resolver for SRV records, it returns an error, then what?

it could fall back to connecting to a known/public "resolver xmpp account" and resolving that way

you try A record?

ok so if that fails then

that's one perfectly valid usecase, another is your router staying connected via XMPP and resolving DNS for your network

valid use case in what situation?

my router currently resolves DNS over DNS-over-TLS and DNS-over-HTTPS, both over tor, and the constant TLS setup/teardown adds quite a bit of overhead that wouldn't exist with DoX

when resolver doesn't work, but internet does?

that's 2 usecases I can think up right now

1.3 to the rescue?

zinid, yep, that happens often

moparisthebest, I don't think often enough to address the problem using stupid hacks

wasn't Ge0rG just complaining the other day that a large % of clients couldn't resolve SRV records?

I don't like this attitude to degrade the tech because of amateur developers

it's not how the industry is progressing

where do amateur developers come in?

you cannot degrade medicine or particle physics

to fit idiots in there

the SRV record thing is bad dns resolvers that haven't been upgraded in 20 years

and/or bad ISPs or countries that block them

and the web doesn't use SRV, so who cares

use A records?

exactly

still better than DoXYZ

zinid, port 5222 is blocked too

and how DoX will help with blocked ports?

maybe we should just make XMPP connect to port 443 on the A record via TLS as a fallback :)

use 443, we already have this insanity

because DoX gets you the SRV records that can point to alternate ports?

and then they will block your ALPN?

what will do next?

looks like an arm race

well, we have encrypted SNI now, so encrypt ALPN using the same setup? :P

it's absolutely an arms race

but why would we need to accept the race? what's the point?

end goal being have everything encrypted and unblockable

then $they find new ways to block, and $we find new ways around those, forever

which means everything is resolved via a single 1.2.3.4 using TLS on 443?

that's what we're going to do

yea, that's already the case basically

FWIW, I do think DoX is insane, but so is DoH. Question for me is whether DoX is better being redirected to IETF, thinking about it, if i's a serious proposal.

I disagree of course, it's not the case

at least things brings in the possibility for more diversity in resolvers

moparisthebest, there will no be diversity, there will be 1.2.3.4 TLS on 443

zinid, it is the case, android 9 ships by default with all DNS going to google over TLS

and?

browsers already ship with DoH capability

so why we need DoX?

only a short matter of time before they turn on by default

dwd, I agree with you, DoX is equal in it's insanity to DoH, no more, no less :)

both have use cases, both a bit crazy, but use cases nonetheless

moparisthebest, The main use case being having someone like Google get all your DNS lookup data.

yeah, I personally don't care whether it will be Google or moparisthebest.com, both are crap

run your own?

we should not move that road

moparisthebest, I already run my own. On port 53.

moparisthebest, why? I have everything working

and every *other* network you go on intercepts that and sends you whatever it feels like jonas’

moparisthebest, so? I have dnssec for that.

and I don't want to run my own, that's also insane

it can’t, too, because my resolver runs on 127.0.0.1

oh so then they just DOS you?

I wanna see them intercept /that/

DNSSEC solves a different set of problems

they can DOS me already if they block TCP or UDP or whatever

privacy etc for instance is not addressed by DNSSEC

yeah

I can personally live with that. and if others can’t, we should solve this in DNS, not by stacking layers over layers for no good reason.

take it up with the IETF, they decided it was a great idea

Surely DoX should be using DoH at the other end anyway, because the resolver the DoX box is using might have SRV blocked?

moparisthebest, some people under the umbrella of the IETF thought htat

that’s a difference.

it's probably too late though, since most devices will be using it soon enough

maybe I should switch trades and learn something which isn’t being botched awfully

jonas’, for example what? 🙂

ha I've often thought about that :P

zinid, I don’t know

I think every other industry is polluted by this shit

anything which has settled more than IT has

maybe academics, but it's totally biased, full of ad hominem and groupthinking

Every other industry isn't 50 years old

isn’t *just*

sustenance farming

Potato farming, in the woods?

sure

Kev, the resolver I'm running currently upstreams to random DNS-over-TLS servers, but someone is writing a prosody module now to go dox -> doh >:)

jonas’, probably to switch the IT niche, but it will be very marginal, if you try to up your head a bit you get it into Google shit 🙁

yeah, layer 1 through 3 are nice

jonas’, let me tell you about QUIC

oh yes, QUIC...

moparisthebest, that’s above layer 3

A dream of SCTP :(

suddenly they found out that it takes time to adopt SCTP, so let's do everything at layer3 !!!

faster!!!

layer 3 isn’t going to change anymore, look at how long it takes to deploy v6 ;-)

what?

I’ll just leave now, this isn’t good for my mental health

application layer

application is 7 or something

don’t scare me like that, zinid

in OSI?

yeah

okay

3 is IP

yeah, probably

don’t scare me like that

I treasure layer 3 as my refuge where I go when I feel sad.

but uh, many (most?) middle boxes block any IP that isn't UDP or TCP so....

moparisthebest, that’s layer 4

UDP and TCP aren’t IPs

which is why QUIC is over UDP, not IP

QUIC is over UDP is over IP

A dream of IPSec, but we got TLS instead :(

tl;dr layers don't matter anymore, forget everything you knew about them

Zash, IPsec is a horrible mess though

moparisthebest, they do matter, up to and including 3

which is why I say 1-3 are sane, everything above is madness

jonas’: And TLS ain't?

Zash, point taken

you can't do anything with IP though, other than UDP or TCP is what I mean jonas’

TLS seems to have taken on the role of IPSec

moparisthebest, working on the infrasturcture which allows UDP and TCP to flow is fun enough and enough "doing something with it"

jonas’, I'm told OSI is a horrible mess, but I don't think it was that bad, in comparison with what we ended up

where we don't have layers anymore

total leak of abstractions from layers to layers back and forth

anyone complain about that with that XMPP SASL thing that needs TLS info? :P

sure, I complained

I can find the complaint in the ML if you like

basically, layer violations are bad unless they give you something good and then they are good

ah, those good intentions

I bet DoH people had good intentions

or maybe it was just Google assasins?

anyway, the major threat will be of course CDNs, not DoH or DoX will help you because you won't be able to do peer-to-peer connections anymore

probably even ICMP will be blocked, lmao

ICMP is already mostly blocked

but what's blocking peer-to-peer connections?

well I mean there will be no route to host

other than, lack of ipv6 deployment

moparisthebest, routers are being replaced by CDNs, google builds farms of CDNs connected via private channels, and ISPs almost don't invest into cables anymore

moparisthebest, IPv6 deployment requires ICMP6, for path MTU discovery.

lots of networks block it though, and it seems to work... but I know what you mean

so *I* think the future of the internet is your "last mile" ISP connected to a CDN

so yeah, the industry is fucked up

I really don't know what you mean by CDNs replacing routers though

Like Google Global Cacehe?

there is a lot of effort towards meshnets too, bypassing all this "internet" crap :P

moparisthebest, how will you bypass the crap when your ISP is connected to google cdn directly and routes nothing?

https://github.com/cjdelisle/cjdns / https://hyperboria.net/ seems interesting/promising

there will be no routers, ISP is a last mile for your phone

then goes Google with CDN

are you saying it blocks everything but google? seems pretty far fetched, hopefully

no

it doesn't block anything, there ARE NOT anything except Google CDN server

there is a nice research paper showing the situation

I really should’ve left

I can't quite imagine a dystopia where that happens yet

I thought the same, but now we have DoH 😀

if anything that's anti-centralization, gives you a choice

with dns-over-tcp/udp you only have 1 choice, because your router/isp hi-jacks it and returns whatever they want

over TLS, you can connect wherever you choose

that goes for DoT, DoH, and DoX

yeah, good luck trying to beat it with the technology 🙂

it's all I have

The problem with SCTP is mostly middleboxes.

given that ISP have no zero incentives to build new routes, because 80% is routed to FAANG, why care?

few have the resources of google/amazon/apple/etc so all we have is tech to battle with

*have now

moparisthebest, especially when they now define tech

I.e. you not only have to support at the edges, but on each possible route between endpoints

yeah, same problem as IPv6 basically

that's why QUIC is over UDP instead of IP

they've essentially said "fuck it, impossible" to making new IP-based protocols

Even though I too have the same thing about crossing OSI layers, I appreciate the practical thinking here.

I'm not convinced it's practical, at least no urgency, so better to define a strategy on moving to SCTP

really, what urgency?

I don't buy efficiency, because the application layer protocols are already horribly inefficient

there is the "ideal" way which most people generally agree on, but might be impossible to achieve practically

then there is the "a bit crappy but works" way which can be used *now*

balancing them is rough

*now* is a good argument in the case of IPv4, because the address space is over

but with TCP?

btw, just in case, you can incapsulate SCTP into UDP, there is even an RFC for this

QUIC doesn't replace TCP, it replaces TCP+TLS

I think the main benefits are reduced RTTs, and eliminating head-of-line blocking

I'm sure there are more

yeah, reduce RTT in order to download bloated JS pages

soon bloated WASM pages :D

soon?

gotta keep up

moparisthebest: indeed, you can get to 0 round-trips for known endpoints.

moparisthebest: another interesting one is that you can keep a connection even if your IP changes (e.g. when switching between cellular and wifi)

ah right that's handy too

There are also some benefits regarding how QUIC packets are encrypted and authenticated

This is an interesting piece: https://tools.ietf.org/html/draft-joseph-quic-comparison-quic-sctp-00

Although I'm sure it is not up-to-date with the latest, this gives some more details of why it trumps SCTP and/or TCP in various areas.

so, XMPP-over-QUIC would mean you could do away with Stream Management I think?

and XEP-0397: Instant Stream Resumption

One other thing I found interesting is that, compared to Google QUIC, they tweaked IETF QUIC headers to allow for multiplexing with STUN/TURN/etc on the same port. https://tools.ietf.org/html/draft-aboba-avtcore-quic-multiplexing-03

moparisthebest: yes

and starttls

(as TLS 1.3 is baked into QUIC)

incoming XEP-0368v2: SRV records for XMPP over QUIC

hehehe

I suppose you can just use _xmpp-client._udp for this

I'll probably off this boat

zinid: at least read that comparison draft I linked. You might find it interesting to know why people have bothered with QUIC.

ralphm, I read it before obviously

and it mostly describes how cool QUIC is

but, old google QUIC or new IETF QUIC because quite different

I have no incentive to implement QUIC, I have no practical problems with TCP, and note that I manage highload with millions of connections

I think this is related to Google grade clusters

and others just swallow it

sure if you ignore all the *other* benefits I guess

RTT is not a problem for me at all

it's certainly not about "handling more connections"

moparisthebest, I still think it's not a worth to ruin everything and rebuilding from scratch

and putting packets framing into user land

zinid: I don't think it is ruining everything.

okay, but I do

so I said I'll implement this the latest

when customers and users will jump on my head

things change, when TCP was invented, people switching IPs regularly mid-stream was not-a-thing, now *most* computers do this

RTT is definitely an issue when you establish many connections and/or in non-reliable networks. The latter is especially true in mobile context.

moparisthebest, but this is solved by SCTP

so far the only somewhat valid arguments I hear is all SCTP can do as well

If you work in an office, then take the elevator to the ground floor, stopping on a few floors, exit the building, how often do you think you switch networks?

SCTP is impossible to get on the internet, it's over

moparisthebest, internet is over

There's so much ossification in existing networks that deploying SCTP in a meaningful way is a non-starter. This is not fatalistic, just realistic.

ralphm, I switch the networks everytime, I don't feel discomfort, stream management works for me

ok, now implement that for all other network connections

or, just once, in QUIC

It does, but there's latency involved due to roundtrips. With QUIC you might achieve 0 RTT to resume.

ralphm, what latency? 1 sec vs 0.1 sec?

I'm fine with that

might be 30 seconds

and might be an hour, sure

If someone writes a QUIC library, putting XMPP on top should not be hard

but if you don't want change why are you using this new fancy XMPP stuff, SMTP works fine for messaging

also manage your servers via telnet

zinid: well, I looked at networks in developing nations, and things aren't that bright.

okay, so why we cannot incapsulate SCTP into UDP once again?

there is an RFC

look at you trying to re-invent QUIC here

>:)

Why would that be better than QUIC, which actually has a lot traction?

moparisthebest, but that RFC was before QUIC, so who is reinventing?

But is it better?

depends on what is better and for whom?

For getting to a place where people can benefit from its properties. Not just theoretically, but in practice.

I see 😀

plus it doesn't bundle TLS which is a huge benefit, for RTTs and other things

moparisthebest, regarding telnet and smtp: why aren't you going to matrix?

I'm happy for Matrix to exist. They have different ideas. We'll see how that works out.

I like XMPP better so far

seems good enough at adapting to new tech too

moparisthebest: I hear that often around these parts 🤣

moparisthebest, yeah good answer 🙂

so I said like 100 posts above I like TCP so far 🙂

zinid: good, but that doesn't mean QUIC is useless, does it?

ralphm, obviously anything is useful for something

I guess that's even one of the great advantages zinid , when my clients are all connected to my server over QUIC and you are connected via TCP, we'll still be able to talk :D

for someone

<3 XMPP

get your dirty unicode out of here ascii will always be enough for me <3

/s :D

)-:

❤ looks like a farting rocket in the font that I'm using.

bah, client auto-replaced that. 😕

What's wrong with you?

many people have wondered.

Guus, screenshot? I want to see the farting rocket

https://xmpp.igniterealtime.org:7483/httpfileupload/b01dd842-a71f-40bf-be54-9867eb1bb640/pkfpUGLnRJCG_R6lQOmxRg.jpg

but that looks like a dick

and people ask what's wrong with _me_ 🙂

a short dick

zinid, you are thinking of 3===D-----

Ok, this escalated quickly

I see that the quality of discussion here has been improved. My work here is done.

I'm dying of laughter over here

Please don't die!

(if you must, laughter is a good way to go though)

is that a XEP? Kill people over XMPP?

<mechanism>laughter</mechanism>

Maybe as an extension to https://xmpp.org/extensions/xep-0132.html

LAUGHTER

sasl mechanisms are in all CAPS

I've often wanted a mechanism to slap users in the face over the internet

I prefer not to authenticate when killing people online.

I see total RFC violation here, we need a police

moparisthebest You'll be rich and famous.

moparisthebest: so XEP-0132 is just the thing for you.

moparisthebest, since you appeal to practice, how do you find federation practical? Sounds like contradicting statements to me

over 15 years of federating it has failed everywhere

*after

You chatting here seems to contradict your point.

ralphm, no, we're in a bubble here

also, prove me wrong, append federation success stories to xmpp.org pages close to the list of walled gardens of the XMPP

I look at mastodon and matrix and scratch my head: what are they doing?

they didn't learn our lesson? they think they will be lucky this time?

bitcoin!

also marginal, hyped though

I've tried to explain this before, but the supposed failure/demise of having large swaths of users on the federated Jabber network is mostly not a technical issue.

ralphm, does it matter?

I mean what issue exactly lead to a failure

It does, I can personally address technical issues. Product/business choices of companies, or social issues, or funding issues, or UX ones, not so much.

zinid, SMTP and HTTP seem to be pretty good examples of successful federation, even if you ignore XMPP

moparisthebest, yeah, happened before FAANG, still alive, also, very uneven distribution as noted many times

and SMTP is PITA to self host

and failed in the sense I pointed above: you either have a marginal network, or power-law

xmpp/mastodon/matrix is marginal, smtp/http - power-law

I don't think "many users on a few servers" is a flaw of federation, nothing wrong with that in my opinion

It took many, many years for SMTP to get to where it is in terms a federation. Email had so many different vendors and protocols.

the point is you can run your own and it works

moparisthebest, so, basically a bubble

and running your own SMTP is a hard task

zinid, I wonder

you've been kicking and screaming for a couple of months now

basically expressing discontent with anything

kicking and screaming

okay

I leave this chat

what is your intend...ed end goal here?

... I should have worded that differently.

Then again, it's not as if he's a master of subtlety. 🙂

(is that a word?)

Subtlety is definitely a word.

I was genuinely interested in why he acts so negative all the time. It's not very productive, nor do I think it's something that's motivating him personally. Live must be tough if you only get to work with stuff that's all of the characteristics that he gives to XMPP.

oh, he left

was going to say running your own SMTP is a nightmare unlike XMPP but meh

if anything, that proves it's not "ease of use" or whatever that makes federation a success or not, XMPP is way easier

my guess is that SMTP pre-dates businessmodels for silos.

Network effect, everything else is subjective

if I had to guess I'd say that was it

which is kind of why, today, if we want nice things HTTP/browsers have to push them, no one else has the pressure to get nice things :D

There was silos in email but they failed somehow

XMPP is nice things, even if it's not pushed to the masses in a truly federated way.

Zash, I don't think there were. You could always federate with other mail accounts?

unless you're not talking about things like Exchange, GMail, etc?

Something something fidonet era stuff

Silos, like AOL mail, failed because users demanded connectivity

before my time.

I wasn't around either

Guus, yea I meant "nice things" as in ability to connect despite port blocking, new protocols like QUIC etc

At this point, I only see this happening through some antitrust measure.