Possible bug during internal move due to incorrect alsoKnownAs assignment

[danirod]

I have a blog with ActivityPub enabled that exists since before blog profiles were a thing in this plugin. Once blog profiles were added, I switched the plugin settings to use a blog profile, started promoting it instead of the author profile, and deactivated the author profile in the plugin settings.

Now that this plugin supports moving accounts, I wanted to use the Move action in order to migrate the existing pending followers of my old profile account into the blog account. I did this using WP CLI and passing the account URLs for both the old and the new profile.

And I failed in the process. It seems that the migration has been made to the same account ID instead of the correct one:

I've checked the source code to try to understand why, and I think that there is a bug in the Move::internally function, but because I am not an expert in ActivityPub, I'm opening a discussion and not an issue because I cannot be 100% sure. It seems that this code is adding the alsoKnownAs identifier to the old account, given that $user is effectively the user object for the ID $from:

wordpress-activitypub/includes/class-move.php

Lines 135 to 149 in 19d0ea1

	public static function internally( $from, $to ) {
	$user = Actors::get_by_various( $from );
	if ( \is_wp_error( $user ) ) {
	return $user;
	}
	// Add the old account URL to alsoKnownAs.
	if ( $user->get__id() > 0 ) {
	self::update_user_also_known_as( $user->get__id(), $from );
	\update_user_option( $user->get__id(), 'activitypub_moved_to', $to );
	} else {
	self::update_blog_also_known_as( $from );
	\update_option( 'activitypub_blog_user_moved_to', $to );
	}

But I'm pretty sure this is not how the protocol works. After reading both the Mastodon and the GoToSocial docs, when you move an account from A to B, alsoKnownAs has to be set in the B profile (so, the new profile). The property to be set in account A (the old profile) is movedTo, which is correctly done in the next line for both cases of the if block.

Therefore, I think that for internal moves, a second call should be made to fetch the WordPress user behind the $to account (or ID=0 if $to is a blog profile), and then that's the account that should actually be tested in order to assign the alsoKnownAs property to it with the URL from $from.