2 Jun
2026
2 Jun
'26
2:39 a.m.
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: XMPP Decentralized ID (XID)
Abstract:
XMPP Decentralized ID (XID) is a DNS independent XMPP entity
identifier. This specification describes how to generate, use, and
handle them.
URL: https://xmpp.org/extensions/inbox/xid.html
The Council will decide in the next two weeks whether to accept this
proposal as an official XEP.
2 Jun
2 Jun
5:14 a.m.
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.
5:30 a.m.
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(a)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.
8:44 a.m.
On Tue, 2 Jun 2026 at 13:44, Dave Cridland <dave(a)cridland.net> wrote:
Goffi's response on Github, verbatim, with my response here (only):
Yeah, .internal is not actually stated as reserved by RFC 6762, in
fact it specifically says "We do not recommend use of unregistered
top-level domains at all". It just lists '.internal' among a bunch of
names which have traditionally been used for private networks. Using
it risks conflicts with private servers on such networks.
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.
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.
Regards,
Matthew
7 Jun
7 Jun
9:10 a.m.
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(a)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
2 Jun
2 Jun
5:48 a.m.
Le mardi 2 juin 2026, 14:14:35 heure d’été d’Europe centrale Dave Cridland a
écrit :
Repeating my GH comment verbatim:
Repleating my
reply:
Hi @dwd thanks for your feedbacks (very valuable, as always).
- 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.
- 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.
- Your challenge comments are very relevant, I'll update after Council vote if
the spec is accepted.
- expiry would be nice indeed. Probably not mandatory though.
- Multiple XIDs are already explicitly allowed, as well as having the same XID
for various account on different domain names.
- 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 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).
Best,
Goffi
8:06 a.m.
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?
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.
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.
Marvin
On Tue, 2026-06-02 at 09:39 +0000, Daniel Gultsch wrote:
The XMPP Extensions Editor has received a proposal for
a new XEP.
Title: XMPP Decentralized ID (XID)
Abstract:
XMPP Decentralized ID (XID) is a DNS independent XMPP entity
identifier. This specification describes how to generate, use, and
handle them.
URL: https://xmpp.org/extensions/inbox/xid.html
The Council will decide in the next two weeks whether to accept this
proposal as an official XEP.
9:11 a.m.
On Tue, 2 Jun 2026 at 16:42, Marvin W. via Standards <standards(a)xmpp.org>
wrote:
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?
I understood a XID to identify a single entity who may have multiple
devices spread across multiple accounts (and serverless as well) both
concurrently and consecutively.
I got that from the first para of the Introduction - obviously I don't have
any objection to stating it explicitly.
Dave.
9:36 a.m.
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
10:30 a.m.
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.
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.
On 6/2/26 5:36 PM, Goffi wrote:
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
_______________________________________________
Standards mailing list -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
7 Jun
7 Jun
9:12 a.m.
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
2 Jun
2 Jun
10:16 a.m.
* Daniel Gultsch <daniel(a)gultsch.de> [2026-06-02 11:50]:
Title: XMPP Decentralized ID (XID)
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.
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.
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.
Most of my following remarks are considering the latter use case.
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.
That said, I'm with Marvin on strongly coupling a cryptographic identity
(XID) with OMEMO (which would require a user identity as opposed to a
device identity for being used as a XID, though).
Detail notes on the XEP:
§3 Overview
I'm with Dave on creating a `xid.xmpp.org` domain for this purpose.
§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.
Validating the signed record can be done offline and does not require
the Identity Challenge handshake at all.
Routing the messages to the JID that has published the highest correctly
signed timestamp value for a given XID would reduce the time window where
a server admin can take over your identity (did I mention Zooko yet?).
§5.2 Revoking
I have a gut feeling that a revocation record should also contain the
XID, the JID and the timestamp of revocation, in order to prevent
malicious revocation by the server admin.
OTOH, losing access to your private key would make the XID irrevocable
in such a design.
§6. Identity Challenge
I fear this protocol is full of failure cases. Off the top of my head:
How long do you wait until you consider a challenge as "timed out"? What
do you do in that case?
If you challenge the new XID of a user with a (now revoked) old XID, do
you treat both as invalid until the new one is validated?
What happens if user A publishes a new XID and multiple devices of user
B send different challenges at the same time (with equal timestamp)?
§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 ;-)
Georg
7 Jun
7 Jun
9:43 a.m.
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
2 Jun
2 Jun
10:45 a.m.
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?
I'm also concerned about formatting them as valid JIDs since this may get
confusing on the live network.
7 Jun
7 Jun
9:50 a.m.
Hi singpolyma,
Le mardi 2 juin 2026, 19:45:11 heure d’été d’Europe centrale Stephen Paul
Weber a écrit :
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
8 Jun
8 Jun
6:02 p.m.
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.
It's inspired from Peer ID from libP2P, and
relatively simple to implement and
use.
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?
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.
9 Jun
9 Jun
12:07 a.m.
Hi Singpolyma,
Le mardi 9 juin 2026, 03:02:22 heure d’été d’Europe centrale Stephen Paul
Weber a écrit :
I'll be working on that (serverless) soon.
However, I already have a XID implementation (with possibility to sign/verify
any kind of data).
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
>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. >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? 
2 Jun
2 Jun
11:14 p.m.
I do not understand why the XEP is locked to OMEMO and also we roll our
own identity scheme.
What we can do instead is use a standard that is well documented and
already exists for this Decentralized Identifiers
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
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.
- 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
MSavoritias
On 6/2/26 12:39, Daniel Gultsch wrote:
The XMPP Extensions Editor has received a proposal for
a new XEP.
Title: XMPP Decentralized ID (XID)
Abstract:
XMPP Decentralized ID (XID) is a DNS independent XMPP entity
identifier. This specification describes how to generate, use, and
handle them.
URL: https://xmpp.org/extensions/inbox/xid.html
The Council will decide in the next two weeks whether to accept this
proposal as an official XEP.
_______________________________________________
Standards mailing list -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
7 Jun
7 Jun
10:08 a.m.
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
8 Jun
8 Jun
8:51 a.m.
On 6/7/26 20:08, Goffi wrote:
It is more complicated indeed, but i think that comes with the
territory. Decentralized ID is not an easy thing to do.
Aside from the algorithm, which we can just generate something, the
problem is to figure out how to discover, verify and make identities
"portable" in some way.
I can't comment whether the XEP way of doing discovery or verification
is private or secure, which is what we get with DIDs. They have had more
scrutiny and more diverse knowledge poured into them.
The part that it is
reinventing is how to do decentralized/nomadic
identities.
The multiple ways of doing authentication i meant that DIDs can have
multiple ways of verifying an identity.
This could help for example movim or libervia in your case by using HTTP
urls or dns for verification, but also fall back to something else (or
multiple) for other uses. For example xmpp pubsub or tor or i2p.
It would also gives us multiple ways of doing said keys with OX and
OMEMO both being possible in the same DID document. From what i see it
could even be used for passwords or doing things to your account.
My concern with temporary solutions, is that they become permanent
really fast. XSF experimental XEPs can and are implemented widely (there
are other threads for that) so conversations about requirments and what
we built are all the more important before we have some proposal ready
to implement.
Regards,
MSavoritias
Hi MSavoritias,
Le mercredi 3 juin 2026, 08:14:44 heure d’été d’Europe centrale MSavoritias
via Standards a écrit :
Ah right sorry i read a bit too fast ^^'
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
_______________________________________________
Standards mailing list -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
9 Jun
9 Jun
8:29 a.m.
Just a bit of bikeshedding (I'm not gigabrain enough to comment on much else here),
but I would really prefer the term XDID over XID.
I frequently see XID used as a synonym of JID in various communities for various reasons,
and it'd be annoying to assign an unrelated but similar meaning to the term at the
same time.
Furthermore, the term XID omits the one word that even differentiates it from the existing
XID/JIDs: decentralisation. Why pretend the most important part doesn't matter?
This was brought up in the XSF MUC, for which the only response was that XDID is
"uglier" than XID. I don't think we should be prioritising aesthetic over
meaningful and unambiguous terminology.
On 2 June 2026 9:39:25 am UTC, Daniel Gultsch <daniel(a)gultsch.de> wrote:
The XMPP Extensions Editor has received a proposal for
a new XEP.
Title: XMPP Decentralized ID (XID)
Abstract:
XMPP Decentralized ID (XID) is a DNS independent XMPP entity
identifier. This specification describes how to generate, use, and
handle them.
URL: https://xmpp.org/extensions/inbox/xid.html
The Council will decide in the next two weeks whether to accept this
proposal as an official XEP.
_______________________________________________
Standards mailing list -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
16 Jun
16 Jun
3:58 a.m.
Hi,
Sorry for the late answer.
Le mardi 9 juin 2026, 17:29:38 heure d’été d’Europe centrale snit via
Standards a écrit :
Just a bit of bikeshedding (I'm not gigabrain
enough to comment on much else
here), but I would really prefer the term XDID over
XID.
I frequently see XID used as a synonym of JID in
various communities for
various reasons, and it'd be annoying to assign an
unrelated but similar
meaning to the term at the same time.
Furthermore, the term XID omits the one word that even
differentiates it from
the existing XID/JIDs: decentralisation. Why pretend the
most important part
doesn't matter?
This was brought up in the XSF MUC, for which the only
response was that
XDID is "uglier" than XID. I don't think we should
be prioritising aesthetic
over meaningful and unambiguous terminology.
The actual response was to ask if "XID" was used in any spec or if there are
proof that it's widely used (and this has not been answered as far as I can
tell). The official acronym for XMPP identifier is `JID` for historical reasons.
XDID would actually be confusing with https://www.w3.org/TR/did-1.0/ that was
mentioned elsewhere in this thread.
"Ugly" is not prioritizing aesthetic: if humans have to share this ID, a user-
friendly name is better.
However, I'm not fully opposed to change the name, but I find "XID" quite
good,
and I don't recall seeing it used instead of "JID" (I sometime see the
larger
form "XMPP ID").
We can see during experimental phase if it is really confusing and causing
troubles, in which case another names will be explored.
Best,
Goffi
12
days inactive
26
days old
21 comments
10 participants
participants (10)
-
Daniel Gultsch -
Dave Cridland -
Georg Lukas -
Goffi -
Marvin W. -
Matthew Wild -
MSavoritias -
snit -
Stephen Paul Weber -
techmetx11