XEP-0283: Moved

computing
#1

Continuing the discussion from Strategic Snikket:

The specific XEP I was referencing is:

https://xmpp.org/extensions/inbox/moved2.html

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 moved element 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 maiki@chat.v2.talkgroup.xyz (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 :stuck_out_tongue_winking_eye:).

Anyhow, pretty nice, for something that folks run on RPis. :slight_smile:

Strategic Snikket
#2

In the case of Snikket, it means contacts/roster info. I believe I could probably go and see what everyone’s contacts are (I don’t, we use Snikket specifically so the sysop for the service [currently me] can not read the messages).

That’s a question that comes up often in chat rooms, the admins seeing one’s roster. But Snikket is for intentional use, not open public servers. Public servers are the domain of these concerns. talkgroup is a public domain communications layer, where we train ourselves on our tools, “contact privacy” isn’t a concern we’re addressing. Same with any family server: you ultimately need to decide how much you trust any given service you use. If you are not actively practicing your discretion in such matters, now is a great time to start!

:rainbow:

#3

I’ve learned that the XSF Council decided to re-use the number of the original Moved spec, so this is available at XEP-0283: Moved.

Also, in timely news, Matthew has pushed server-side implementation in Prosody, last night: mod_auto_moved - Prosody Community Modules

mod_auto_moved

Introduction

This module implements XEP-0283: Moved, a way for contacts to notify you that they have moved to a new address.

This module is not necessary to generate such notifications - that can be done by clients, for example. What this module does is automatically verify such notifications and, if verification is successful, automatically update your roster (contact list).

Configuration

There is no configuration for this module, just add it to modules_enabled as normal.

The next phase will address integration in Prosody/Snikket, and creating a decent user interface.

:partying_face: