jdev - 2025-04-12

> 2025-04-11T20:58:31Z - theTedd: > When the aim is to log in on mobile, you'll already be using data to request the code, and then presumably chatting afterwards The SIM is not necessarily installed in the same device. ↺

> 2025-04-11T18:36:25Z - Zash: > but '77 doesn't really support flows like "enter an email, then enter the code we sent to that email", but https://xmpp.org/extensions/xep-0389.html was meant to allow that kind of thing Wow, I'm implementing a login wizard via Ad-Hoc right now, because XEP-0077 does not support multiple stages. Is it implemented in some clients already? ↺

I'm not sure though if it's suitable for the case, probably still not.

I don't think it's implemented anywhere no

I'm hoping to implement it for a few clients though, once I figure out the details and get a funding green light from Prav

bodqhrohro, tell me more about your use-case?

So I've been thinking about FAST and it looks like combined with extensible IBR we have all we need for actual passwordless authentication?

If I understood the specs right, I can use extensible IBR the first time to receive a one-time login code to (email or mobile) and register the user if it matches

Then each time the user wants to log in from a new client we use FAST to trigger another one-time code, after which the client gets a token for future reconnections

One flaw is the client would get *two* codes the first time (once for registration, and once for login)

Unless there's something in the reg spec that lets the server say "okay cool you're registered and also authenticated so you can continue using the existing connection"? But that would *also* have to say "...and here's your FAST token" so things get a bit complicated 🤔

https://xmpp.org/extensions/xep-0389.html#example-15

After successful registration (at the point linked to above) is the negotiation considered complete (as if they've also authenticated) or does the client has to renegotiate (i.e. authenticate again)?

Equivalent question for whatever the `jabber:iq:register` RFC is

> well: > > You're welcome to implement it. or write a XEP Just learnt about this utilisation of XEP-0070 that actually implements "Sign into website with XMPP"! https://blog.agayon.be/xmpp_auth_django.html ↺

> <badrihippo> > bodqhrohro, tell me more about your use-case? Multi-stage login via a transport. It already works via text commands, and via separate Ad-Hoc commands, I'm just duplicating it as a wizard also. ✏ ↺

Interesting. Did that work out of the box in clients or did you have to customise on the client end too? ✏

badrihippo: Ad-Hoc works well in many clients for decades already. There are indeed some tiny problems, e.g., Gajim didn't support multiple notes per a command result (I've sent a patch for that), and Psi+/Tkabber don't as well (still didn't even report). And there some bugs in forms in another.im and probably in Cheogram too.

bodqhrohro: multiple notes it should show only one of them per spec

But yes IMO every user facing flow should be built on ad hoc unless there's a very good reason not to

Is "you don't have an account yet" a good reason?

No?

I guess you can do it by first granting a limited account and then upgrading later.

You don't need an account. Same as ibr

If you're just talking to the server

So more iq stanzas before resource binding? That's not supposed to be allowed and only exists for historical reasons

Well we're talking about account registration. It's the same case where we do this already

For ugly historical reasons

Let's not add more of it

> 2025-04-12T13:08:47Z - singpolyma: > bodqhrohro: multiple notes it should show only one of them per spec Ehm, really? ↺

Zash: Im not proposing adding more. Just keeping the one we have and using a different syntax

But I want it gone :(

bodqhrohro: yes. A command may have multiple payloads but they are alternatives to each other

Zash: how would you do registration then?

IBR2?

Which somehow doesn't need to communicate before having an account?

Wait what the, who put an iq there?

I can't imagine any way torke an IBR replacement without iq

> You don't need an account. Same as ibr I didn't know that! ↺

Prosody doesn't even treat those as iq stanzas, because stanzas aren't allowed before resource binding (and authenticating)

> For ugly historical reasons What's the history? ↺

badrihippo, in 1999, iq stanzas was used for everything

Zash: Oh so you just want to replace with IQ equivalent nonzas?

singpolyma, yes

like auth and everything else going on before resource binding

That seems worse. Nonzas are gross. But I guess it's equivalent

Why not a nonza named iq 😉

Noooooo!

We already have too many of those

Making up new names seem like where the "more of those" come from but fine. If we pick the other name and keep the payloads the same I can still use the ad hoc code path so I don't really care

Or I guess use the <command element as a nonza directly why not

Pre-bind <iq> requires more involved routing that the simple name+namespace dispatch used for other stream elements

also stanzas are supposed to be routable, which isn't allowed pre-auth/bind

I'm new to this part of the stream, but isn't the entire negotiation a sequence of request/responses anyway? So "iq" is kind of anyway implied for everything and there's no need to make it explicit just for one case?

Yes obviously an IQ with a to attribute would not be allowed pre bind

badrihippo: sure

Yes

Its the same either way. Using iq is slightly simpler but it doesn't really matter I guess

So long as we use <command

Looking at Zash's comments I think I need to read the code before forming a ~judgement~ opinion

To understand the technical part

An IQ can only have one payload so as long as you won't have multiple in flight at once using the payload directly is equivalent to using an iq

> 2025-04-12T13:16:27Z - Zash: > But I want it gone :( Could you point me to an exact excerpt? I can't find anything like that, yet I see multiple explicit mentions that there can be multiple <note> elements. If payloads are supposed to be alternatives, then how are actions supposed to be provided along with forms? I assume the same applies to notes: they are supposed to accompany other elements, not to replace them. Or does this apply only to elements of the same type? Also, it seems that spec-wise the whole set of children elements of the <command> element is considered a "payload", not individual elements or one of them. ✏ ↺

Huh?

Actions aren't a payload in the same way

> 2025-04-12T13:32:13Z - Zash: > Huh? Sorry, popup buttons in Gajim work unclearly for narrow rows and I miss the proper message sometimes. ↺

Eww, they just got out of sync when scrolling.

https://cerdale.zash.se/s/067fa6bb-a04c-7ee4-8ceb-4a7120b4fc3f/345b2074-b9ef-4b70-98d5-cfa7d1641a9a.png

> When the precedence of these payload elements becomes important (such as when both "jabber:x:data" and "jabber:x:oob" elements are present), the order of the elements SHOULD be used. Those elements that come earlier in the child list take precedence over those later in the child list.

> The children of a <command/> element (other than <actions/> and <note/>) pertain to the command's execution. The order of these elements denote their precedence, so that those elements earlier in the list have higher precedence.

> 2025-04-12T13:33:47Z - singpolyma: > > When the precedence of these payload elements becomes important (such as when both "jabber:x:data" and "jabber:x:oob" elements are present), the order of the elements SHOULD be used. Those elements that come earlier in the child list take precedence over those later in the child list. I saw this, but what does "precedence" mean exactly? "Pick one" or "take order into account"? ↺

> 2025-04-12T13:35:44Z - singpolyma: > > The children of a <command/> element (other than <actions/> and <note/>) pertain to the command's execution. The order of these elements denote their precedence, so that those elements earlier in the list have higher precedence. And this also means <note> is special along with <actions>. ↺

Yes the second one says note is special which makes no sense and isn't now anyone implements it

Precedence means "which one you choose"

Eg I often deliver a note or form and oob with oob first so it is used when supported and when not supported the note or form is used

Based on how implementations work and how the rest of the spec reads I expect the (excepts actions or note) should just say (except actions)

https://xmpp.org/rfcs/rfc6120.html#rfc.section.4.3.5 has some words the effect of forbidding stanzas prior to completing stream negotiation and points out resource binding as an *historical* exception to that rule. Seems much cleaner to me to keep handling of stream negotiation (and e.g. xep-198 acks) separate from stanza routing.

> 2025-04-12T13:37:15Z - singpolyma: > Yes the second one says note is special which makes no sense and isn't now anyone implements it It makes sense because there are multiple types of notes which have different purpose. ↺

> 2025-04-12T13:39:56Z - singpolyma: > Based on how implementations work and how the rest of the spec reads I expect the (excepts actions or note) should just say (except actions) I think implementations are just not well-polished enough because Ad-Hoc had little real use historically and wasn't battle-tested enough. AFAIR, there were even plans to remove it from Gajim because the code is rotten and abandoned, but someone insisted to keep it. ↺

i think you remember something wrong there

Maybe, I have no proofs there :P

the only problem over the years i ran into with adhoc were more about the dataform which is included than about adhoc

e.g. my text is not dispalyed pretty in this dataform

> 2025-04-12T13:51:19Z - lovetox: > the only problem over the years i ran into with adhoc were more about the dataform which is included than about adhoc Yup, aforementioned another.im bugs also happen with dataforms rather than in the scope of Ad-Hoc itself. (do forms have use out of Ad-Hoc though?) ↺

>> 2025-04-12T13:37:15Z - singpolyma: >> Yes the second one says note is special which makes no sense and isn't now anyone implements it > It makes sense because there are multiple types of notes which have different purpose. Do you have an example of including two types of notes in one response? ↺

>> 2025-04-12T13:51:19Z - lovetox: >> the only problem over the years i ran into with adhoc were more about the dataform which is included than about adhoc > Yup, aforementioned another.im bugs also happen with dataforms rather than in the scope of Ad-Hoc itself. > (do forms have use out of Ad-Hoc though?) Yes they do. In IBR for example. And MUC config ↺

> 2025-04-12T14:02:42Z - singpolyma: > Do you have an example of including two types of notes in one response? I have a configuration form where some options are incompatible with others and may be automatically harmonized on validation stage. Or incompatible with the server configuration, and thus also automatically changed. The transport informs about this in the command result, and thus there are two notes: one "usual" `info` about updated properties, and one `warn` with a notice about corrected or rejected parameters. Technically, I could stuff them into one `warn` note, yet it would look meh. There are also some validation errors which can be displayed this way (`info` note and an `error` note), yet they can only occur with a misbehaving client, i.e. using a wrong widget for the field or an unknown name, so they shouldn't occur normally. There also were mutually dependent options, but they were removed already. (New ones may appear in the future though.) ✏ ↺

> 2025-04-12T14:02:42Z - singpolyma: > Do you have an example of including two types of notes in one response? I have a configuration form where some options are incompatible with others and may be automatically harmonized on validation stage. Or incompatible with the server configuration, and thus also automatically changed. The transport informs about this in the command result, and thus there are two notes: one "usual" `info` about updated options, and one `warn` with a notice about corrected or rejected parameters. Technically, I could stuff them into one `warn` note, yet it would look meh. There are also some validation errors which can be displayed this way (`info` note and an `error` note), yet they can only occur with a misbehaving client, i.e. using a wrong widget for the field or an unknown name, so they shouldn't occur normally. There also were mutually dependent options, but they were removed already. (New ones may appear in the future though.) ✏ ↺

> 2025-04-12T14:02:42Z - singpolyma: > Do you have an example of including two types of notes in one response? I have a configuration form where some options are incompatible with others and may be automatically harmonized on validation stage. Or incompatible with the server configuration, and thus also automatically changed. The transport informs about this in the command result, and thus there are two notes: one "usual" `info` about updated options, and one `warn` with a notice about corrected or rejected optoins. Technically, I could stuff them into one `warn` note, yet it would look meh. There are also some validation errors which can be displayed this way (`info` note and an `error` note), yet they can only occur with a misbehaving client, i.e. using a wrong widget for the field or an unknown name, so they shouldn't occur normally. There also were mutually dependent options, but they were removed already. (New ones may appear in the future though.) ✏ ↺

> 2025-04-12T14:02:42Z - singpolyma: > Do you have an example of including two types of notes in one response? I have a configuration form where some options are incompatible with others and may be automatically harmonized on validation stage. Or incompatible with the server configuration, and thus also automatically changed. The transport informs about this in the command result, and thus there are two notes: one "usual" `info` about updated options, and one `warn` with a notice about corrected or rejected options. Technically, I could stuff them into one `warn` note, yet it would look meh. There are also some validation errors which can be displayed this way (`info` note and an `error` note), yet they can only occur with a misbehaving client, i.e. using a wrong widget for the field or an unknown name, so they shouldn't occur normally. There also were mutually dependent options, but they were removed already. (New ones may appear in the future though.) ✏ ↺

So you have an error but you also include a seperate info note? 🤔

Actually, this is a legacy of mapping the CLI way to the form, where one command could change only one option at a time. I might consider reworking it, i.e., ping back the corrected form to the user to check and confirm it, and also to reject it altogether if there are problems with certain fields. Yet I think listing the changed options is easier than to spot what was changed in the form. As there are no rich means for interactive validation.

> 2025-04-12T14:14:42Z - singpolyma: > So you have an error but you also include a seperate info note? 🤔 Yup. "ERROR: Success", lol. ↺

The wording there sort of implies you can have a note *and* a form too which seems odd since a firm can already display whatever. I've always done precedence with notes alongside everything

singpolyma: this time I'm talking about the completion stage. But a note and a form is an even more valid case regarding validation. How to display the reason the form was rejected otherwise? Show a message and provide a "prev" action to go to the previous stage and correct it? Doesn't seem flexible really. ✏

I also remember trying to add some instructions on filling the form, yet I probably rejected this idea exactly because there's no robust way to do that with current clients.

A form can show text already with instructions elements etc. Don't need a note for that

but is it the right thing to do

its not about sending just text, its about telling the client that an error or warning happend

just writing it into the instruction text gives the client no chance to properly display whats happened

> 2025-04-12T15:00:12Z - singpolyma: > A form can show text already with instructions elements etc. Don't need a note for that Hmm, yeah, then it happened in the semi-functional XEP-0077 stub. ↺

> just writing it into the instruction text gives the client no chance to properly display whats happened I have wished for a per field error option in data forms before. ↺