Account Migration

tchambers · July 27, 2023, 1:03am

Does this article help?

And: Migrating Servers - Cutie City Guide

helge · July 27, 2023, 7:06am

If both your old and new home servers are running the most up-to-date version of Mastodon, you will probably be able to automatically bring over your followers and manually export and then upload your following lists, mutes and blocks, and bookmarks.

WTF! Whose volunteering to build a tool to automate this?

As I often say, there is small fixable stuff. Not exactly sure how to best communicate this stuff, but this seems like something someone with experience in the Mastodon API and a feeling how to build UX for the common man, should be able to do in a “short timeframe”.

Your username: Your old one will no longer work, and your old profile will link to your new one.

Again WTF! I would claim one should report this as a bug. A request to https://mastodon.social/.well-known/webfinger=acct:kissane@mastodon.social should return the new information. That’s what webfinger is for.

Your followers’ lists: If any of your followers made a list (like “people I follow who post flowers” or whatever) and put you on it, you won’t be on it after you move. (Your old dead username will be. Your new live username won’t.) I know this only because someone who follows me noticed I’d gone missing from a list.

Also probably a bug …

bumblefudge · July 27, 2023, 8:45am

A ton! If converting this to a markdown table or list of user stories or other more familiar form-factor and calling that an informational FEP would be helpful, I could jump on that next week. Unless @kalfa already started? I never heard back, starting to wonder I gave them the wrong contact info or something

bumblefudge · July 27, 2023, 9:21am

Hmmm, I just created a mas.to account and “moved” it to my real account, and
https://mastodon.social/.well-known/webfinger=acct:bumblefudge@mas.to
is just 404ing. as is
https://mastodon.social/well-known/webfinger?resource=acct:bumblefudge@mast.do
and
https://mastodon.social/well-known/webfinger?resource=acct:by_caballero@mastodon.social
. On the other hand,
https://mas.to/.well-known/webfinger?resource=acct:bumblefudge@mas.to
(the dummy migrated account) works, but doesn’t include any link to my main account. I presume that’s because Mastodon’s definition of Move makes the old account “re-activatable” as opposed to permanently tombstoned. Thinking about account takeover and corner-cases, I can see how using webfinger as auth-forwarder would be messy and risky if re-activiation was a goal.

To be honest, I’m new to the mechanics of Webfinger, I only know have a kind of bird’s eye/happy path notion of how it works, so I don’t really understand what all the options are there, or the exact semantics on the WebFinger side that a Move FEP could be mapping to them as MUSTs and MAYs

Perhaps how Webfinger works in other contexts (AP and non-AP alike) would be a good topic for an upcoming SWICG meeting? if someone volunteered to lead with a screen-shared, recorded tour of Webfinger spec and/or implementations and/or diagrams, I think that would be a helpful level-set and community-building contribution, not just for migration FEP purposes but for helping all decent social developers (particularly newbies!) to get a firm grip on the various ways they could be using WebFinger. It doesn’t need to be an expert or a spec co-author or anything, it could just be someone who studied a few different implementations and could walk the group through some show-and-tell. Selfishly, I’m trying to manifest this into existence

stevebate · July 27, 2023, 10:41am

As you know, Webfinger usage is not part of AP or required by it. My understanding is that it is used to compensate for Mastodon using account identifiers instead of AP actor URIs for identifying its internal accounts. Unfortunately, Mastodon requires other servers that federate with it to also implement Webfinger. I think this is relevant to any FEP referencing Webfinger, even if it’s just a footnote for AP implementors.

That said, Fediverse usage of Webfinger is pretty simple. In the simplest case it’s just a small static file (for a single resource). However, I’ve implemented Webfinger several times now (for Mastodon-compatible interop) and it’s typically 10-20 lines of code.

bumblefudge · July 27, 2023, 1:37pm

Good point! I know the AP spec left AuthN out of scope and a lot of the Fediverse has been using webfinger and OIDC in a somewhat tribal/unspecified way ever since. And I also know that webfinger was “not invented here,” although at least one of the authors is a big supporter and user of the Fediverse and could have his arm twisted to attend such a meeting.

But I take your procedural point that something so implementation/AuthN-system specific should probably form part of a FEP only in a non-normative appendix like “Legacy considerations” or “Implementation guidance”, that’s entirely fair. I still feel that thinking through the upgrade path from status quo to something that federates more easily helps get buy-in from today’s implementations, and makes it easier to find volunteers to actually write the PRs, right? This is one of those collaborative superpowers that accrues to a healthy community group. And in this case, I think it can still adds plenty of value to non-AP social web participants, including networks that use none of the specs incubated here.

stevebate · July 27, 2023, 2:41pm

I think it’s fair to say that the Webfinger specification per se is not related to authN at all although Mastodon uses it as part its platform-specific authN functionality. I’m not concerned about NIH, but being clear about what is in the AP scope and what are optional extensions (possibly platform-specific ones) is good IMO.

helge · July 27, 2023, 4:17pm

I don’t think webfinger is really “mechanics” heavy. It’s more a “meaning” heavy subject. From a conceptual level Webfinger is the following function

URI on domain ->  list of URL resources

Entries of the list of URL resources are identified by a type, rel, and possibly other things.

The entire complication with authentication comes in, because of the decision to identify by @username@domain, i.e. acct:username@domain, instead of the Actor URI. We need now to check that the two way identification Actor ↔ Webfinger is valid, when retrieving an Account.

If one just sets the old account, i.e. alice@old_server to point to the new actor, no Authentication is needed.

bumblefudge · July 27, 2023, 9:15pm

This is very helpful, thanks. And totally agreed, @stevebate , that the top priority is to design Migration for systems that use Actor URIs so as to keep platform details like AuthN separated out as much as possible! I’m grateful for the help understanding these “quirks” of Mastodon’s design.

silverpill · September 1, 2023, 10:04pm

I started to write account migration FEP: feps/fep-7628.md at main - feps - Codeberg.org.

This proposal introduces the concept of “linked actors”, and attempts to generalize existing solutions.

It is not finished yet, so I’m not submitting it to the FEP repo. Feedback is welcome!

silverpill · September 15, 2023, 2:17pm

Updated the FEP-7628 draft. I think rel-me links can be potentially used for linking actors, so I mentioned them there. Also added references to Streams and its Nomadic Identity implementation.

EDIT: rel-me requires a trusted website, so this method should be discouraged. However, I’d like to keep it in proposal for completeness.

trwnh · September 15, 2023, 3:42pm

rel-me could point not to another “trusted website” but also to another actor. imagine bidirectional rel-me with FEP-fb2a for example, working like alsoKnownAs works in mastodon, but potentially freeing up alsoKnownAs for its actual defined usage in DIDs of “same-resource” rather than “same-controller” semantics.

helge · September 15, 2023, 4:31pm

@silverpill Thank you for writing this.

Some comments:

Different actors are considered associated with one person if they are linked.

I would prefer the term “persona” instead of person. A person can have multiple personas. For example, I could have a persona to promote FEPs and another to announce cow pictures.

Upon receiving this activity, all actors following object MAY un-follow it and MUST follow target.

I would like more details here. First there are two cases here: object in following and object in followers.

Second, there are two ways to interpret “follow”

Quietly update the following collection on a Move Activity, i.e. remove object from following and add target to following.
Loudly update the following collection. This means send an Undo Follow to object. Send a Follow to target, and expect an Accept answer.

Before doing that, recipients of Move activity MUST verify that two actors are linked.

I would prefer if something like “a valid Move activity”. This would simplify the logical constructs. So for a valid Move do the move. A Move is valid, if it is a Move and satisfies the validity constraints.

movedTo and copiedTo properties

I think it should be added that an Actor with the movedTo property should not receive messages. This means that when sending messages, one should check that the actor does not have the movedTo property. The usual caveats about caching Actors apply.

Probably an algorithm for what to do when movedTo is set would be good.

trwnh · September 15, 2023, 10:43pm

one thing i missed

Upon receiving this activity, all actors following object MAY un-follow it and MUST follow target

i don’t think that should be a MUST. you could generate a notification as pleroma does. i’d say change that to a SHOULD. maybe SHOULD either follow the target or otherwise notify the user that their contact has moved

silverpill · September 16, 2023, 6:55am

Thank you @helge and @trwnh , all good suggestions, I have updated the proposal again: FEP-7628: Update proposal · 6ef4622868 - feps - Codeberg.org

For some reason I can’t wrap my head around this . It doesn’t actually require a trusted website, as rel-me link is considered verified if it goes in both directions, right? The website owner can’t just add a link to actor’s profile and steal followers.

That’s possible, although I’d like to note that usage in DIDs is “same-subject”, not “same-resource”, and I now think that Mastodon is using this property correctly.

I decided to go with this, but it’s not clear how it should be reconciled with “don’t send activities to actor with movedTo property”.

tchambers · December 2, 2023, 9:29pm

What is the next step here on this FEP? Looking it over, but does this cover all followers, following, lists, mutes, blocks and bookmarks?

silverpill · December 6, 2023, 7:43pm

I submitted my proposal to FEP repository: fep/fep-7628.md at main - fep - Codeberg.org

And there’s now a dedicated topic on SocialHub: FEP-7628: Move actor

The proposal only covers followers, because migration of followers requires coordination between servers (using Move activity). Following, lists, mutes, blocks and bookmarks can be simply exported and then imported to a new server, so I think these are out of scope.

Overall, I’m beginning to think that this approach to migration is a technological dead end. It would be better if we stop attaching accounts and posts to any particular server.

helge · December 7, 2023, 3:48pm

I think a big problem here is that a lot of issues are being conflated into “account migration”. Current “Move actor” could be described as a way to transfer followers collections. That’s hard, because you need many servers to cooperate.

There is a bunch of other data, some examples are listed by @tchambers above. If we subscribe to the value “A user should own their data”, one should obviously have an export functionality for this data. This is really independent of any “account migrations” questions. This should just exist. There are probably even laws in the EU that say that this should exist.

By the very nature of the inbox being an endpoint receiving POST requests, it needs to be attached to a server. So one cannot migrate away from servers without a lot of work …

I agree for posts. However I can imagine running into problems like “Where do I GET the replies collection?” if the post is not managed by a server. This requires some planning.

stevebate · December 7, 2023, 5:30pm

An inbox is not an account (or actor). For example, an AP-conformant server could have a single inbox endpoint for all accounts (sharedInbox) or the endpoint could serve as the gateway to a cluster of servers behind an AP façade. The account/actor could theoretically have a URI not tied to a specific server. Of course, you’d need to define how the URI would be dereferenced (like the issue you described for posts).

silverpill · December 7, 2023, 6:05pm

In FEP-ef61 actor object may be replicated to multiple servers. In that case each server would host a separate personal inbox, but these inboxes can be synchronized via inbox forwarding.