XSF Discussion - 2023-03-24

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

Who knows it supports XEP-0070?

the server who sends the stanza to the user

Who says the entity doing ad-hoc is a server

As much as I agree that an iq-based transport is better

PSA: multiple XSF/jabber.org services are currently unreachable due to an outage - including mailing lists, xmpp.net, jabber.org and conference.jabber.org

Thank you

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

flow, the challenge is not requested by the client, but by the user

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) ✏

4.2 and 4.3 are a HTTP client, e.g. a web browser

hmm?

yes 4.1 - 4.3 are HTTP

So your web browser, and the web server, have no idea if your XMPP client supports XEP-0070

the http client needs to be *at least* aware of the JID of the user to perform 4.3

so there needs to be some interaction between the HTTP logic and the XMPP logic

Yes, e.g. by offering an "Enter your JID to sign in" input box

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/>

I don't think such a step exists

it's not a step, it's more signalling

Where/what is this signalling? There is none other than "the user entered their JID into a web app"

I assumed realm=xmpp is the signalling that xep70 should be used

That's from the web server

and once the client continues in 4.3 after receiving realm=xmpp in 4.2, he sginals xep70 support

At that point it has no idea who you are, or whether you have clients that support XEP-0070

The client in 4.3 is a web browser, it too has no idea whether your XMPP clients support XEP-0070

fwiw, I don't believe that everything that does HTTP is a web browser :)

could be a XMPP client doing a http upload fetch

I don't believe so either

But I'm attempting to simplify things because of the potential for confusion over the word "client"

i am not sure if this simplification is beneficial here

You seem to be assuming that the HTTP client and the XMPP client are the same entity?

If so, everything you say makes sense

if xep70 <confirm/> is used, then at least a coupling between the HTTP and XMPP layer is to be expected, no?

But that is one specific case that is not very common

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.

ok, the other case is where your HTTP GET results in a "please enter your jid for verification" box

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 ✏

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

It's just one possible login option, it may be one of many (in which case using www-authenticate is not wise)

That would require support in every web browser

well you could define the absence of the header as "does not support <confirm/>"

bbl, time for coffee

I think you're still mixing up the HTTP client and the XMPP client

They are totally separate

Your HTTP client (web browser) has no information about your XMPP client

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

MattJ, does https://blog.agayon.be/xmpp_auth_django.html use <confirm/> somewhere?

ahh ok, it appears it does

Yes: https://git.kingpenguin.tk/chteufleur/HTTPAuthentificationOverXMPP/src/branch/master/xmpp/confirmation.go

I think I see know that we approach this from different angles

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

When you say "the client" - which one? :)

The HTTP client or the XMPP client?

hmm, but it is unlear for me how an xep70 unware http client would create a xep70 transaction id

MattJ, in my case, it's the same entity (which may not be true, I know, but that's what I was thinking about)

The reality is that nobody uses the www-authenticate parts of this XEP

then where does the 'id' in the Gajim example originate from?

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

In the "enter your JID" web app case, it's the web app that generates the id and communicates with you over XMPP

MattJ, ok, so xep70 § 4.2 and 4.3 isn't used at all in this case? ✏

No

Just the XMPP parts

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

Yep

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")

Just the way some sites use email or SMS to sign you in

XEP-0070 just allows clients to put a nicer UI on top

However I think it's inadequate even for that

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

Although it can be used that way, that was definitely not the intention of the authors (per the paragraph I quoted earlier)

But a lot of optimism was involved in that, I think

In practice, www-authenticate isn't often used these days even for HTTP-only auth

MattJ, not sure about that, the process flow in § 4. makes it appear that § 4.2 and § 4.3 are somehow expected to happen

Yes, the idea would be that browsers implement support for XEP-0070 to make this work

The same way SCRAM is also defined for HTTP, but browsers don't implement that either

Everything happens via HTML/JS now instead

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? 🤔

at the time of sending is less confusing IMHO

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.

Time of sending + invisible changes = an interesting ability to forge a conversation that to an observer looks like multiple parties were involved

What if they have multiple current nicks ✏

"multiple current nicks"?

what's that?

jonas’: you can join a room from different clients with different nicknames

then they're not the same entity

Until they are

*shudder*

do they have the same occupant-id?

Yes

When I'm joined here as `Daniel` and `daniel` from Dino and Conversations I have two nicks and one occupant id

that does not sound right

That's the whole point of occupant-id, no?

The XEP says: "A user in the sense of this specification is identified by its real bare JID."

> 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?

the latter I guess

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

`</vent>`

:)

It is Friday!

which became recently one of my favorite weekdays, since its the day where new episode of picard appears

I do not dislike Picard S3

well put

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.

All service operators: "Everything would run fine, if it weren't for these pesky users!" L29Ah: "I have a cunning plan."