Part of #47. This issue covers the receiving side of account migration: letting a bot list other actors as its aliases, so that an account on Mastodon (or anything else that implements Move) can move its followers to the bot.
The immediate motivation is the fedidevs repeater account, which lives on channel.org and has to find a new home before the instance closes in October. Rebuilding it as a BotKit bot is an option its maintainer is considering, and that option is far more attractive if the followers come along. This sub-issue is also the smallest of the three, so it should land in 0.6.0 without waiting for #49 or #50.
Why this is enough on its own
In a Mastodon migration, the old server does all the sending. Before it lets a user start, its migration form checks that the target's alsoKnownAs includes the old account's URI. It then sends a Move to the old account's followers, and each follower's server runs the same check again before sending a Follow to the target and unfollowing the old account.
So from the new account's side, the only requirements are advertising the alias and accepting the follows that arrive. BotKit already does the second part: with the default followerPolicy of "accept", the incoming Follows are accepted automatically, and with "manual" they reach onFollow like any other follow request.
The aliases option
Add an aliases option to CreateBotOptions, next to properties, and to BotProfile so bots in a dynamic group can set it per bot:
/**
* The URIs of other actors that represent the same bot, published as
* the actor's `alsoKnownAs`. An account elsewhere can move its followers
* to this bot only if its actor URI is listed here. It can be changed
* after the bot is federated.
* @since 0.6.0
*/
readonly aliases?: readonly URL[];
Expose it as readonly aliases: readonly URL[] on the Bot interface as well, defaulting to an empty array, the way followerPolicy is exposed. dispatchActor() passes it through as aliases when constructing the actor.
The values are actor URIs, not handles or profile page URLs. For a Mastodon account those differ: @fedidevs@channel.org has the actor URI https://channel.org/users/fedidevs, while its profile page is https://channel.org/@fedidevs. Mastodon compares URIs exactly, so a profile page URL in aliases would silently fail the check. Accepting handles and resolving them through WebFinger would be friendlier, but it means network requests during actor dispatch plus a cache to keep them off the hot path. That can come later without breaking this API.
Documentation
Add a section to the docs on moving an existing account to a BotKit bot. It should walk through the order that matters: deploy the bot with the old actor URI in aliases first, then start the migration from the old account's settings, since Mastodon refuses to start one while the target lacks the alias. It should also explain how to find an actor URI, and note that what moves is the follower list only, not posts.
Part of #47. This issue covers the receiving side of account migration: letting a bot list other actors as its aliases, so that an account on Mastodon (or anything else that implements
Move) can move its followers to the bot.The immediate motivation is the fedidevs repeater account, which lives on channel.org and has to find a new home before the instance closes in October. Rebuilding it as a BotKit bot is an option its maintainer is considering, and that option is far more attractive if the followers come along. This sub-issue is also the smallest of the three, so it should land in 0.6.0 without waiting for #49 or #50.
Why this is enough on its own
In a Mastodon migration, the old server does all the sending. Before it lets a user start, its migration form checks that the target's
alsoKnownAsincludes the old account's URI. It then sends aMoveto the old account's followers, and each follower's server runs the same check again before sending aFollowto the target and unfollowing the old account.So from the new account's side, the only requirements are advertising the alias and accepting the follows that arrive. BotKit already does the second part: with the default
followerPolicyof"accept", the incomingFollows are accepted automatically, and with"manual"they reachonFollowlike any other follow request.The
aliasesoptionAdd an
aliasesoption toCreateBotOptions, next toproperties, and toBotProfileso bots in a dynamic group can set it per bot:Expose it as
readonly aliases: readonly URL[]on theBotinterface as well, defaulting to an empty array, the wayfollowerPolicyis exposed.dispatchActor()passes it through asaliaseswhen constructing the actor.The values are actor URIs, not handles or profile page URLs. For a Mastodon account those differ:
@fedidevs@channel.orghas the actor URIhttps://channel.org/users/fedidevs, while its profile page ishttps://channel.org/@fedidevs. Mastodon compares URIs exactly, so a profile page URL inaliaseswould silently fail the check. Accepting handles and resolving them through WebFinger would be friendlier, but it means network requests during actor dispatch plus a cache to keep them off the hot path. That can come later without breaking this API.Documentation
Add a section to the docs on moving an existing account to a BotKit bot. It should walk through the order that matters: deploy the bot with the old actor URI in
aliasesfirst, then start the migration from the old account's settings, since Mastodon refuses to start one while the target lacks the alias. It should also explain how to find an actor URI, and note that what moves is the follower list only, not posts.