why does xep70 define also a message-based variant? that appears unnecessary, as at the time you know that the client supports xep70, and then the IQ transport is far better
yushyinhas left
belovehas left
Mikaelahas joined
djorzhas left
belovehas joined
yushyinhas joined
Kevhas joined
Arnehas joined
775857429has left
Mikaelahas left
Mikaelahas joined
Dele Olajidehas joined
Friendly Resident Cynichas left
Friendly Resident Cynichas joined
Hugohas left
MattJ
Who knows it supports XEP-0070?
flow
the server who sends the stanza to the user
Mikaelahas left
Menelhas left
resolihas left
Hugohas joined
marchas left
marchas joined
Menelhas joined
Tobiashas left
Tobiashas joined
yushyinhas left
marchas left
pep.
Who says the entity doing ad-hoc is a server
marchas joined
pep.
As much as I agree that an iq-based transport is better
MattJ
PSA: multiple XSF/jabber.org services are currently unreachable due to an outage - including mailing lists, xmpp.net, jabber.org and conference.jabber.org
Andrzejhas joined
Seve
Thank you
flow
pep., my point is that as soon as someone sends you a xep70 challenge, then you previously requested that challenge. and you wouldn't request the challenge if you can't handle it
MattJ
flow, the challenge is not requested by the client, but by the user
Hugohas left
khirputhas left
flow
MattJ, maybe I messed up the terminology. but as soon as a client reacts on xep70 § 4.2 and does § 4.3, the server knows that the client will support § 4.4 (otherwise the client would have done § 4.3)✎
flow
MattJ, maybe I messed up the terminology. but as soon as a client reacts on xep70 § 4.2 and does § 4.3, the server knows that the client will support § 4.4 (otherwise the client would not have done § 4.3) ✏
goldbeardphas left
MattJ
4.2 and 4.3 are a HTTP client, e.g. a web browser
Menelhas left
flow
hmm?
flow
yes 4.1 - 4.3 are HTTP
Tobiashas left
Tobiashas joined
MattJ
So your web browser, and the web server, have no idea if your XMPP client supports XEP-0070
khirputhas joined
Titihas joined
flow
the http client needs to be *at least* aware of the JID of the user to perform 4.3
flow
so there needs to be some interaction between the HTTP logic and the XMPP logic
Menelhas joined
MattJ
Yes, e.g. by offering an "Enter your JID to sign in" input box
khirputhas left
SteveFhas joined
flow
right, I think one flaw of xep70 is that it does <body/> and <confirm/> in the same message. at some point in the HTTP exchange you know that your client either supports xep70, then you do not need <body/> or that it does not support xep70, then you do not need <confirm/>
MattJ
I don't think such a step exists
flow
it's not a step, it's more signalling
MattJ
Where/what is this signalling? There is none other than "the user entered their JID into a web app"
Tobiashas left
flow
I assumed realm=xmpp is the signalling that xep70 should be used
Tobiashas joined
MattJ
That's from the web server
flow
and once the client continues in 4.3 after receiving realm=xmpp in 4.2, he sginals xep70 support
MattJ
At that point it has no idea who you are, or whether you have clients that support XEP-0070
MattJ
The client in 4.3 is a web browser, it too has no idea whether your XMPP clients support XEP-0070
flow
fwiw, I don't believe that everything that does HTTP is a web browser :)
flow
could be a XMPP client doing a http upload fetch
MattJ
I don't believe so either
goldbeardphas joined
MattJ
But I'm attempting to simplify things because of the potential for confusion over the word "client"
flow
i am not sure if this simplification is beneficial here
MattJ
You seem to be assuming that the HTTP client and the XMPP client are the same entity?
MattJ
If so, everything you say makes sense
flow
if xep70 <confirm/> is used, then at least a coupling between the HTTP and XMPP layer is to be expected, no?
MattJ
But that is one specific case that is not very common
goffihas joined
MattJ
This is explicitly stated in the XEP:
> Note well that an XMPP Client can simultaneously be an HTTP Client (or vice-versa), and that an XMPP Server can simultaneously be an HTTP Server (or vice-versa). However, for the purposes of this discussion, we assume that these entities are logically if not physically separate and distinct.
flow
ok, the other case is where your HTTP GET results in a "please enter your jid for verification" box
khirputhas joined
flow
and to be, it is not clear how the HTTP server should decide to return such a verification box or a 401 with realm=xmpp✎
flow
and to me, it is not clear how the HTTP server should decide to return such a verification box or a 401 with realm=xmpp ✏
flow
i would somehow naively expect that 4.1 should contain some http header that signals to the server the the requesting entity supports the xep70 <confirm/> method
MattJ
It's just one possible login option, it may be one of many (in which case using www-authenticate is not wise)
yushyinhas joined
MattJ
That would require support in every web browser
khirputhas left
flow
well you could define the absence of the header as "does not support <confirm/>"
xnamedhas joined
flow
bbl, time for coffee
MattJ
I think you're still mixing up the HTTP client and the XMPP client
MattJ
They are totally separate
MattJ
Your HTTP client (web browser) has no information about your XMPP client
MattJ
You should take a look at https://blog.agayon.be/xmpp_auth_django.html if you want to see a practical demonstration of XEP-0070
antranigvhas left
projjalmhas left
projjalmhas joined
flow
MattJ, does https://blog.agayon.be/xmpp_auth_django.html use <confirm/> somewhere?
I think I see know that we approach this from different angles
flow
my line of thought is, since it is the client, who wants to access the HTTP resource, which specifies the transaction ID, there is no need for an confirmation UI dialog, as you know at the time the <confirm/> arrives via xmpp, that you requested it. of course, this requires a coupling between http and xmpp
Tobiashas left
Tobiashas joined
MattJ
When you say "the client" - which one? :)
MattJ
The HTTP client or the XMPP client?
flow
hmm, but it is unlear for me how an xep70 unware http client would create a xep70 transaction id
flow
MattJ, in my case, it's the same entity (which may not be true, I know, but that's what I was thinking about)
MattJ
The reality is that nobody uses the www-authenticate parts of this XEP
flow
then where does the 'id' in the Gajim example originate from?
MattJ
The XEP clearly states that the two entities are usually separate, but yes, I agree they may be the same entity and then it solves the discovery problem
MattJ
In the "enter your JID" web app case, it's the web app that generates the id and communicates with you over XMPP
flow
MattJ, ok, so xep70 § 4.2 and 4.3 isn't use at all here?✎
flow
MattJ, ok, so xep70 § 4.2 and 4.3 isn't used at all in this case? ✏
MattJ
No
MattJ
Just the XMPP parts
flow
that leaves so little remaining from the xep that I wonder if it wouldn't be sensible to simply send a message with a body
marchas left
SteveFhas left
MattJ
Yep
marchas joined
MattJ
And since so few clients currently implement it, that's the UI most people would see right now (that or "here is your authentication code")
MattJ
Just the way some sites use email or SMS to sign you in
MattJ
XEP-0070 just allows clients to put a nicer UI on top
MattJ
However I think it's inadequate even for that
flow
MattJ, that was nice chat, btw. it is always interesting how the same xep can be interpreted in different ways, depending on your prior experience. I read the xep primarly as an approach for a single entity performing http requests and authenticating via xmpp
praveenhas left
MattJ
Although it can be used that way, that was definitely not the intention of the authors (per the paragraph I quoted earlier)
MattJ
But a lot of optimism was involved in that, I think
MattJ
In practice, www-authenticate isn't often used these days even for HTTP-only auth
flow
MattJ, not sure about that, the process flow in § 4. makes it appear that § 4.2 and § 4.3 are somehow expected to happen
MattJ
Yes, the idea would be that browsers implement support for XEP-0070 to make this work
MattJ
The same way SCRAM is also defined for HTTP, but browsers don't implement that either
MattJ
Everything happens via HTML/JS now instead
praveenhas joined
goldbeardphas left
goldbeardphas joined
Martinhas left
Martinhas joined
Andrzejhas left
antranigvhas joined
Alexhas left
775857429has joined
sjmhas left
sjmhas joined
marchas left
marchas joined
chipmnkhas left
chipmnkhas joined
Alexhas joined
Daniel
If occupant ids allow me to track users across nick name changes and sessions. Do I show the current Nick next to a message or the Nick at time of sending? 🤔
neoxhas left
Ge0rG
at the time of sending is less confusing IMHO
MattJ
I don't see an immediate right or wrong answer. However I think maybe if you display nick changes in the chat log, show at the time of sending. If you don't show nick changes, always show the current.
jonas’: you can join a room from different clients with different nicknames
gooyahas joined
jonas’
then they're not the same entity
MattJ
Until they are
neoxhas left
jonas’
*shudder*
Ge0rG
do they have the same occupant-id?
goldbeardphas left
goldbeardphas joined
Daniel
Yes
Daniel
When I'm joined here as `Daniel` and `daniel` from Dino and Conversations I have two nicks and one occupant id
belovehas left
praveenhas left
jonas’
that does not sound right
775857429has left
MattJ
That's the whole point of occupant-id, no?
belovehas joined
stphas joined
Tobiashas left
Tobiashas joined
MattJ
The XEP says: "A user in the sense of this specification is identified by its real bare JID."
Daniel
> that does not sound right
In that I'm quoting the xep wrong or in that the effects of ephemeral nicks in group chats are bonkers?
Alexhas left
neoxhas joined
jonas’
the latter I guess
neoxhas left
oshnhas left
Tobiashas left
Tobiashas joined
Tobiashas left
Tobiashas joined
Menelhas left
goldbeardphas left
stphas left
oshnhas joined
Mikaelahas joined
no_1729has joined
Menelhas joined
neoxhas joined
goldbeardphas joined
papatutuwawahas joined
Tim Rhas joined
Mikaelahas left
oshnhas left
L29Ahhas joined
praveenhas joined
Tobiashas left
Tobihas left
jgarthas joined
no_1729has left
no_1729has joined
neshtaxmpphas left
neshtaxmpphas joined
neshtaxmpphas left
Fishbowlerhas left
Fishbowlerhas joined
paulhas left
neshtaxmpphas joined
no_1729has left
marchas left
marchas joined
no_1729has joined
Tim Rhas left
deimoshas left
deimoshas joined
no_1729has left
no_1729has joined
Alexhas joined
oshnhas joined
paulhas joined
Hugohas joined
no_1729has left
nicomuchas joined
nicomuchas left
LNJhas left
LNJhas joined
jgarthas left
jcbrandhas left
no_1729has joined
oshnhas left
Hugohas left
775857429has joined
jcbrandhas joined
mimi89999has left
Calvinhas joined
mimi89999has joined
Tim Rhas joined
no_1729has left
no_1729has joined
Calvinhas left
konstantinoshas left
stphas joined
sjmhas left
papatutuwawahas left
singpolymahas left
papatutuwawahas joined
govanifyhas left
praveenhas left
sjmhas joined
singpolymahas joined
inkyhas left
govanifyhas joined
Tobihas joined
Tobiashas joined
Tobiashas left
Tobiashas joined
stphas left
L29Ahhas left
Tobiashas left
L29Ahhas joined
Tobiashas joined
Wojtekhas joined
oshnhas joined
Martinhas left
Martinhas joined
L29Ahhas left
L29Ahhas joined
Andrzejhas joined
lskdjfhas joined
praveenhas joined
oshnhas left
Tobiashas left
Tobihas left
Tobihas joined
Tobiashas joined
no_1729has left
oshnhas joined
no_1729has joined
Andrzejhas left
singpolymahas left
Tobiashas left
Tobihas left
Tobiashas joined
Tobihas joined
singpolymahas joined
Tobiashas left
Tobihas left
Tobiashas joined
Tobihas joined
djorzhas joined
Maranda[x]has left
oshnhas left
moparisthebesthas left
Martinhas left
no_1729has left
sjmhas left
moparisthebesthas joined
no_1729has joined
Maranda[x]has joined
govanifyhas left
Alexhas left
Alexhas joined
inkyhas joined
Guus
User complaining that bugs never get fixed, pointing out that the problem already existed five years ago. When requesting some kind of diagnostics other than "it doesnt work", I find out that they've configured their XMPP domain name to be 'localhost'. #tgif #sigh
Guus
`</vent>`
oshnhas joined
MattJ
:)
govanifyhas joined
Martinhas joined
Zash
It is Friday!
775857429has left
resolihas joined
flow
which became recently one of my favorite weekdays, since its the day where new episode of picard appears
singpolymahas left
Tobiashas left
Tobiashas joined
Guus
I do not dislike Picard S3
singpolymahas joined
flow
well put
tbm16has joined
Rebeldhas left
lskdjfhas left
resolihas left
775857429has joined
oshnhas left
jgarthas joined
no_1729has left
franck-xhas left
lskdjfhas joined
Andrzejhas joined
oshnhas joined
Tobiashas left
Tobihas left
adiaholichas left
adiaholichas joined
djorzhas left
marchas left
Calvinhas joined
Calvinhas left
Calvinhas joined
mentos124has joined
adiaholichas left
adiaholichas joined
jgarthas left
sjmhas joined
deimoshas left
stphas joined
marchas joined
zonsopkomsthas left
zonsopkomsthas joined
775857429has left
oshnhas left
Fishbowlerhas left
Fishbowlerhas joined
mentos124has left
chipmnkhas left
Hugohas joined
chipmnkhas joined
neshtaxmpphas left
neshtaxmpphas joined
BASSGODhas left
Martinhas left
Martinhas joined
oshnhas joined
praveenhas left
adiaholichas left
Ge0rGhas left
adiaholichas joined
deimoshas joined
L29Ahconfigured his XMPP domain name to be 'localhost' and is happy, 10/10 do recommend ;]
Ge0rGhas joined
Fishbowler
I'm biased towards all Trek, but Picard S3 is something extra special. Every episode so far this season has been even better than the one before.
Calvinhas left
Fishbowler
All service operators: "Everything would run fine, if it weren't for these pesky users!"
L29Ah: "I have a cunning plan."