-
lovetox
MattJ, this does not really answer the question for what you use it, i wonder too what use case this could have
-
lovetox
maybe something like teamwork, where different people in a groupchat can add stuff to a message?
-
lovetox
something like threads ^^
-
lovetox
seems converse shows now in front of every groupchat message a green checkmark i wonder what it means
-
lovetox
hm we could use it for omemo because right now we cant send a message AND a httpupload link
-
lovetox
this way we could send pictures with comments but encrypted
-
lovetox
daniel ^
-
pep.
lovetox: it's 0184 I think, the checkmark
-
lovetox
i dont think so, that would make absolutly no sense at all
-
lovetox
i think it means the message was reflected by the muc
-
lovetox
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
-
lovetox
ok they recently added 0184
-
lovetox
wow now i know one of the 100 participants of this chat received my message
-
lovetox
useful
-
daniel
I think in groups the checkmark should be generated by the reflection
-
daniel
That's how Conversations does it
-
daniel
In 1:1 it uses 184. In groups it's reflection. Same UI to the user
-
MattJ
Makes sense
-
lovetox
didnt look through the code, lets assume they did that 🙂
-
Ge0rG
daniel [08:07]: > In 1:1 it uses 184. In groups it's reflection. Same UI to the user Same in yaxim
-
jonas’
MattJ, I’m asking because somebody is attempting to use attaching for quotations
-
jonas’
and I think that would lead to suboptimal UI if clients show the "quoting" message right below the other one
-
jonas’
(which is however a sensible UI for attachments)
-
lovetox
we have some other xep for quoting
-
lovetox
references or something like that
-
jonas’
yes
-
MattJ
jonas’, I agree with you
-
jonas’
MattJ, tell than to them: https://github.com/siacs/Conversations/issues/3125✎ -
MattJ
:/
-
jonas’
MattJ, tell that to them: https://github.com/siacs/Conversations/issues/3125 ✏
-
MattJ
I think I have an outstanding diff for that XEP anyway
-
jonas’
granted, in my original critique I forgot to mention *how* clients display it
-
jonas’
("out of order", which may be more grave than what sam expects)
-
MattJ
Don't have time today
-
jonas’
ah, right
-
ralphm
With the recent news around http/3, I was wondering if anyone here has thought about a QUIC binding for XMPP.
-
flow
ralphm, what would the advantages be, besides "it's http"?
-
ralphm
I'm especially interested in the decrease in required roundtrips and if it behaves more efficiently in mobile networks (compared to TCP).
-
ralphm
I'm talking about QUIC, not http/3 (which is HTTP-over-QUIC).
-
flow
but isn't http-over-quic http/3?
-
flow
ahh now I got it
-
flow
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.
-
daniel
Doesn't quic have multipath tcp basically
-
jonas’
(because using multipath tcp directly would be too sane?)
-
daniel
So we wouldn't have to reauth after every network change
-
daniel
> (because using multipath tcp directly would be too sane?) Nobody supports that and quic has the power of Google behind it
-
ralphm
Well, from what I understand, the initial setup, which incliudes TLS 1.3, would be a nice benefit.
-
jonas’
daniel, yes, talking about google etc. not using existing IETF standards and rolling their own instead
-
daniel
Right. But if you can't stop them you could at least benefit from it
-
daniel
(I don't actually have any stakes or opinion in Quic or xmpp over quic)
-
flow
ahh that multipath fature sure would be nice
-
ralphm
There's a nice picture here: https://www.zdnet.com/article/http-over-quic-to-be-renamed-http3/
-
flow
also it appears that XMPP over QUIC would be for most parts trivial
-
flow
like you could replace your languages Socket object with a QuicSocket object and be done
-
ralphm
I could also see a use for in-(quic)-band file transfers, but that's indeed a bit more advanced.
-
Ge0rG
ralphm: a mobile client has too many roundtrips to count, _after_ the TLS handshake
-
Ge0rG
ralphm: I made a proposal to have the client dump all desired connection state into bind2, and let the server figure out everything
-
flow
Ge0rG, but that is only true for the intital connection
-
ralphm
Ge0rG: I know this, but the SASL-2 suggestions from dwd could help with that.
-
ralphm
So sure, there's work to be done on both fronts
-
flow
if you mostly resume your xmpp connection using quic the round trips should go down to near zero
-
Ge0rG
flow: 0198 also has a bunch of round-trips, at least the one you need to ensure whether the session got resumed
-
flow
Ge0rG, I dunno if xep198 would be that involved when using quic
-
flow
hmm it also appwars that quic is a IETF thing, at least there appears to be an IETF WG
-
daniel
> Ge0rG, I dunno if xep198 would be that involved when using quic At least the resume part
-
daniel
You'd still need the acks
-
flow
daniel, do you?
-
flow
I mean there are still nice
-
daniel
I don't think quic has acks
-
flow
but if the resumption of the stream is performed on the quic layer, without the upper layers being bothered
-
flow
hmm I though quic has stream properties, but could be wrong
-
Ge0rG
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.
-
flow
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
-
flow
I also believe that unix sockets are sane APIs and that you don't get nothing by checking the TCP ack state
-
flow
cause eventually you want application protocol acks, which tcp acks are not
-
ralphm
I guess that's the upshot of QUIC, it moves this to userland.
-
jonas’
yes, because re-implementing decade-proven stuff in userland is always good /s
-
ralphm
yes, because re-thinking decade-proven stuff is never a viable approach.
-
Ge0rG
it's not about re-thinking it but about working around limitations in its entrenched implementation
-
ralphm
Indeed. I think QUIC is a very interesting development, and was just curious if it could benefit XMPP, too.
-
Ge0rG
somebody should do a quic prototype.
-
daniel
Ge0rG: I see what you did there
-
Guus
Hey, my summit announcement blogpost didn't pop up in the blog. Did I mess something up?
-
ralphm
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.
-
Ge0rG
surprisingly, HTTP is slowly approching XMPP, protocol-wise
-
flow
not sure if I'd call it surprisingly, but true, true
-
Zash
HTTP/2 seems an awful lot like SSH
-
Ge0rG
And WS is a TCP socket exchanging framed messages.
-
Zash
Mhm
-
ralphm
Like Beep
-
MattJ
Hmm, not sure I see the benefits of QUIC specifically
-
MattJ
...given in-order requirements in XMPP, and a single stream between client and server
-
Zash
Something something having two channels could be useful for large binary low-priority transfers
-
Zash
SCTP :(
-
MattJ
RTT reduction is already possible without QUIC, and changing IP is just 198
-
jonas’
:(
-
MattJ
RIP SCTP
-
fippo
mattj: do you work at google? they seem to think that way
-
MattJ
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
-
jonas’
:(
-
Zash
MattJ: Could change IP with less overhead if MPTCP got done and deployed
-
Zash
Oh and SCTP is deployed and used! .. in WebRTC
-
Zash
SCTP over DTLS over UDP
-
jonas’
:<
-
fippo
well, google wants to kill that
-
fippo
and usrsctp is the only usable library and has funding issues :-|
-
fippo
I think mattias wimmer (of jabberd1) once proposed s2s over sctp...
-
flow
MattJ, I'm not sure, but QUIC could get you free instant stream resumption it appears
-
flow
and i'm not sure how xmpp's in-order requirement is related to quic
-
MattJ
QUIC's main purpose is multiplexing without head-of-line blocking. XMPP needs neither of those
-
MattJ
The other things QUIC provides can be done with TCP
-
flow
you mean "on top of TCP"
-
MattJ
Sure
-
flow
sure, but quic gives you resumption for free
-
MattJ
So instead of reimplementing TCP semantics on top of UDP
-
flow
you don't have to implement xep198 resumption
-
Zash
MPTCP would also give you that
-
flow
probably, in the end the surviver will likely be the thing with widely available libraries
-
flow
and which works in the current IP environment
-
MattJ
Which QUIC is not from a glance
-
flow
(in reality, and not on paper)
-
Zash
XMPP over HTTP over QUIQ over DTLS over UDP with ugly hacks to make it look like plain text DNS?
-
flow
quic libraries seem to be sparse, true
-
Zash
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.
-
flow
but it doesn't appear to be unlikely that there will be some for android (and java), possibly even from google itself
-
flow
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
-
Zash
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
-
flow
I don't see a point for sticking to the OSI model just for the sake of it
-
flow
it appears sensible to run such a thing over udp
-
Zash
HTTP over UDP was a thing already tho
-
flow
"it breaks layering" is never a good argument, unless it is followed by an argument why it is bad
-
daniel
Or what layers are
-
Guus
An Ogre is like an onion...
-
flow
right now I think of quick as an TCP socket on steriods with tls, compression, automatic resumption in case of connectivity/network change
-
flow
and looking at the XEPs we have, those are propertys XMPP also wants
-
flow
it is true that XMPPs doesn't need quic's multiplexing feature, but, yah know, nobody forces you to use it
-
flow
then again, didn't we have a XEP (or ProtoXEP) which multiplexes multiple sessions over the same stream?
-
jonas’
for s2s
-
ralphm
MattJ: flow, of course the number of libraries is still a bit sparse. QUIC is not even finished yet.
-
ralphm
And to be sure, Google QUIC was taken apart to IETF QUIC (with a handful of specs) + HTTP-on-QUIC.
-
ralphm
Some background here: https://blog.cloudflare.com/the-road-to-quic/
-
jonas’
Guus, I think I know what went wrong with your blog post
-
jonas’
it went into some "drafts" folder
-
jonas’
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
-
jonas’
I retriggered the build
-
Guus
ah, I didn't take notice much of the timestamp
-
jonas’
(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)
-
jonas’
(and you can find the build by clicking the "docker|building" tag thing in the readme after a merge)
-
Guus
That's some kind of implementation that can be used to schedule posts, then?
-
jonas’
it could, if we had automatic rebuilds
-
Guus
well, thanks for figuring that one out 🙂
-
jonas’
you’re welcome
-
jonas’
thanks for boarding :)
-
Guus
where are my warm nuts?
-
jonas’
I have questions about that question
-
Guus
wait, don't answer that one.
-
jonas’
it’s either delicious or TMI
-
Guus
I _just_ realised.
-
jonas’
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.
-
Guus
Ok, I'm off to pick up my kids from daycare, before I make more of a fool of myself here. 🙂
-
jonas’
good luck!
-
Guus
(I shall be making a fool of myself elsewhere now)
-
jonas’
you’ll blend in
-
Link Mauve
SCTP got some adoption as part of WebRTC, but now there are discussions about replacing it with QUIC too.
-
jonas’
Guus, your blog post is up :)
-
Link Mauve
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.
-
pep.
Yeah I remember one guy implementing a bunch of stuff from the spec during the impl days
-
ralphm
Link Mauve: I also found this https://tools.ietf.org/html/draft-aboba-avtcore-quic-multiplexing-02, and https://w3c.github.io/webrtc-quic/
-
ralphm
I.e. the QUIC WG actually made changes to the initial packet byte to accomodate multiplixing with RTP/STUN/etc.
-
Guus
jonas’: tx!