-
flow
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
-
MattJ
Who knows it supports XEP-0070?
-
flow
the server who sends the stanza to the user
-
pep.
Who says the entity doing ad-hoc is a server
-
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
-
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
-
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) ✏
-
MattJ
4.2 and 4.3 are a HTTP client, e.g. a web browser
-
flow
hmm?
-
flow
yes 4.1 - 4.3 are HTTP
-
MattJ
So your web browser, and the web server, have no idea if your XMPP client supports XEP-0070
-
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
-
MattJ
Yes, e.g. by offering an "Enter your JID to sign in" input box
-
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"
-
flow
I assumed realm=xmpp is the signalling that xep70 should be used
-
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
-
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
-
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
-
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)
-
MattJ
That would require support in every web browser
-
flow
well you could define the absence of the header as "does not support <confirm/>"
-
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
-
flow
MattJ, does https://blog.agayon.be/xmpp_auth_django.html use <confirm/> somewhere?
-
flow
ahh ok, it appears it does
-
MattJ
Yes: https://git.kingpenguin.tk/chteufleur/HTTPAuthentificationOverXMPP/src/branch/master/xmpp/confirmation.go
-
flow
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
-
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
-
MattJ
Yep
-
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
-
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
-
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? 🤔
-
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.
-
Daniel
What if the have multiple current nicks✎ -
MattJ
Time of sending + invisible changes = an interesting ability to forge a conversation that to an observer looks like multiple parties were involved
-
Daniel
What if they have multiple current nicks ✏
-
jonas’
"multiple current nicks"?
-
jonas’
what's that?
-
Ge0rG
jonas’: you can join a room from different clients with different nicknames
-
jonas’
then they're not the same entity
-
MattJ
Until they are
-
jonas’
*shudder*
-
Ge0rG
do they have the same occupant-id?
-
Daniel
Yes
-
Daniel
When I'm joined here as `Daniel` and `daniel` from Dino and Conversations I have two nicks and one occupant id
-
jonas’
that does not sound right
-
MattJ
That's the whole point of occupant-id, no?
-
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?
-
jonas’
the latter I guess
-
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>`
-
MattJ
:)
-
Zash
It is Friday!
-
flow
which became recently one of my favorite weekdays, since its the day where new episode of picard appears
-
Guus
I do not dislike Picard S3
-
flow
well put
- L29Ah configured his XMPP domain name to be 'localhost' and is happy, 10/10 do recommend ;]
-
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.
-
Fishbowler
All service operators: "Everything would run fine, if it weren't for these pesky users!" L29Ah: "I have a cunning plan."