Multiple Accounts - one Identity

[pkreissel]

Activity Pub should have a solution for this problem:

I have a wordpress blog, I have a bluesky account federated via bridgyfed, I have a mastodon account and a pixelfed account.

Now I would like to "merge" the Wordpress blog and the Mastodon Account, so that my articles get shown to my Mastodon followers AND the comments to the articles show up on my Wordpress blog. I could of course reblog the Wordpress Articles with the Mastodon Account, but then people would follow my Wordpress Blog instead of my main account, if they see the post in their feeds.

I don't know what the best solution for this would be, but I think it's an impediment to ActivityPub adoption. One option would be a pointer from my Wordpress account to my Mastodon Account (and vice versa for authentication), so that Fediverse instances could respect my wishes and redirect follow requests to my main account or e.g. auto reblog posts from my Wordpress Instance.

[silverpill]

There are two approaches (not mutually exclusive):

• Identity is controlled by the server, which works as identity provider for "single sign-on". This solution is described in FEP-61cf
• Identity is controlled by the user, who can plug it into different clients. This solution is described in FEP-ae97

[snarfed]

Thanks @silverpill!

There are two other relevant ideas also worth mentioning here. First, account migration via the Move activity is a merge under the covers. A weak, incomplete one, but nonetheless. You create the new account, point the old and new accounts at each other, then send a Move to trigger merging the old account's followers into the new one. The old one then "redirects" to the new one. This is only semi-standardized at best, and it's nowhere near a substitute for either nomadic identity or OAuth-style single sign-on, but it's something.

Second, we've started to talk about how to de-dupe accounts across bridges, which is a different angle on what you're talking about. Those conversations are very early, and not very active, but we've at least started thinking about it.

[pkreissel]

I think the MOVE activity would already tick a lot of the boxes with regard to followers. However right now it kind of assumes the old identity to shut down, but does not really specify that.

I do not want total nomadic identity with secret key, because I believe for 95% of users that would end in identity loss at some point.

Instead it would be better to have a "main" Identity and then subidentities on other servers.

To use bridgy fed as an example: My bridged bluesky account together with the MOVE specification would forward anyone who tries to follow it, to my main account. Now when I reblog posts from my federated identity (still need to do that manually, bummer), anyone who sees them in their feed and tries to follow me, now gets to my actual profile. So this would solve my request, if posts still work from a profile with MOVE

I added a feature request on the Wordpress Plugin. I can add one at bridgy fed as well, but I think it's still further away, because the mutual authentication of the bridged account and the home account would first need to be solved, as you said in your issue.

[pfefferle]

I am not sure if you are talking about the same thing! If you Move your WordPress users to Mastodon, they will no longer receive Blog-Updates and comments to your Mastodon Account will not federated back to your blog! Move means that all the followers of one account on a platform will be moved to another account an the same or different platform. The other account is abandoned then!

[pkreissel]

That is not entirely correct. Here is a post of an old account of mine, that was "moved" to my new account here.

I can still boost the post, comment it and so on. You can test this by searching for the status uri on your instance. So the account is just "abandoned" if chaos.social would decide to delete my old posts, but it is not specified in activity pub. Only all the followers are redirected to my new account. All the other post functionality still works.

The decision that I can no longer post from my chaos.social account is in my view only a decision by mastodon, but not forced by activity pub.

To summarize: I think the MOVE functionality already does what I want, it is just too specifically phrased.

[pfefferle]

Maybe we have a different understanding of "Abandoned", but it does not help with your issue!

Move only moves your followers one time. So either you have to run the Move once a week or you have to disable following completely (there is no nice way to tell users that they can't follow an account, so this might result in an UX issue). If a blog has no followers it will not automatically federate posts any more, so you need a different way to boost content from your blog, because only comments to boosted posts will be federated.

So Move does only solve your problem of bringing all your followers to one account at one given point in time, but it does not solve the other distribution issues.

[pkreissel]

The move for my old account now lead to a permanent redirect to my new account. That is what I want.

[pfefferle]

OK, but just to get sure: You are aware that the comment federation will no longer work then?!?

[pkreissel]

Why should it no longer work? The comment from my old account are still there and you can still comment there.

[pfefferle]

As I mentioned above, if a blog has no followers, it will not publish anything to the fediverse.

[pfefferle]

But this may be a different discussion. FYI: we are currently working on a Move functionality https://github.com/Automattic/wordpress-activitypub/pull/685

[silverpill]

@pkreissel Follower migration (in Mastodon network) relies on alsoKnownAs property, which is a link between two accounts (this mechanism is described in FEP-7628). Old account can remain active after migration and linked accounts can even be merged into one in UI as you suggested, but this is not sufficient to make clones. This problem is solved by nomadic identity.

I do not want total nomadic identity with secret key, because I believe for 95% of users that would end in identity loss at some point.

Nomadic identity doesn't necessarily mean that users have to manage secret keys. Key custody is supported too.

[evanp]

There are two built-in solutions to this problem. I think they are. I think they are an important part of how we use activity pub in 2024 and where we should be going with activity pub into the near future return.

1. First one is using the activity pub API from remote clients instead of having lots of different servers. The activity pub model expect the clients will post different kinds of activities into the same actor account. So posting longform tax like a blog post or images or video would be done with specialized activity, pub, API clients, and distributed by a general purpose activity pub, Federation protocol server. Unfortunately, this model isn't well supported on the Fed adverse today. Instead, we've copied the model from commercial social networks, where you have a full social graph attached to each type of content that you want to create, for example, posting images on Instagram, posting video on YouTube, etc., having one account per type of content is what causes this multiplicity of accounts. Hopefully getting more support for the activity pub API built into activity pub servers will help reduce this problem.
2. The second option is as you mentioned re-sharing content from one account to the other. So, for example, re-sharing all your WordPress blog posts through your mastodon account. This works pretty well however, there are not a lot of tools out there for automatically reposting Activities from one activity pub account to the other, I think this is a an opportunity for a service that hasn't been built yet. Activity servers could also build this functionality directly into the service.
3. Another possibility is using Webfinger to unite multiple activity pub actors under a single address, managing how these actors interact how clients might choose which ones to follow is a little outside the activity, pub specifications specifically, but may be a good area for research in our web finger program profile, recently published.

I'm going to write up this guidance in a primer page to help implementers take steps towards reducing this problem. I agree that managing multiple accounts on the Fed verse is an impediment to adoption all right.