Hi Georg, Le mardi 2 juin 2026, 19:16:56 heure d’été d’Europe centrale Georg Lukas a écrit :
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 not meant to be humanly meaningful, we have JID for that. It's mean't to be a DNS- independent ID. It's not coming from nowhere, it's inspired and made to be compatible with Peer ID from libp2p which is a reference and widely used. It's based on a widely used algorithm (Ed25519) which is used almost directly, only adapted to XMPP mechanisms. Any other option would probably be more complicated, and 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 that is for severless identification, but it's also useful in various other used cases, including Moved. I can be used explicitly with several JID at the same time (because it's not tied to JID), but redirecting traffic is another story, there be dragons. Not the puprose of this protoXEP.
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 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, good point, I'll add it.
[SNIP]
Detail notes on the XEP: [SNIP]
§5.1 Publishing
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 it's accepted.
[SNIP]
§6. Identity Challenge
I fear this protocol is full of failure cases. Off the top of my head:
[SNIP]
Probably, that's what experimental and standard@ are for. This specification didn't aimed at being perfect on first version, and that's why feedbacks for the community with people like you are important.
§8. Server Mapping
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?
I can see benefits in a protocol that would allow XID-based routing (i.e a client sends a message to=XID 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.
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 mostly cosmetic indeed. I see a particular use case where it's extremely useful, it's for publisher attribute in pubsub (mentioned in business model), and other field (where the JID is used (like in XEP-0277). Today if we change the server and copy the items, they would all be marked as invalid publisher because of that. But maybe that could be moved to a separate specification. Best, Goffi