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.