What is involved in moving your account from one server to another seems much, much more difficult than it should be.

What is involved in moving your account from one server to another seems much, much more difficult than it should be.

#FediUX #FediverseUX

reiver@mastodon.social wait was there more or was this just a slightly warm take

@julian

I will write something up more later.

Perhaps with UI-mockups of what I feel could be better account move experience.

...

(I just moved 3 old accounts to somewhere else. So I just experienced the flow three times.)

@julian

Right now you have to log into both the new account, and the old account.

In new account you add an alias to the old account. (It is a bit of a hunt to find this in the UI if you don't know where it is.)

In the old account you put in the new account to migrate to. (It is also a bit of a hunt to find this in the UI if you don't know where it is.)

And, you also download a bunch of stuff from the old account.

.

@julian

I think a better user-experience could maybe involve logging into the old server with the new server.

And there being a "hand held" experience.

What if you didn't need to move your account from server to server? What if you had your account on a "personal" server and all the fediverse applications talked to that?

More on this in my up-coming talk (I talked about this at FediForum), I just need to record the video for the talk.

thisismissem I feel like this can be extended to utilising accounts on separate services (e.g. posting to a NodeBB from a Mastodon account)... Having a separate PDS-like store for account data is a nice to have but the underlying tech should apply...

cc reiver@mastodon.social

julian right, if we decouple your account & identity from the software you use, perhaps that'll unlock new interesting things — no longer would building an AP app be that you have to build the complexity of S2S and handle storing everything. Like NodeBB could not include an AP S2S implementation and just use C2S APIs

Seems to me there are three related things here, all useful:

1) being able to use the same account for different fedi instances, running different software

2) the ability to have a personal server for your data

3) easily moving your account and data between different providers

On AT Proto, for example, event though #1 and #2 were part of the protocol all along, having easy-to-use migration tools like PDS Moover and tektite.cc makes it much more accessible than GOAT, which is very hard for anybody who's not a developer.

So even if we had #1 and #2 on ActivityPub, there would still need to be effort in making moving easier. Conversely there's no need to wait for #1 and #2, it would be great to continue the momentum for making migration earlier. Vyr's work with Slurp, Bonfire's recent release, and jonny's new proposed FEP all point in that direction, but there's still a lot more to do ...

@thisismissem @julian

jdp23@neuromatch.social it's #3 that's possible on AT Protocol, but all but impossible on ActivityPub for now. (There is a FEP for portable objects, but I'm not 100% sold on it yet)

Oh totally agree! And @reiver's original point that the UX is challenging here even for the limited migration that is possible is an important one as well. I just meant that the (very worthwhile) architectural improvements you're talking about aren't by themselves a full solution to this issue.

@thisismissem