Migratory Accounts


#22

Thinking along here a bit, I get the impression that maybe the biggest challenge with migration is allowing pre-migration links to still work after migration - at least follows and profile links, if not all content links (which would be ideal.)

The problem with this method, of course, is that if mastohost.one goes down, so do all of the links.

We’re also assuming here that the instance Alice wants to leave (mastohost.one) actually supports this shiny new migration feature - and we actually don’t want to assume anything about that instance, at least if we want to help people migrate away from badly-maintained instances which haven’t been updated in a while.

Ideally I think the rerouting migrated content should be something that propagates through the network. If we could count on mastohost.one supporting migration, we could start propagating the updated routes by having it send out a notification to any instance with users who follow the migrating account, giving them the full set of re-mappings of old to new URIs/URLs. This way the moment you leave mastohost.one, you no longer depend on that server for anything anymore. (You do depend on your followers’ instances being up to date enough to handle your migration.)

But we can’t count on mastohost.one for anything, and if we allow mastohost.two to announce it’s now alice’s home, we’re also creating a way for rogue instances to hijack an identity, which would be disastrous.

Have other federated networks solved these problems somehow? The “clone” solution from Hubzilla as @zotlabs described it sounds like mastohost.one would have to stay alive - if one of the clones’ instance dies, would followers still have access to the remaining clones and their content?

Maybe there’s some cryptography-based solution to all this. My understanding of cryptography is kinda shaky but I suspect something like the following should be possible:

  1. When following Alice at mastohost.one, mastohost.foo get some kind of public secret, allowing Alice’s identity to be authenticated but not impersonated
  2. When migrating, mastohost.two gets Alice’s private secret from mastohost.one, allowing mastohost.two to prove that it’s Alice’s authentic home now
  3. Once migration is complete and confirmed, mastohost.two sends a migration notice out to all of Alice’s followers, signed using their private secret so that mastohost.foo and mastohost.baz know this is something Alice really chose to do, propagating a routing table for Alice’s migrated profile and all of her content

As a side effect, this kind of system would also allow an instance to change domain names safely without breaking all follows and links to it, and again without allowing impersonation.

I hope these thoughts are helpful. :slight_smile:


#23

We’re also assuming here that the instance Alice wants to leave (mastohost.one) actually supports this shiny new migration feature - and we actually don’t want to assume anything about that instance, at least if we want to help people migrate away from badly-maintained instances which haven’t been updated in a while.

This is true, but I think that’s going to be a thing that likely cannot be helped. I’d think the best defense for that issue is to get the migration feature in as early as reasonably possible, so that less enthusiastic instances about updates might still eventually end up with it, and so that ones that update enthusiastically but eventually ‘fall off’ can still be migrated away from.

Unless some sort of universal dead-admin-switch is in place for instances (and I’d be REALLY hesitant to have something like that), there’s always going to be the possibility of admins failing to update/maintain, and probably not a lot of great ways around it.

But we can’t count on mastohost.one for anything, and if we allow mastohost.two to announce it’s now alice’s home, we’re also creating a way for rogue instances to hijack an identity, which would be disastrous.

This would be a huge vulnerability, and absolutely needs guarding against, IMO. (And thank you for bringing it up!)


#24

If one of the clones’ instance dies, would followers still have access to the remaining clones and their content?

Yes.


#25

I like this idea.
I’d like to couple this with an export option as well though, to allow for periodic backup and an option for users to maintain that private key and a database of their posts just in case a disastrous event takes out a node.


#26

I feel like this might be where Keybase would be useful? Not necessarily about the storage aspect – that’d ideally be user-directable, and I have no idea how Keybase would look at that level of interweaving – but the keys and such.

My understanding is that Gargron already reached out but hasn’t heard back – not sure if/how that sort of thing can be made to seem of higher import to them, but maybe others have some ideas on it?