Goffi's response on Github, verbatim, with my response here (only):

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

Thanks for the rapid response!

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

My thinking is that if ".internal" is in use on private networks as a free-for-all, rather than having any global meaning. From RFC 6762, it's listed amongst "names which do not have meaning in the global context". The "proper" way of doing this would be to use a subdomain of a TLD like .arpa, or potentially make our own reserved one via the IETF like ".onion", though I seem to recall that would be hard. The only other solution I see is to use one the XSF controls.

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

That makes sense, and is what I assumed. So some kind of domain is required.

* Your challenge comments are very relevant, I'll update after Council vote if the spec is accepted.

I forgot, obviously, that it also needs a timestamp in the signed payload, to avoid replay.

* expiry would be nice indeed. Probably not mandatory though.

I wonder about this. The expiry can be updated frequently without rotating the key (and therefore XID), but it means that if a access to an account is lost, it will naturally "age out", and it also provides a simple mechanism to ensure challenges also expire predictably.

* Multiple XIDs are already explicitly allowed, as well as having the same XID for various account on different domain names.

Right. I had missed that (as I anticipated).

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

I had entirely missed the single byte (my error, I'm terrible at reading XML XEPs directly). I suggest that a single byte is insufficient. I'd pick either an HTTP/3-ish varint, or simply two octets. Just the numbers of PQ/hybrid KEMs coming out right now might get close to exhausting a single byte.

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

Agreed! Dave. On Tue, 2 Jun 2026 at 13:14, Dave Cridland <dave@cridland.net> wrote:

Repeating my GH comment verbatim:

This generally looks good, and I support publication.

Blockers for advancement:

* I don't think you can use the internal TLD here. That's a free-for-all on private networks, and in cases where a XID is confused with a JID (since they share the same syntax) it could end up resolving to an actual XMPP server. Does the syntax for a XID have to match that of a jid? If so, I'd suggest that the XSF creates a xid.xmpp.org domain for this purpose, with zero'd SRV records. * The challenge protocol is trivially MITMable. I suggest including the source jid within the signed payload, and possibly signing the challenge with the source XID too. This would mean that the challenge was mutual, and mutually verifiable, though not end-to-end of course.

Four notes:

* I would strongly consider adding an expiry to the XID publication. * I would also explicitly allow multiple XIDs - perhaps this is in place already, I didn't notice it (but haven't exhaustively searched). * I would also highly recommend examining PQ options (presumably KEM or HPKI based) and also threshold cryptography might be interesting as well. * By way of another approach worth examining, I'd suggest looking at Philip Hallam-Baker's Mesh and its id service, callsigns: https://datatracker.ietf.org/doc/html/draft-hallambaker-mesh-callsign-01

Dave.

Hello, Thanks for the late answers, I'll try to reply to all feedbacks. Le mardi 2 juin 2026, 17:44:31 heure d’été d’Europe centrale Matthew Wild a écrit :

On Tue, 2 Jun 2026 at 13:44, Dave Cridland <dave@cridland.net> wrote: [SNIP] Indeed, I doubt a reserved TLD would be approved for this specification, but given that you mentioned .onion it's worth noting that RFC 9476 did specify '.alt' for non-DNS usage.

I've missed this one, thanks for the notice Matthew. That look like a good fit to me, do you see any problem in using that? Best, Goffi

Le mardi 2 juin 2026, 17:06:27 heure d’été d’Europe centrale Marvin W. via Standards a écrit :

Hey,

I am a little confused about what is the intended scope of a XID, that is, what it is meant to identify? A device/resource? An entity? A user? Multiple users? A human?

An entity (which can be a person, a bot, a group of human, whatever), but not a device.

If we are fine with binding a XID to a specific device/resource, we could "just" use the OMEMO public key for it. Then binding the XID to a specific user in a cryptographically sane way would just be the same issue as doing that for OMEMO (which while not entirely solves, has a lot of work put into it) and there would be no additional identity or key management tasks.

OMEMO is per-device, it doesn't work here. It's also far more complicated to implement. OX could be used, but the key sharing mechanism is not specified anyway, and again it's more complicated to implement the whole thing (and it's not widespread). The current implementation is relatively easy for most clients, as Ed25519 is already used for OMEMO.

This reminds me of something I had in mind for reviving XEP-0174: adding a TXT key that carries a signature of other parts of the mDNS records, so that one can discover that a known OMEMO contact is nearby and send messages to them directly rather than through the server.

One of the main purpose of this proposal is to have a ID working for serverless, on which I'll be working soon. I've chosen something easily mappable to LibP2P's Peer ID. Best, Goffi

Hi, Le mardi 2 juin 2026, 19:30:10 heure d’été d’Europe centrale techmetx11 via Standards a écrit :

As it's written in the specs, I think the challenge protocol can be abused to leak a user's presence, because any device associated to the target user *MUST* send a message to the entity who requested the challenge, as soon as it receives it.

Indeed, that something to change, it should probably be answered only to people with presence access.

This would violate RFC 6121's guarantees to not leak the user's network availability to an entity who's not authorized to know about it.

So, I'm wondering if we could instead have the identity verification be a secondary optional method of verification, and have something like a signature of the JID (signed by the XID) in the user's PEP node, that the user themself HAVE to re-sign once every so often, like a month or week to ensure it remains valid, so that old hosts cannot impersonate users with stale signatures.

That sounds like a good option. Best, Goffi

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

Hi singpolyma, Le mardi 2 juin 2026, 19:45:11 heure d’été d’Europe centrale Stephen Paul Weber a écrit :

...

URL: https://xmpp.org/extensions/inbox/xid.html

I am unclear on the goal here. It doesn't give us e2e auth, nor does it give us decentralized routing. What can I actually accomplish with this that I cannot accomplish without it?

Indeed, it's not about auth nor routing; it's a decentralized DNS-independant ID for an entity (not a device). I need that for serverless, but it has several other use cases as explained in the protoXEP, and we don't have equivalent AFAIK for that (OX would be the closest, but more complicate and difficult to use in those case). It's inspired from Peer ID from libP2P, and relatively simple to implement and use.

I'm also concerned about formatting them as valid JIDs since this may get confusing on the live network.

That's why a `.internal` TLD was used for, but as pointed out by other in this thread, it's not the best choice. Probably `.alt` would be a better fit, as it's a non-DNS namespace. Best, Goffi

Hi Singpolyma, Le mardi 9 juin 2026, 03:02:22 heure d’été d’Europe centrale Stephen Paul Weber a écrit :

...

I need that for serverless, but it has several other use cases as explained in the protoXEP, and we don't have equivalent AFAIK for that (OX would be the closest, but more complicate and difficult to use in those case).

I think it's not going to make much sense to me until I see it in the context it's actually going to be used in... even if being a separate XEP still makes sense.

I'll be working on that (serverless) soon. However, I already have a XID implementation (with possibility to sign/verify any kind of data).

...

It's inspired from Peer ID from libP2P, and relatively simple to implement and use.

...

I'm also concerned about formatting them as valid JIDs since this may get confusing on the live network [SNIP] But even so it still looks like a JID and can parse as a JID and could end up in a part of the code that expects it to be a JID... I'm not sure this is what we would want if it's for other purposes?

That's actually a feature, it makes it usable everywhere where a JID is usable, and compatible with xmpp: scheme. See the example I'm mentioning in business rules: using a XID for "publisher" attribute in pubsub make it portable Right now, if you change server, you must change every single item due to that (I've already been hit by that). On the live network, even if it where confused, that would resolve to nowhere, so the developer would quickly find the problem. Best, Goffi

Hi MSavoritias, Le mercredi 3 juin 2026, 08:14:44 heure d’été d’Europe centrale MSavoritias via Standards a écrit :

I do not understand why the XEP is locked to OMEMO and also we roll our own identity scheme.

This protoXEP is not locked to OMEMO at all, why make you think that? OMEMO is only used for the optional automatic private key synchronization feature, and there is an alternative out-of-band QR code based method specified. This not really a scheme, it's inspired from existing solution (Peer ID from LibP2P), and it's simply using an existing widely used algorithm (Ed25519). This spec simply adapt it to XMPP mechanisms, a thing we would have to do for any solution.

What we can do instead is use a standard that is well documented and already exists for this Decentralized Identifiers

I admit that I was not aware of DIDs, but we could still have to adapt it to XMPP, and it's far more complicated to implement. The current proposal is simple and use an algorithm that most client already use. Also, the prefix byte is made to update to another method if necessary, so DIDs or anything else could be used in the future.

https://www.w3.org/TR/did-core/ this would give us:

- decoupling of the verification of identity from any centralized entity and any encryption scheme

This spec does that. The prefix byte is there to not be dependent on current encryption algorithm.

I understand that it supposedly strives to not depend on servers, but such a thing is not possible yet in xmpp due to DNS reliance. DIDs on the other hand can support multiple verification methods.

The main DNS reliance is in the JID. This proposal (again made to be easily mappable on Peer ID which is widely used) is made to not have to rely on DNS.

- our own xmpp method to resolve things to

- a standardized way to represent this and do discovery, not reinvent our own

- multiple ways of authentication besides just xmpp pubsub things

This specification use PEP which is also what is used for OMEMO and OX, and many other things. It's not reinventing anything. And other authentication method are planned, notably out-of-band via QR Code. PEP doesn't have to be the only way, it's just convenient because it has everything needed. Again, this is a protoXEP which would go as an experimental specification, made to test implementation, and see if it works or not, and how it can be improved. We are not discussing here a move to draft or final. Best, Goffi