Supporting instances MUST indicate their support of this FEP by including its namespace in the @context of affected Actor objects.
I think it would be better to use a regular property (e.g. supportsObjectMigrations) because most Fediverse platforms don't use JSON-LD and don't parse @context. Some may not want to add @context to their objects.
Another option is FEP-844e.
A "proposed move" is an Offer[Move] activity emitted by the source instance addressed to the target instance's shared inbox (and not as:Public)
How it should work in practice? Should the URI of a sharedInbox endpoint be added to the value of to property?
Normally audience consists of actors and collections, perhaps this activity should be addressed to a server actor?
sec: https://w3id.org/security# - The Data Integrity vocabulary used by FEP-8b32 proofs.
Data Integrity and FEP-8b32 use https://w3id.org/security/data-integrity/v2
The items in the migration collection SHOULD use URI references in their object and target fields rather than inlining the materialized objects
But examples show origin and target, rather than object and target. FEP-7628 Move includes object and target.
moves
I don't fully understand what are the benefits of publishing this collection. If the source server is still online, all objects could be fetched from there. The FEP also says that moves indicates the state of migration, but later is says that migrationComplete should be added to the migration collection.
All in all, it seems that moves should be optional. That would greatly simplify the implementation.
The moves collection MUST itself be signed with an FEP-8b32 proof.
I suggest adding "by the target actor" here (currently this is stated in a different sentence).
3rd-party instances MUST NOT emit additional Update or other activities while updating migrated objects.
They won't do it anyway, because they don't own these objects. However, they might emit Update for the objects they own, e.g. when inReplyTo points to a migrated object.