Feedback on XEP-0379, XEP-0401, XEP-0445
Hi, I’m sorry to say but the "Easy Onboarding" stack is a bit of a mess and I believe it requires significant work before we can consider restarting the Last Call. Personally the most impactful feature of that stack has always been allowing registrations on servers that don’t have public (open) registrations. This solves a real need for "Family and Friends" style servers that really, really should not have open registration. I was never fully sold on the pre-authenticated roster part of the stack. I don’t know. I guess it’s kinda neat but I don’t really need a mutual presence subscription to get the first message out. The XEPs try to separate those two concerns (I guess partially due to me providing the same feedback a few years ago) but do a pretty bad job at it. 0445 is technically a separate XEP but without 0401 I have no (standardized) way retrieving those registration tokens. However 0401 doesn’t provide a guarantee that the server even supports 0445 and I have no way of knowing that before retrieving the invite URI. Only after retrieving the invite URI and checking for the existence of the ibr=y parameter I know that the server supports 0445. Currently, when I want to display a button in my client that reads. "Invite people to my server" I can’t because i have no discovery for that. Side note: The XEP is kinda sneaky in that it uses the same "preauth" parameter for 0379 and 0445. So even if I as a client developer are only really interested in the registration part; the delta work to also implement 0379 is extremely minimal. (Which I guess that’s fine and very much on purpose; but it speaks to the separation between those three XEPs not really existing). With an implementor hat but I guess also partially with my council hat I really need these 3 XEPs to go one of two ways: a) Give me a real way to use 0445 stand alone. Give me a standardized, discoverable way to request those IBR tokens from my server. b) Collapse those three XEPs back into one and make 0445 a required part of the stack. (Basically guarantee me that the URI that falls out of 0401 also allows me to register on the server of the person that invited me) P.S.: Completely separate of concerns above: We (both Prosody and ejabberd) do that have started to put a Link: <xmpp:…> header into the HTTP landing page. This allows a client to HEAD the HTTP endpoint when scanned from a QR code and then process the xmpp URI directly and internally without opening a website first. That way you can always put the HTTP uri into a QR code and when scanned it will always do the right thing regardless of whether it was scanned by the OS or by the XMPP app directly. I think this should go into the XEP.
On Sun, Mar 8, 2026, at 10:27, Daniel Gultsch wrote:
I was never fully sold on the pre-authenticated roster part of the stack. I don’t know. I guess it’s kinda neat but I don’t really need a mutual presence subscription to get the first message out.
You share a QR code to a friend, or they scan it from your phone, and all the subscribe/subscribed dance is done without anyone of the 2 users receiving requests that they need to accept or acknowledge. This sounds to me like a pretty nice value. Why do you think its about sending a first message?
The XEPs try to separate those two concerns (I guess partially due to me providing the same feedback a few years ago) but do a pretty bad job at it.
0445 is technically a separate XEP but without 0401 I have no (standardized) way retrieving those registration tokens.
However 0401 doesn’t provide a guarantee that the server even supports 0445 and I have no way of knowing that before retrieving the invite URI. Only after retrieving the invite URI and checking for the existence of the ibr=y parameter I know that the server supports 0445.
It does guarantee that, it says
Romeo's server MUST support at least one Pre-Authenticated In-Band Registration mechanism.
Though i agree we can make that even more strict, because this pre auth mechanism 445 defines, has nothing to do with specific IBR mechanism that is used later, its completely independent, and it does not care if a server uses 0389 or 0077. Further 445 defines a stream feature, so you *can* know that the server supports it *before* creating the invitation. Though as 401 has already a MUST dependency on 445, not sure why you would need to check that stream feature.
Currently, when I want to display a button in my client that reads. "Invite people to my server" I can’t because i have no discovery for that.
You can check the supported commands, and check the stream feature if you think its necessary. Personally i would only check the supported commands and depend on the server respecting the XEPs dependencies. About the rest i agree, this could have been all one big XEP, especially because half of 445 XEP is duplicating text about what URIs there are and what they do. 379 without server support seems to me not really worth it, you run into the topic that you have multiple devices all not online at the same time, so even though you generated a token on one device this does not guarantee that the subscribe flow will reach this device. I would opt for collapsing them all into 401, this should be possible without really changing anything about the implementations. I also would offer my help to do that if the author is interested. Regards Philipp
On Sun, Mar 8, 2026 at 2:49 PM Philipp Hörist <philipp@hoerist.com> wrote:
On Sun, Mar 8, 2026, at 10:27, Daniel Gultsch wrote:
I was never fully sold on the pre-authenticated roster part of the stack. I don’t know. I guess it’s kinda neat but I don’t really need a mutual presence subscription to get the first message out.
You share a QR code to a friend, or they scan it from your phone, and all the subscribe/subscribed dance is done without anyone of the 2 users receiving requests that they need to accept or acknowledge. This sounds to me like a pretty nice value.
Why do you think its about sending a first message?
I just meant if the goal is to share your JID and to send you a message (aka make first contact) I don’t really need mutual presence sub for that. Yes it's nice to have but personally I’m very much *shrug emoji*. Anyway my goal is not to take Roster Pre Auth away from someone. Out of the two suggestions I had in my original email I'm absolutely fine with going the "combine this all into one do it all XEP".
However 0401 doesn’t provide a guarantee that the server even supports 0445 and I have no way of knowing that before retrieving the invite URI. Only after retrieving the invite URI and checking for the existence of the ibr=y parameter I know that the server supports 0445.
It does guarantee that, it says
Romeo's server MUST support at least one Pre-Authenticated In-Band Registration mechanism.
There is also language like that: "The ibr query component in the XMPP URI indicates that the invitee is allowed to create an account on Romeo's server, using the 'preauth' token. If the server does not support or allow in-band registration for invited users, the server MUST omit the ibr query component." and "Register an account with Romeo's server (if the URI contains a ibr=y parameter)." (Notice the *if*) And I’m fairly sure that in practice not all implementation in all configuration do that. The 0445 stream feature is only advertised to unauthenticated users. Which actually makes sense because the normal register stream feature is also only advertised before authentication. So they can’t be used for logged in users to display that button or not.
On Sun, Mar 8, 2026 at 2:49 PM Philipp Hörist <philipp@hoerist.com> wrote:
379 without server support seems to me not really worth it, you run into the topic that you have multiple devices all not online at the same time, so even though you generated a token on one device this does not guarantee that the subscribe flow will reach this device.
FWIW I agree with this too. I didn’t want to put too much stuff into my original mail but I think the client side work around should just go. I don’t implement and through the magic of time we are actually in a situation where both major servers have support for it anyway.
Hi, someone else can (and hopefully will) write more words on that matter but I’m just writing it here today so we don’t forget if this ever goes to LC again. There is currently no way to discover that a server is 'invite only'. Both register and 0445 have stream features but there is no way to discover that 0445 is "required" for <register/> to work. There is also no standardized error message for the registration in case that fails due to missing token submission. I think both should exists. cheers Daniel
Hey, everyone! (Not been active here in over ten years, I think) Am So., 8. März 2026 um 10:28 Uhr schrieb Daniel Gultsch <daniel@gultsch.de>:
I was never fully sold on the pre-authenticated roster part of the stack. I don’t know. I guess it’s kinda neat but I don’t really need a mutual presence subscription to get the first message out.
Just like Philip, I don't agree with this. Also consider there are people who have "block strangers" active, one way or the other. And this is a good way to establish a trusted connection then.
However 0401 doesn’t provide a guarantee that the server even supports 0445 and I have no way of knowing that before retrieving the invite URI. Only after retrieving the invite URI and checking for the existence of the ibr=y parameter I know that the server supports 0445.
The way it's implemented in ejabberd you could check for the existence of the "Account Creation" command.
Currently, when I want to display a button in my client that reads. "Invite people to my server" I can’t because i have no discovery for that.
If the focus is on creating an account, rather than adding someone to your roster, then wouldn't the semantics of "Account Creation" invite be a better match anyway? Of course, that means, if the target person does have an account already, this invite would be useless. Which sort of hints at a messy situation where there's just a large overlap between the two types of invites which makes it hard to convey to people what they are for and what they are not for (no one wants to read a whole paragraph first).
Side note: The XEP is kinda sneaky in that it uses the same "preauth" parameter for 0379 and 0445. So even if I as a client developer are only really interested in the registration part; the delta work to also implement 0379 is extremely minimal. (Which I guess that’s fine and very much on purpose; but it speaks to the separation between those three XEPs not really existing).
Exactly.
However 0401 doesn’t provide a guarantee that the server even supports 0445 and I have no way of knowing that before retrieving the invite URI. Only after retrieving the invite URI and checking for the existence of the ibr=y parameter I know that the server supports 0445.
It does guarantee that, it says
Romeo's server MUST support at least one Pre-Authenticated In-Band Registration mechanism.
There is also language like that:
"The ibr query component in the XMPP URI indicates that the invitee is allowed to create an account on Romeo's server, using the 'preauth' token. If the server does not support or allow in-band registration for invited users, the server MUST omit the ibr query component."
Maybe not directly related but I want to make you aware of one more semantical difference: In ejabberd we support setting a limit to how many "Account Creation" invites an account can generate. This also implies there is a reserved spot for you, when you receive such an invite. Now with "User Invites" we set "ibr=y" if the issuer could have also generated an "Account Creation" invite. But since we don't know, what it's gonna be used for and since there's no limit on "User Invites", there's no guaranteed "spot" in case the recipient uses the token to create a new account. So if in between creating the invite and the recipient redeeming it the issuer has created more "Account Creation" invites or other recipients of "User Invite" invites used them to create accounts, The redeemer might end up with another error message after sending the iq-set for 'jabber:iq:register'. Which again hints at something not being spec'd out properly. Maybe.
There is currently no way to discover that a server is 'invite only'. Both register and 0445 have stream features but there is no way to discover that 0445 is "required" for <register/> to work. There is also no standardized error message for the registration in case that fails due to missing token submission. I think both should exists.
I didn't implement a more meaningful error message in ejabberd, because I didn't want to disclose any unnecessary information about the server's configuration. Now that I think about it, that is a mistake most likely. So if we had a dedicated error, that would certainly help. A workaround (at least in ejabberd) is to set `registration_url` for `mod_register`. In this case when a client does an iq-get on 'jabber:iq:register' a URL is returned instead of the form (if there's not been a valid token presented).
participants (3)
-
Daniel Gultsch -
Philipp Hörist -
Stefan Strigler