Alright it's late and i need to go to bed, but here's a draft FEP to do full account migration with posts and whatever other kinda objects you want ...

submitted by

Alright it's late and i need to go to bed, but here's a draft FEP to do full account migration with posts and whatever other kinda objects you want to bring with you. It's a trivial expansion of existing ActivityPub/streams systems and supports gradual migration as it's implemented and after an account migration. It should be possible to migrate pretty much everything this way, both private and public objects.

criticism, feedback, revisions, etc. welcome - i don't think this is a "final version" and there are certainly things i overlooked.

codeberg.org/fediverse/fep/src

codeberg.org/fediverse/fep/pul

#MoveAllPosts #FediDev #FEP #FEP_1580 #FullMigration #AccountMigration

10
1

Log in to comment

Hot Top New Old

This looks fine to me, great to see many edge cases considered.

 reply
1
OP

and no it doesn't require emitting and processing 100,000 Move activities to 10,000 instances at once

 reply
1
OP

i think i'm supposed to direct discussion here, but i also linked back here from there, so idk in the spirit of everything being everywhere as far as i'm concerned go hogwild and yell at me online wherever you want

socialhub.activitypub.rocks/t/

 reply
1
OP

i'm almost disappointed bc it's so simple and obvious. there are a lot of caveats and requirements there because i was trying to make it clear enough to be implementable, but really it's as simple as doing this: neuromatch.social/@jonny/11533

 reply
1
edited

jonny@neuromatch.social FWIW there’s no need to use SocialHub. You could post a discussion thread anywhere (like ActivityPub.Space, GitHub, a WordPress blog, etc… and yes, even a Mastodon status can be a starting point for discussion.)

 reply
1

@julian @jonny SocialHub is not a bad place though - FEP category is federated

https://socialhub.activitypub.rocks/ap/object/bee813d28b0947ffce97f8c2bbebb955

 reply
1

Of course, not trying to say otherwise. Just that there is a preconception that jonny@neuromatch.social had to post there as part of the FEP process, which even I was under the assumption of.

We chatted about that and you disabused me of that notion :smirk:

 reply
2

> The mapping from old to new URIs is not knowable in advance, as the local IDs used by one instance software need not map onto the IDs used by another[...]

@jonny frankly you're making it more difficult for yourself here. There's no actual reason why regenerating all IDs should be necessary.

You're forcing the new server to do processing for every moved object, which is very inefficient.

A good proposal should try to make the whole move in one batch. Keep the existing ID paths and mitigate against collisions by having them namespaced properly in the first place (which I think most servers kinda do already).

 reply
1
OP

@mariusor cool well i figured that the URI mapping step (which is cheap) was a good compromise vs "modifying the URI structure in every existing fediverse app to support proper namespacing" especially since you do need to hit each object to update the proofs anyway, but note taken.

 reply
1
Insert image