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
lnjhas left
Str4tocasterhas left
Str4tocasterhas joined
Nekithas left
Nekithas joined
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
guusdkhas left
guusdkhas left
Nekithas left
Nekithas joined
lovetox
ok they recently added 0184
lovetox
wow now i know one of the 100 participants of this chat received my message
lovetox
useful
Nekithas left
Nekithas joined
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 🙂
Nekithas left
Nekithas joined
edhelashas left
edhelashas joined
Str4tocasterhas left
guusdkhas left
guusdkhas joined
Str4tocasterhas joined
Ge0rG
daniel [08:07]:
> In 1:1 it uses 184. In groups it's reflection. Same UI to the user
Same in yaxim
Zashhas left
remkohas joined
Str4tocasterhas left
Str4tocasterhas joined
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)
Zashhas left
Zashhas left
andyhas joined
lovetox
we have some other xep for quoting
lovetox
references or something like that
jonas’
yes
MattJ
jonas’, I agree with you
labdsfhas joined
jonas’
MattJ, tell than to them: https://github.com/siacs/Conversations/issues/3125✎
Zashhas left
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
Zashhas left
Steve Killehas left
Steve Killehas left
Zashhas left
ralphm
With the recent news around http/3, I was wondering if anyone here has thought about a QUIC binding for XMPP.
Steve Killehas joined
lnjhas joined
danielhas left
lovetoxhas left
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).
ThibGhas left
ThibGhas joined
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
lnjhas left
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.
vaulorhas joined
Ge0rG
it's not about re-thinking it but about working around limitations in its entrenched implementation
alacerhas joined
lovetoxhas joined
Alexhas joined
tuxhas left
ralphm
Indeed. I think QUIC is a very interesting development, and was just curious if it could benefit XMPP, too.
blablahas left
Ge0rG
somebody should do a quic prototype.
guusdkhas left
guusdkhas joined
daniel
Ge0rG: I see what you did there
Marandahas left
Marandahas joined
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.
alacerhas left
Ge0rG
surprisingly, HTTP is slowly approching XMPP, protocol-wise
blablahas left
Zashhas left
Str4tocasterhas left
Str4tocasterhas joined
Str4tocasterhas left
Str4tocasterhas joined
ralphmhas joined
flow
not sure if I'd call it surprisingly, but true, true
Zash
HTTP/2 seems an awful lot like SSH
rionhas left
alacerhas joined
blablahas joined
blablahas left
blablahas joined
Ge0rG
And WS is a TCP socket exchanging framed messages.
vaulorhas joined
Zash
Mhm
Str4tocasterhas left
Str4tocasterhas joined
Str4tocasterhas left
Str4tocasterhas joined
Str4tocasterhas left
Str4tocasterhas joined
Str4tocasterhas left
Str4tocasterhas joined
Str4tocasterhas left
Str4tocasterhas joined
Str4tocasterhas left
Str4tocasterhas joined
danielhas left
tuxhas left
blablahas left
blablahas joined
blablahas left
blablahas joined
blablahas left
blablahas joined
Str4tocasterhas left
Str4tocasterhas joined
lumihas joined
blablahas left
Str4tocasterhas left
Str4tocasterhas joined
moparisthebesthas left
Str4tocasterhas left
Str4tocasterhas joined
Str4tocasterhas left
Str4tocasterhas joined
valohas joined
valohas joined
Str4tocasterhas left
Str4tocasterhas joined
Zashhas left
Zashhas left
Str4tocasterhas left
Str4tocasterhas joined
lovetoxhas left
Str4tocasterhas left
Str4tocasterhas joined
Str4tocasterhas left
Str4tocasterhas joined
Str4tocasterhas left
Str4tocasterhas joined
ralphm
Like Beep
Zashhas left
guusdkhas left
blablahas left
blablahas joined
rionhas left
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
blablahas left
j.rhas left
Alexhas left
Yagizahas left
Str4tocasterhas left
Str4tocasterhas joined
Holgerhas left
blablahas joined
lovetoxhas joined
j.rhas joined
Str4tocasterhas left
Str4tocasterhas joined
Str4tocasterhas left
Str4tocasterhas joined
danielhas left
Str4tocasterhas left
Str4tocasterhas joined
blablahas left
blablahas left
MattJ
Hmm, not sure I see the benefits of QUIC specifically
alacerhas left
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
matlaghas left
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...
j.rhas joined
j.rhas joined
Str4tocasterhas left
Str4tocasterhas joined
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
Alexhas joined
waqashas joined
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
Zashhas left
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?
Nekithas left
Nekithas joined
mimi89999has joined
mimi89999has joined
jonas’
for s2s
Str4tocasterhas left
ralphm
MattJ: flow, of course the number of libraries is still a bit sparse. QUIC is not even finished yet.
Yagizahas joined
ralphm
And to be sure, Google QUIC was taken apart to IETF QUIC (with a handful of specs) + HTTP-on-QUIC.
j.rhas joined
ralphm
Some background here: https://blog.cloudflare.com/the-road-to-quic/
Zashhas left
MattJhas joined
guusdkhas left
guusdkhas joined
Andrew Nenakhovhas left
danielhas left
Andrew Nenakhovhas joined
Andrew Nenakhovhas joined
blablahas left
Zashhas left
marchas joined
moparisthebesthas joined
moparisthebesthas left
moparisthebesthas joined
labdsfhas left
labdsfhas joined
matlaghas left
rionhas left
andyhas left
vanitasvitaehas left
Holgerhas left
guusdkhas left
guusdkhas joined
blablahas joined
krauqhas left
waqashas left
tuxhas joined
krauqhas joined
lskdjfhas left
vanitasvitaehas left
lskdjfhas joined
genofirehas left
genofirehas left
lskdjfhas joined
Alexhas joined
genofirehas joined
winfriedhas joined
genofirehas left
genofirehas joined
Steve Killehas joined
Kevhas joined
Kevhas joined
Kevhas joined
Steve Killehas joined
Steve Killehas left
Kevhas joined
Steve Killehas joined
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.
lhas left
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!
Alexhas left
Guus
(I shall be making a fool of myself elsewhere now)
jonas’
you’ll blend in
guusdkhas left
guusdkhas joined
Yagizahas left
guusdkhas left
lumihas left
guusdkhas left
guusdkhas joined
waqashas joined
Steve Killehas left
ThibGhas joined
tahas joined
ralphmhas joined
lskdjfhas left
mightyBroccolihas left
alexdehas joined
marchas left
marchas joined
lnjhas joined
alexdehas left
APachhas left
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.
tuxhas joined
pep.
Yeah I remember one guy implementing a bunch of stuff from the spec during the impl days
matlaghas left
mightyBroccolihas joined
lumihas joined
matlaghas left
tuxhas left
tuxhas joined
guusdkhas left
guusdkhas joined
SamWhitedhas left
tahas left
tuxhas joined
Ge0rGhas left
lorddavidiiihas left
Lancehas joined
tuxhas joined
APachhas joined
lorddavidiiihas joined
sonnyhas left
sonnyhas joined
tuxhas joined
tuxhas joined
labdsfhas left
APachhas left
APachhas joined
mimi89999has left
lskdjfhas left
lskdjfhas left
matlaghas left
lskdjfhas joined
Yagizahas joined
Yagizahas left
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/
genofirehas left
Yagizahas joined
ralphm
I.e. the QUIC WG actually made changes to the initial packet byte to accomodate multiplixing with RTP/STUN/etc.