XSF Discussion - 2018-11-16

MattJ, this does not really answer the question for what you use it, i wonder too what use case this could have

maybe something like teamwork, where different people in a groupchat can add stuff to a message?

something like threads ^^

seems converse shows now in front of every groupchat message a green checkmark i wonder what it means

hm we could use it for omemo because right now we cant send a message AND a httpupload link

this way we could send pictures with comments but encrypted

daniel ^

lovetox: it's 0184 I think, the checkmark

i dont think so, that would make absolutly no sense at all

i think it means the message was reflected by the muc

but instead of now seeing on *every* message a green check mark, i would have opted for seeing a red mark for the 1 in 1000 messages that is not received because the muc is down or my connection

ok they recently added 0184

wow now i know one of the 100 participants of this chat received my message

useful

I think in groups the checkmark should be generated by the reflection

That's how Conversations does it

In 1:1 it uses 184. In groups it's reflection. Same UI to the user

Makes sense

didnt look through the code, lets assume they did that 🙂

daniel [08:07]: > In 1:1 it uses 184. In groups it's reflection. Same UI to the user Same in yaxim

MattJ, I’m asking because somebody is attempting to use attaching for quotations

and I think that would lead to suboptimal UI if clients show the "quoting" message right below the other one

(which is however a sensible UI for attachments)

we have some other xep for quoting

references or something like that

yes

jonas’, I agree with you

:/

MattJ, tell that to them: https://github.com/siacs/Conversations/issues/3125 ✏

I think I have an outstanding diff for that XEP anyway

granted, in my original critique I forgot to mention *how* clients display it

("out of order", which may be more grave than what sam expects)

Don't have time today

ah, right

With the recent news around http/3, I was wondering if anyone here has thought about a QUIC binding for XMPP.

ralphm, what would the advantages be, besides "it's http"?

I'm especially interested in the decrease in required roundtrips and if it behaves more efficiently in mobile networks (compared to TCP).

I'm talking about QUIC, not http/3 (which is HTTP-over-QUIC).

but isn't http-over-quic http/3?

ahh now I got it

don't we have most round trips on the xmpp protocol layer? I don't see how quic would e.g. decrease the SASL roundtips. But I'm curious if there are any other advantages of using quic, but right now, I can't think of any.

Doesn't quic have multipath tcp basically

(because using multipath tcp directly would be too sane?)

So we wouldn't have to reauth after every network change

> (because using multipath tcp directly would be too sane?) Nobody supports that and quic has the power of Google behind it

Well, from what I understand, the initial setup, which incliudes TLS 1.3, would be a nice benefit.

daniel, yes, talking about google etc. not using existing IETF standards and rolling their own instead

Right. But if you can't stop them you could at least benefit from it

(I don't actually have any stakes or opinion in Quic or xmpp over quic)

ahh that multipath fature sure would be nice

There's a nice picture here: https://www.zdnet.com/article/http-over-quic-to-be-renamed-http3/

also it appears that XMPP over QUIC would be for most parts trivial

like you could replace your languages Socket object with a QuicSocket object and be done

I could also see a use for in-(quic)-band file transfers, but that's indeed a bit more advanced.

ralphm: a mobile client has too many roundtrips to count, _after_ the TLS handshake

ralphm: I made a proposal to have the client dump all desired connection state into bind2, and let the server figure out everything

Ge0rG, but that is only true for the intital connection

Ge0rG: I know this, but the SASL-2 suggestions from dwd could help with that.

So sure, there's work to be done on both fronts

if you mostly resume your xmpp connection using quic the round trips should go down to near zero

flow: 0198 also has a bunch of round-trips, at least the one you need to ensure whether the session got resumed

Ge0rG, I dunno if xep198 would be that involved when using quic

hmm it also appwars that quic is a IETF thing, at least there appears to be an IETF WG

> Ge0rG, I dunno if xep198 would be that involved when using quic At least the resume part

You'd still need the acks

daniel, do you?

I mean there are still nice

I don't think quic has acks

but if the resumption of the stream is performed on the quic layer, without the upper layers being bothered

hmm I though quic has stream properties, but could be wrong

you know, TCP has got acks, and if we had sane APIs instead of Unix sockets, we could actually query the TCP ack state from the OS and not need 0198 acks.

true, that is why I said acks are still nice, but I'm not sure if you still need xep198 resumption when using quic to handle a network switch

I also believe that unix sockets are sane APIs and that you don't get nothing by checking the TCP ack state

cause eventually you want application protocol acks, which tcp acks are not

I guess that's the upshot of QUIC, it moves this to userland.

yes, because re-implementing decade-proven stuff in userland is always good /s

yes, because re-thinking decade-proven stuff is never a viable approach.

it's not about re-thinking it but about working around limitations in its entrenched implementation

Indeed. I think QUIC is a very interesting development, and was just curious if it could benefit XMPP, too.

somebody should do a quic prototype.

Ge0rG: I see what you did there

Hey, my summit announcement blogpost didn't pop up in the blog. Did I mess something up?

There are some interesting comments about QUIC here: https://www.codavel.com/2018/09/17/quic-vs-tcptls-and-why-quic-is-not-the-next-big-thing/. Despite the title, it seems the benefits for something like XMPP might be greater than for HTTP.

surprisingly, HTTP is slowly approching XMPP, protocol-wise

not sure if I'd call it surprisingly, but true, true

HTTP/2 seems an awful lot like SSH

And WS is a TCP socket exchanging framed messages.

Mhm

Like Beep

Hmm, not sure I see the benefits of QUIC specifically

...given in-order requirements in XMPP, and a single stream between client and server

Something something having two channels could be useful for large binary low-priority transfers

SCTP :(

RTT reduction is already possible without QUIC, and changing IP is just 198

:(

RIP SCTP

mattj: do you work at google? they seem to think that way

fippo: regarding SCTP? I tried to keep the dream alive for quite some time, but short of renaming to HTTP/4, it's never going to see sensible adoption

:(

MattJ: Could change IP with less overhead if MPTCP got done and deployed

Oh and SCTP is deployed and used! .. in WebRTC

SCTP over DTLS over UDP

:<

well, google wants to kill that

and usrsctp is the only usable library and has funding issues :-|

I think mattias wimmer (of jabberd1) once proposed s2s over sctp...

MattJ, I'm not sure, but QUIC could get you free instant stream resumption it appears

and i'm not sure how xmpp's in-order requirement is related to quic

QUIC's main purpose is multiplexing without head-of-line blocking. XMPP needs neither of those

The other things QUIC provides can be done with TCP

you mean "on top of TCP"

Sure

sure, but quic gives you resumption for free

So instead of reimplementing TCP semantics on top of UDP

you don't have to implement xep198 resumption

MPTCP would also give you that

probably, in the end the surviver will likely be the thing with widely available libraries

and which works in the current IP environment

Which QUIC is not from a glance

(in reality, and not on paper)

XMPP over HTTP over QUIQ over DTLS over UDP with ugly hacks to make it look like plain text DNS?

quic libraries seem to be sparse, true

flow: Do you think we should just go along with stupid things like that or try to do it right? Because I want to do things right.

but it doesn't appear to be unlikely that there will be some for android (and java), possibly even from google itself

Zash, well, doing things right is usually what one should do, but I don't see how quic is doing things wrong, feel free to feed me the missing pieces

I haven't looked at QUIC recently, but isn't it supposed to be a transport protocol? So, running it over another transport protocol is meh

I don't see a point for sticking to the OSI model just for the sake of it

it appears sensible to run such a thing over udp

HTTP over UDP was a thing already tho

"it breaks layering" is never a good argument, unless it is followed by an argument why it is bad

Or what layers are

An Ogre is like an onion...

right now I think of quick as an TCP socket on steriods with tls, compression, automatic resumption in case of connectivity/network change

and looking at the XEPs we have, those are propertys XMPP also wants

it is true that XMPPs doesn't need quic's multiplexing feature, but, yah know, nobody forces you to use it

then again, didn't we have a XEP (or ProtoXEP) which multiplexes multiple sessions over the same stream?

for s2s

MattJ: flow, of course the number of libraries is still a bit sparse. QUIC is not even finished yet.

And to be sure, Google QUIC was taken apart to IETF QUIC (with a handful of specs) + HTTP-on-QUIC.

Some background here: https://blog.cloudflare.com/the-road-to-quic/

Guus, I think I know what went wrong with your blog post

it went into some "drafts" folder

my suspicion is that it treated the publish timestamp as UTC, and since that was greater than the time of the build, it treated it as unpublished draft

I retriggered the build

ah, I didn't take notice much of the timestamp

(you can see that it went into some draft folder by searching this https://hub.docker.com/r/xmppxsf/xmpp.org/builds/bgajpfwqegw7nfzcthinnui/ for the file name)

(and you can find the build by clicking the "docker|building" tag thing in the readme after a merge)

That's some kind of implementation that can be used to schedule posts, then?

it could, if we had automatic rebuilds

well, thanks for figuring that one out 🙂

you’re welcome

thanks for boarding :)

where are my warm nuts?

I have questions about that question

wait, don't answer that one.

it’s either delicious or TMI

I _just_ realised.

and here I was wondering which double-entendre I could’ve missed in "thanks for boarding" which doesn’t go into the direction of airplanes or torture.

Ok, I'm off to pick up my kids from daycare, before I make more of a fool of myself here. 🙂

good luck!

(I shall be making a fool of myself elsewhere now)

you’ll blend in

SCTP got some adoption as part of WebRTC, but now there are discussions about replacing it with QUIC too.

Guus, your blog post is up :)

At the last Rustfest in Paris, there was someone working on a QUIC parser, but I don’t remember who, nor what kind of milestone they reached.

Yeah I remember one guy implementing a bunch of stuff from the spec during the impl days

Link Mauve: I also found this https://tools.ietf.org/html/draft-aboba-avtcore-quic-multiplexing-02, and https://w3c.github.io/webrtc-quic/

I.e. the QUIC WG actually made changes to the initial packet byte to accomodate multiplixing with RTP/STUN/etc.

jonas’: tx!