Re: Feedback on XEP-0379, XEP-0401, XEP-0445

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 <[email protected]>:
>
>
> 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).
_______________________________________________
Standards mailing list -- [email protected]
To unsubscribe send an email to [email protected]