8 Mar
2026
8 Mar
'26
3:27 a.m.
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.
8 Mar
8 Mar
7:48 a.m.
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
9:29 a.m.
On Sun, Mar 8, 2026 at 2:49 PM Philipp Hörist <philipp(a)hoerist.com> wrote:
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 10:27, Daniel Gultsch wrote:
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".
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? 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.
9:41 a.m.
On Sun, Mar 8, 2026 at 2:49 PM Philipp Hörist <philipp(a)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.
12 Mar
12 Mar
10:50 a.m.
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
16 Mar
16 Mar
3:10 a.m.
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(a)gultsch.de>de>:
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.
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 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).
66
days inactive
74
days old
5 comments
3 participants
participants (3)
-
Daniel Gultsch -
Philipp Hörist -
Stefan Strigler