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

--===============6156454627023139242==
Content-Type: multipart/signed; boundary="nextPart8FqZ6lm4TKiaGvq-r-hXCw";
 micalg="pgp-sha512"; protocol="application/pgp-signature"

--nextPart8FqZ6lm4TKiaGvq-r-hXCw
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: Sun, 07 Jun 2026 18:43:50 +0200
Message-ID: <[email protected]>
In-Reply-To: <[email protected]>
References: <[email protected]>
MIME-Version: 1.0

Hi Georg,

Le mardi 2 juin 2026, 19:16:56 heure d=E2=80=99=C3=A9t=C3=A9 d=E2=80=99Euro=
pe centrale Georg Lukas a=20
=C3=A9crit :

> Personally, I have VERY strong feelings about trying to shoehorn XMPP
> into a different line on Zooko's triangle. There are many other
> protocols out there that use cryptographic keys as identities and
> optimize routing, storage and E2EE on top of that, making the whole
> construct significantly more robust and secure than we ever could
> achieve with an overlay on top of XMPP.

This is not an attempt to do anything about Zooko's triangle. The XID is no=
t=20
meant to be humanly meaningful, we have JID for that. It's mean't to be a D=
NS-
independent ID.

It's not coming from nowhere, it's inspired and made to be compatible with=
=20
Peer ID from libp2p which is a reference and widely used. It's based on a=20
widely used algorithm (Ed25519) which is used almost directly, only adapted=
 to=20
XMPP mechanisms. Any other option would probably be more complicated, and=20
would have to fit XMPP mechanism anyway.

> Is this XEP about adding a moderately-secure cryptographic proof to your
> account in order to make a XEP-0283 Moved possible if the server dies,
> or is this about having a strong cryptographic identity that can be used
> on multiple JIDs at the same time and would allow redirecting traffic
> from one to the other? I have a fear that it was designed for the
> former, but gives developers enough rope to be used for the latter.

This XEP is about having a DNS independent ID. The main use case why I need=
=20
that is for severless identification, but it's also useful in various other=
=20
used cases, including Moved. I can be used explicitly with several JID at t=
he=20
same time (because it's not tied to JID), but redirecting traffic is anothe=
r=20
story, there be dragons. Not the puprose of this protoXEP.

>=20
> The former use case can probably be implemented with a small subset of
> this protocol, or even with a signed OMEMO record on the user's pubsub.

OMEMO is per-device, that's not a good fit. And it's far more complicate to=
=20
implement. Definitely not the purpose of this XEP nor a good fit.

> As written, there is no out-of-band mechanism to verify / exchange XIDs,
> so a malicious server can just create its own MitM XIDs for all accounts
> that try to publish one, and there is no easy way around that without OOB.

There is one to share private key with QR code, but not to verify indeed, g=
ood=20
point, I'll add it.

> [SNIP]

> Detail notes on the XEP:
>  [SNIP]
>=20
> =C2=A75.1 Publishing
>=20
> Publishing a signed record containing the XID, the JID and a timestamp
> (+ validity?) would prevent somebody from maliciously publishing foreign
> XIDs on their pubsub in order to try to circumvent routing or to exhaust
> resources.

Indeed, as said in previous reply, will be integrated in future revision if=
=20
it's accepted.
=20
> [SNIP]
>=20
> =C2=A76. Identity Challenge
>=20
> I fear this protocol is full of failure cases. Off the top of my head:
>=20
> [SNIP]

Probably, that's what experimental and standard@ are for. This specificatio=
n=20
didn't aimed at being perfect on first version, and that's why feedbacks fo=
r=20
the community with people like you are important.
>=20
>=20
> =C2=A78. Server Mapping
>=20
> What is this part supposed to achieve? As I read it, this is about the
> JID used on an individual c2s link between a server and its
> client, and allowing the client to use a XID instead of the
> authenticated JID. Given that the client knows both JID and XID, and the
> server knows the JID and could authenticate the XID, this is merely
> cosmetic?
>=20
> I can see benefits in a protocol that would allow XID-based routing (i.e
> a client sends a message to=3DXID and the local server would route it
> according to the JID that has been authenticated for that destination
> XID). However, such a protocol would impose a significant cryptographic
> responsibility upon the server, upon its s2s links (to other servers
> publishing XIDs), and would require a global XID routing table in order
> to work reliably.
>=20
> Ideally, in such a scenario, message payloads should be encrypted to the
> private key corresponding to the destination XID, in order to not leak
> any relevant content to somebody intercepting the routing process ;-)

Yeah, the idea was to use XID instead of JID, and the current section is=20
mostly cosmetic indeed. I see a particular use case where it's extremely=20
useful, it's for publisher attribute in pubsub (mentioned in business model=
),=20
and other field (where the JID is used (like in XEP-0277). Today if we chan=
ge=20
the server and copy the items, they would all be marked as invalid publishe=
r=20
because of that.

But maybe that could be moved to a separate specification.

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

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

iQEzBAABCgAdFiEEsNZvWyEnjW9SVudbKqmcu6xuKwwFAmoln8YACgkQKqmcu6xu
Kwzk7AgAgIL0Zjg/J/Q2Jta/3vjaaauvYM1OT2kQKMlQQ6puauzmUjAGr0Fk3+f5
wO5t3X8kSvKiZ/w/AVvQ27L9XCYQCnEbqKAvMcpTdb98HI5WMS2Rf8QyI2jqnX7N
tB1LM97abwY2XP7EpOrASa8yJdbA6aC2a/gwJdIAPAz3Tkkv/AXKtiiEvze+GlYp
tL5AttbNUfQkwP2iJkpnnN+FBMVkzUs48BwD+AS32KpYQeH2si857x/6V+UJ+Mww
+RdzCtZIpS2Zkx3tiJ+TrZXDJt6Gd7wAcjKeph76ZP4/7D7eeenQM5vs+WS3dVzg
nlPENGTyyMwOxlwn6wRabm8qSU8cFg==
=IyZZ
-----END PGP SIGNATURE-----

--nextPart8FqZ6lm4TKiaGvq-r-hXCw--




--===============6156454627023139242==
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]

--===============6156454627023139242==--