Continuing the discussion from Strategic Snikket:
The specific XEP I was referencing is:
Moved 2.0 is being worked on by Matthew Wild, and for the user equates to account portability between services; your identity changes (your XMPP address), while the XEP in question provides mechanisms for notifying and updating your contact list of the identity change.
- Users should be able to notify their contacts of a change of address.
- Contacts should be able to verify that such a notification is legitimate, to prevent malicious actors from spoofing notifications.
- It should be possible for a contact’s server to automatically update the contact’s roster for seamless migrations.
- In the absence of a contact’s support for this protocol, it should fall back to a simple manual subscription approval.
I think it’s pretty neat how it works, considering the multi-client/server arrangement for each XMPP user. I’ll paraphrase:
- With a new account already created, you set a statement on the your old server which includes the new account address
- You add your contacts to the new account, sending a subscription notification to each contact including the
movedelement with the old account
- Then the contact verifies the contact change, in one of two ways:
- Client-side, the client checks the old accounts statement and verifies the accounts match, and if so the contact is notified of the change and prompted to accept it
- Server-side, the server does all of it, and if the accounts match the server creates the new contact along some neat rules
The server-side part is really hot! I’ve removed the code samples, but check out what it does:
Upon successful verification, the server MUST NOT forward the stanza to Romeo’s clients, but instead MUST create a roster entry for the new JID with a subscription of ‘from’ (sending out the appropriate roster push), and then auto-reply to the subscription request with a presence of type ‘subscribed’.
After authorizing the new JID, the server should revoke the presence subscription of the old account.
Finally, if the old JID was in the user’s roster with a subscription of ‘both’, the server MUST also send a presence of type ‘subscribe’ to the new JID in order to seek establishment of a mutual subscription.
Here’s why I’m excited for this: Matthew is also building the Snikket project, meaning Snikket will have Moved 2.0 support! Which means porting between Snikket instances could in theory be seamless for many users. That certainly opens up a lot of new use cases!
For instance, my address is currently
email@example.com (XMPP links don’t currently render in Discourse, but could be added, see Bug(s) in Discourse handing of URIs in markdown content - bug - Discourse Meta), and one day I think we might have
chat.v3.talkgroup.xyz, or I might want to do a different domain for whatever purpose. I would be able to do so without fear of losing my contacts.
Moving from v2 to v3 is particularly interesting to me. It means rather than holding on to users’ data indefinitely all talkgroup services come with built-in expiration (I mean, it’s on the scale of decades, but still… other organizations are not as stable as our project, and will benefit from portability more frequently ).
Anyhow, pretty nice, for something that folks run on RPis.