XSF Discussion - 2022-02-14

moparisthebest, websockets and other alt transports were introduced for client adoption/improvement especially due to mobile and the shift towards web technologies. honestly, i don't think any effort in alt s2s transports would be as beneficial as effort rather put into c2s transport improvements. if anything, i see it introducing more complexity into a portion of the stack that is already stable and established.

(last line of that was directed at intro of alt transports into s2s)

junaid, why not both though? I mean, why create a new c2s transport and not just go ahead and also make it useable for s2s ?

moparisthebest, i didn't say "no" but rather focused on the benefit that would be derived by such s2s efforts. like any community, we ultimately have a finite amount of resources. separately, for s2s, i don't see websockets/sse/other-new-hotness showing a significant improvement against straight-up TCP connections between always-on servers. for c2s on the other hand, i figure we need to have a deep think about how to streamline our approach and (hopefully) choose a route that's more extendible going forward. sse yesterday. websockets today. new-hotness tomorrow.... i don't think it's wish to burden server dev teams with keeping up with the latest web trends like that 😁️

s/think it's wish/think it's wise/

junaid, quic for example seems to have very good benefits for both c2s and s2s

websockets, maybe, maybe not, but I'd argue if you have c2s support it's trivial to add s2s support for any transport

I do not know whether this is a good idea or not, but I do know that just because something is trivial doesn't make it a good idea or mean you should do it. Any claim that we should do anything because it's trivial should be viewed with extreme skepticsism.

I agree with Sam. The question is not, or at least not only, about whether the coding effort seems trivial. In practice, introducing another transport forces everyone (server devs, XMPP and firewall admins, monitoring DevOps) to implement and offer both the existing and the new transports for interop. So there's yet another code path that needs testing, there's additional monitoring complexity, and it makes debugging harder. So if the idea is this comes with no cost, I'd disagree.

Just offering both STARTTLS and XMPPS can already be annoying in these regards.

Also additional documention and support complexity.

moparisthebest: no problem! Yeah maybe keeping 156 around for Bosh and to keep Bosh in compliance suite 2022 is a bit less brutal

I also don't see the point in ws s2s, if it doesn't solve a problem, it's unnecessary complexity

Plus there is already a replacement in the work with unreliable message support. Wb features have been deprecated/removed before and so might Websocket.

Web features*

What problem is xmpps-s2s solving then?

Latency!!!

Ah yes, indeed, latency was too low, waiting for more DNS queries solves that nicely.

🙂

I'm still skeptical about touching security things for vanity reasons like latency and problems like restrictive firewalls that really should be solved elsewhere if we could have nice things.

QUIC has nothing to do with restrictive firewalls, but it does bring many nice things as a replacement for TCP+TLS that I think equally apply to S2S

Isnt quic horribly complex to implement? Thats what i have heard at least

at what level ?

from an application point of view it's the same as TCP+TLS, if not a bit easier, in both cases you import your library that handles it for you and get a stream from it

hopefully no XMPP clients or servers are currently rolling their own TLS library, and therefore also won't roll their own QUIC library?

moparisthebest: I would've thought it's somewhat tailored towards typical web client use cases (short-lived queries of many resources via unreliable networks)? I.e. optimization of connection establishment, roaming, multiplexing?

Sure. But sometning being more complex means less implementations. Which leads to less choices, less community participation etc... See matrix, web browsers

Holger, I looked into QUIC for a side project, and it seemed to be quite useful for XMPP actually

c2s anyway, because of the very efficient roaming

Yes I'll easily buy it for c2s. L

Holger, ah, well we only have google to blame for the naming confusion because they originally called http3 quic, but names have been shuffled around

This was about s2s specifically.

quic is a drop-in replacement for tcp+tls

h3 is a layer on top of quic, like http1/http2/xmpp is a layer on top of tcp+tls

(more like SCTP+TLS or multi-path-TCP+TLS even) ✏

Yes and I thought the replacement was about these topics mainly but whatever.

You say it brings 'many nice things' to s2s, I'm clueless and was just asking 'which things?'.

just off the top of my head benefit wise: 1. there is free roaming (switching IPs without terminating connections), which you could fairly say applies much more to clients than servers, but my server runs in my closet and I have a dynamic IP, so that's not universally true 2. multiple independent streams with only 1 encryption context and no head-of-line blocking, so piggybacking without head-of-line blocking 3. stream resumption but at the quic-level, so if your internet drops out for a minute, you don't need to re-establish any connections

TCP can handle hours of network outage if you let it

then just combine #3 with #1

> 1. there is free roaming (switching IPs without terminating connections), which you could fairly say applies much more to clients than servers, but my server runs in my closet and I have a dynamic IP, so that's not universally true this doesn't really help you in s2s, if both servers have a dynamic IP and switch IPs around the same time.

so you need strategies for that anyway

that sounds like a pretty unlikely edge case, it still helps you in the majority of cases though right ?

And there was something I remember about QUIC being incompatible with either OpenSSL or TLS itself, so a huge chunk of the current network stack would need to be replaced and I'm unconvinced of the ROI

no, in the majority of cases it doesn't matter

not mine :)

because the majority of servers have static IPs :) ✏

"oh no we have to replace openssl" the horror...

shoulda done that about a decade ago

moparisthebest: Ok yes that's mostly what I had in mind, thanks.

moparisthebest: Your dynamic IP address will only change every now and then, no? We're talking about TCP-TLS's reconnection latency in that situation?

I *think* you can keep connections open across service restarts in theory, though I don't know if any existing libraries support something like that

yep, so far my dynamic IP only changes about every 6 months so I don't care, but they guarantee nothing about it

Hmm, not sure I'm sold 🙂

maybe QUIC makes people more likely to run servers on their phones, the people who like p2p anyway :)

(keeping connections open is nice and all, but saving the state on top of those connections makes it typically not worth it.)

I've already known 2 people who have done this for awhile

I would think the real issue we see with s2s in practice is reliability, no matter whether the address is dynamic. If QUIC brings some magic fix for that, I *am* sold.

I'm somewhat afraid we'll only see that benefit in the beginning, while bad middleboxes only fiddle with TCP stuff like keepalives, QUIC should be much better until they catch up...

moparisthebest, I’ve had Prosody running on my phone for more than a decade, it just works and since my ISP gives me a static IPv6 it can even federate with other servers living in the 21st century.

my ISP briefly handed out some ipv6 addresses once upon a time then just quit :'(

But of course, I mostly keep it to testing.

moparisthebest, wat, why?

don't ask me, I've never been able to reach anyone on the phone that knows what ipv6 is

^^'

Maybe time to switch to a better ISP?

same company that was a big sponsor of world ipv6 day some years back too

haha good one

man imagine having more than 1 choice for ISP, what a world that would be...

Wait, there's more than 1 ISP?

Here I’ve had a static IPv6 /60 (splittable in 16 subnetworks) and an IPv4 since 2007.

(That is only sort of a joke)

Sam, oh it's a joke, just not a haha funny one

moparisthebest, which country do you live in? :/

USA, local cable company is the only ISP

Oh my…

My condoleances.

Yah, the internet situation in the U.S. is *really* bad

Almost typed "cabal company", then went to correct it and decided it was fine as is.

haha so true

Hi, kind reminder to place the GSoC 2022 flyer in hacker-spaces, unis etc if you want to support this event. Please check before if you are allowed to place such things. https://xmpp.org/community/gsoc-2022/ List of hackerspaces, may in your corner: https://wiki.hackerspaces.org/Category:Hackerspace Let's spread the word!

But yah, most of the time the local cable company who *really* wants you to subscribe to their cable package and not netflix or whatever is the only option. You can imagine how that goes.

I've been trying to start a little co-op WISP in my town for ages, but no one else seems to think it's a problem that they're being charged a huge amount for terrible internet that's out most of the time.

I should be grateful, I hear it can be much worse than I have it, at least I don't have comcast I hear ?

I have like 5 ISPs to choose from but they all have to deliver though the building/landlord-company infrastructure which is not IPv6-capable (despite I think newer than IPv6 launch day)

Oh boy, yah, I lived in an area where comcast was the only provider for a while, they were *way* worse than AT&T (not that AT&T is good, but they're better)

Used to be more ISPs, but some of them bought the others and then got bough by the former state telco monopoly...

used to be time warner here, now it's spectrum/charter

Actually, I may *technically* have a choice because Spectrum sends me at least one flier via snail mail every day (no really, I'm not being hyperbolic, sometimes I even get two on the same day), so presumably they're in my area too

Anyways, bad ISP rant over. Sorry. Thanks for commiserating moparisthebest.

+1