Re: Proposed XMPP Extension: XMPP Decentralized ID (XID)

--===============4596586818313778981==
Content-Type: multipart/signed; boundary="nextPartqROSUGZuSHmjDf24TQM4Jg";
 micalg="pgp-sha512"; protocol="application/pgp-signature"

--nextPartqROSUGZuSHmjDf24TQM4Jg
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"; protected-headers="v1"
From: Goffi <[email protected]>
To: XMPP Standards <[email protected]>
Date: Tue, 02 Jun 2026 14:48:08 +0200
Message-ID: <[email protected]>
In-Reply-To: 
 <CAKHUCzyNG5V1QQJ_qqDeH=j8XyOsCmgYWO4W0Z8y8DPWvPLZPw@mail.gmail.com>
MIME-Version: 1.0

Le mardi 2 juin 2026, 14:14:35 heure d=E2=80=99=C3=A9t=C3=A9 d=E2=80=99Euro=
pe centrale Dave Cridland a=20
=C3=A9crit :
> Repeating my GH comment verbatim:
Repleating my reply:

Hi @dwd thanks for your feedbacks (very valuable, as always).

=2D I've chosen `.internal` because it's reserved for private application u=
se=20
(https://en.wikipedia.org/wiki/.internal, https://www.rfc-editor.org/info/
rfc6762/#appendix-G) actually to avoid accidental reach of a real server. B=
ut=20
you're right that on private networks it can be an issue. Your `xid.xmpp.or=
g`=20
proposal can be a solution. I would like to have more inputs on it before=20
changing though.

=2D The use of JID syntax is to make XID trivially usable in many use cases=
 with=20
little to no adaptation code (I'm thinking about "from"/"to" attribute with=
=20
serverless, but in general anywhere were a JID is expected, a XID could be=
=20
used). Please note the server mapping feature, and also in business rules, =
the=20
example of "publisher" attribute for pubsub. We have also `xmpp:` URIs re-
usable without any modification.

=2D Your challenge comments are very relevant, I'll update after Council vo=
te if=20
the spec is accepted.

=2D expiry would be nice indeed. Probably not mandatory though.

=2D Multiple XIDs are already explicitly allowed, as well as having the sam=
e XID=20
for various account on different domain names.

=2D I'll have a look to what you suggest, but note that I try to make somet=
hing=20
simple and easy to implement. The first byte is there to extend algorithms=
=20
easily later if necessary (for PQ or some other reason). One of the advanta=
ges=20
of `Ed25519` is that it's already used with OMEMO, so most clients already=
=20
have an implementation.

I would like to avoid the discussion here if possible, and rather see it on=
=20
standard@ (more eyes, no need to chase feedbacks everywhere, and archives a=
re=20
easier to retrieve).


Best,
Goffi
--nextPartqROSUGZuSHmjDf24TQM4Jg
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----

iQEzBAABCgAdFiEEsNZvWyEnjW9SVudbKqmcu6xuKwwFAmoe0QgACgkQKqmcu6xu
KwyARgf+L2FP8As2BaQsvHlfniHubVp6Sb74nMhISnR0n6FgiWiJL/ddadx39zf8
QbRWj4nbWk9QJyMHRltolMm72NXKJPUE9Tpruz88kPHur0RuRwn/dbTzanrupVXq
NdJIQ1S9tUEOrtkQvqdnhCDrgL5Wj24KkS2Qu4S4lYn/SpJhk+ANfSkkA4GaixBB
uCTcWbMr8OgGGvXQH0+cppRcR5lfDkIAiJTHU1Dqb8dWTM1Jmwl4TehRXxTn/Imp
utPoFAXlzMJVAgFsQUMb302NBU9M5atIdf/dxbPbqpKwIoRwAFVtPjxabMTRIq3I
zO7SKd6o0QaNRfFiRhbPpmxl+7wY6A==
=1haG
-----END PGP SIGNATURE-----

--nextPartqROSUGZuSHmjDf24TQM4Jg--




--===============4596586818313778981==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Standards mailing list -- [email protected]
To unsubscribe send an email to [email protected]

--===============4596586818313778981==--