— You got new mail address

Back when I worked for Opera, I had a proposal for an extension for mail client to mail clients update emails.

Mail clients can use extension headers, X-headers, for whatever information they want to pass along. This isn’t encouraged, but it is an available mechanism. The update emails would be hidden in a subfolder by default (except by recipients that didn’t support these extensions, but there were other tricks to keep the client chatter to a minimum).

A prime motivation was make the web/mail verification loop tighter, safer and smoother. A web form would get a token from the user agent (browser) and include that in an header in the verification email. That way the UA could know that this email was a response to user request on that web site (and link web form and responder address), and not a scam. Conversely a user could authenticate her mail with a similar challenge-response mechanism.

But I realised that this could be used for more purposes, like a change of address. Changing a mail address was painful. You had to tell everyone your new address, and you have no way of telling if they really had updated the address even if they had got that message.

I don’t have the memo here, so this is not the original syntax, but the idea was to include some header like this: x-opera-new-address-request: [email protected]

The receiving client would update the contact database with [email protected] and move the current email address into list of former email addresses, then send a reply like:
x-opera-new-address-acknowledge: [email protected]

This wouldn’t be particularly safe, so the recipient should probably send a message to the new mail address first to get a confirmation from there that it actually the new address, and that it is working, before going through the change of address, for a total of four mail messages.

But when all is done, the contact will have updated the sender’s new mail address, and the senders contact database will have confirmed that the COA is registered. That way those stragglers could be contacted more manually if it was important to the user.

The protocols of change

This back and forth chatter is the nature of all protocols, including HTTP. An HTTP conversation is usually fairly simple. The client (user agent) asks, the server provides.

This includes address changes, which in HTTP is in the 300 class of responses, like this textbook exchange. Client asks for this.file:

GET /this.file HTTP/1.1
Host: www.example.org

while the server says we do another.file at a /new-location now:

HTTP/1.1 301 Moved Permanently
Location: http://www.example.org/new-location/another.file

Client hopefully takes note and asks for this in the future

GET /new-location/another.file HTTP/1.1
Host: www.example.org

And if it doesn’t, client will get status code 301 Moved Permanently again. If the redirect ends, the client will get status code 404 File Not Found — or possibly if a new file moves into this address 200 OK and the new file instead.

This system is not very robust, by design. Things easily get lost in this “Internet file system”, and over time they generally do. That’s OK, the thinking goes, because it is fast, easy, and flexible, and if someone will maintain a persistent register, they can. At least as long as they remember to pay the renewal fees.

There are distributed file systems that do keep track of where things are, globally (and most do, locally). Instead of an address, you get an identifier, a key, that you give to a register, together with credentials that you are allowed to get the resource. The register will then find the resource this key unlocks and return that to the requester. It will not know where the resource is at, as far as it is concerned it never moves.

The register on the other hand keeps meticulous records. Instead of copying (making a copy of the original at another address) and moving files (copying and then deleting the original), it replicates and migrates them. Here the copied files are not independent, but synchronised instances of the same file. If one changes, they all do. Some go further and make the files immutable. You cannot change a file, but you can make new modified instances. Now you got yourself a versioning system.

Both approaches co-exist. The term URI (or IRI) used in web specifications reflect that, URI is collective term for URL and URN, the former being a location, an address, and the latter being a name, a tag or key to be given to the reception. The “HTTP approach” dominate. Well-designed systems have redirects when things move, so you can still find them, but unless they really are designed for posterity, they will eventually break.

Moving with Mastodon

Most systems, social or not, are not built for a move. Worst case you have to download your data by hand, and even when you can download your data, like with Facebook or Twitter or WordPress, you still have to figure out what to do next. For big and sometimes smaller systems there is usually a way. This blog has migrated once, from when Opera Software shut down their social media. Vivaldi went out of their way to make the transition to Vivaldi smooth, and largely it was.

But even when you can successfully export and reimport your entries, there are no HTTP 301 messages. All the traffic to Opera.com was gone, individual blogs as well as to the social media in general. Any links were broken. And of course Vivaldi didn’t get the Opera traffic.

Mastodon does better. You can more from one instance of Mastodon to another. Certainly not without fuss, and far from perfectly. There are losses and you depend on your followers to follow you onwards, but a huge step forward. From 404 to 301 if you like. Here is how you do it: How To Change Servers On Mastodon (And When You Should)

This is definitely better, but is it good enough? Is it how it should be? As described above, unless there is some global register we need redirects, and redirects will decay. But so does everything. There could be cooperation with an archive.org type service, so that future historians will have some threads to pick out from the rubble. Redirect is good enough, but that does not mean we can’t improve on the experience.

The duration of a redirect is not an issue. As long as the server/instance remains I have squatted https://social.vivaldi.net/@jaxroam, even if the account were deleted. But like with the mail header example above, it should be possible for the account owner to keep track of which of the follower clients have registered the move, and which haven’t, with the possibility to notify and for the followers to automatically update.

Next/previous in the timeline could also jump instances as a linked list. Assuming a clean move, the previous toot of my first one on the new instance would be my last one on the previous one, and the next toot of the previous instance would be the first of the new one. This would matter little for Mastodon, where toots presumably are many and fairly ephemeral, and people wouldn’t follow a timeline from beginning to end, but would matter more on blog posts like this.

The export/import step of moving should be unnecessary, and could be handled between the Mastodon instances directly. However, as this involves significant upkeep, the experience shouldn’t be too smooth, otherwise this could be used as a form of denial of service. There seems to be a 24 hour rule, which could be adapted and adjusted to provide the right amount of friction.

It should still be possible to download to the user’s personal repository.