On 6/7/26 20:08, Goffi wrote:
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. Ah right sorry i read a bit too fast ^^'
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.
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.
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.
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
Best, Goffi
_______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org