I need to read up on and account migrations.

It sounds like currently, we'd need to keep shadow copies of people to update old references all over the place

like if I left PV to go to like, you could issue a "Follow" action to everyone who used to follow you to have them follow the new account (maybe? or a specialized kind of follow action - like "RedirectedFollow"?). But all of the old activities would still point to the archived account

it _feels_ like the issue is that we got dup'd content

@jalcine I used to think that since this all works like email, maybe a simple forwarder, and a proxyAddress on the new server would do the trick nicely, but over time it would get out of hand.

@thegibson right like it'd be too much to handle.

however, we can set an expiration I think; there's no reason to expect people to completely have moved over.

like it could last until all following accounts have reported that they've migrated. it might also require the following accounts to rewrite references in their objects to the new `acct:` in question


sure... something like that is required on top of forwarding to a proxy... but you'll almost never get 100% transferral due to the ephemeraL NATURE OF SOME INSTANCES.

@thegibson which might be an acceptable loss if we add ephemeral natures into the mix. I'm wondering if that Action (like "MigratedFollowBackRequest" as an extension on "AcceptFollow") could just be a UDP-esque request.

Hey, I moved. Come find me here if you can handle it.


right... just need to consider that the 100% migration rate is not the number you want to use to deactivate the forwarding.

@thegibson tbh this feels fine! If I had time, I'd hack together a PoC for tootsuite/masto

@jalcine yeah, it's just the nature of the beast... sysadmin hat tells me a 30-60-90 day expiration would fit better

@jalcine Problem is that then you can have people maliciously hijack your account be pretending to be your new account.

I think this problem was discussed before by Gargron & co and they settled on the `movedTo` semantics.

@cj how is the account hijacked? I see spoofing here since they're faking one's identity. This does bring up a point of probably making "tombstone" accounts that admins can choose to free up to prevent spoofing

@jalcine Sorry maybe I misunderstood: if the new destination account is the one sending these "MigratedFollowBackRequest", then there is the question of how to have the original (possibly no longer existent) account bless it as being authentic.

@cj ahh right. Maybe having sent it a signed message using the old account's key? this is all meant to be temporary - like sent over a period of a time then stopped

@jalcine Ah yeah, but only if the previous crypto war was actually won and PGP/GPG, key signing parties, etc were more of a thing. In practice, key management to this day is a big PITA, especially between different machines serving different domains.

@TheGibson @jalcine this is why 301 redirection is good - it means 'go here instead, and remember it for next time' Underneath all the webfinger flummery, mastodon does use urls for posts and users, so supporting this is the way to migrate as it updates.

@TheGibson @jalcine each mastodon/fediverse instance is in effect a caching proxy for the remote users and posts; it needs to update it's cache origin over time if they migrate.

@KevinMarks this doesn't work if the instance completely disappears (like DNS not resolving; server outages). Pushing info reduces the responsibility of maintaining the relationship of the deprecated account to the followee @thegibson

@jalcine @TheGibson you could recover your posts from a dead instance via the caches in other ones, and if the rel=me model is observed you can recover migration intent too. You could use Internet archive for mastodon, if not pleroma.

@KevinMarks who's the audience you're suggesting here? Like I'm thinking about automatable plumbing that can be used to build something for people who might not know what HTML is or fully grok how archiving + backups work @thegibson

@jalcine @TheGibson we're having a plumbing conversation about how to achieve seamless migration for ordinary users.
I'm making the case for basic HTTP caching, but i know there are some signing bits involved somewhere that will need a private key to be either moved or deprecated and replaced.

@KevinMarks hmm. re: signatures, I don't know too much about how HTTP signatures work to give a detailed thought on that.

But I want to avoid having people pull if the data here is conventionally pushed to them (the data being their following count) @thegibson

@jalcine @TheGibson both Salmon and ActivityPub have signature mechanisms to give confidence in passing around posts without fetching them from origin URLs - I don't know how instances cache and update the keys for verifying these. Old Salmon explanation here:

Since Friendica does habe account migration in its current protocol, I would like to implement it with AP as well, but I'm unsure how to do it.
@Jacky Alciné @Michael Vogel

Same here. ActivityPub can't be nomadic (cloned like in Zot projects) but we need a clean signal about moving. Mastodon has a "moved" indicator in the actor record but this is only valid if the original site is still up and best I can tell only if you try and access the old account. Still it's something. There is a Move verb in the vocabulary. Don't know if Mastodon is using it, but I would think that a move activity (object  = source actor, target = destination) would work as long as all the source and destination servers were running. I know a certain pleroma dev that will shit bricks about this, but I want a mechanism to prove that the destination is in fact controlled by the same individual as the source and we don't have a good mechanism for this in the protocol. Perhaps if the Move message has an LD signature for both entities. It might be pushing the capabilities of ldsigs a wee bit but I think it is legal for signature to be an array (In ActivityPub, nearly everything can be an array, but few projects expect to receive more than one thing in most cases).
@mike I do trust you more concerning this protocol stuff than I trust myself. In fact I opened an issue at the W3C for that:… - but got no good answer.
Sign in to participate in the conversation
Social @ PV

Social is the primary social media platform for the forth coming fourth version of Play Vicious, a new initiative built to bring attention to the plethora of creative acts that don't get the shine they deserve.
For more details about the project and how to support, go here.