Move: support domain changes

[mattwiebe]

When the home domain is changed, we should detect it and take action to call Move::internally, which will need enhancing to support this case (or possibly another specific function like Move::domain for this case.)

I worked with Windsurf to spec out what would be needed.

---

1. Domain Change Detection System

   1.1. Create a Domain Change Monitor

   • Create a new class Domain_Change_Monitor to track domain changes
   • Store the current domain in the WordPress options table
   • Add a hook to update_option_home to detect when the site URL changes
   • Compare the old and new domains to determine if a domain change occurred

   1.2. Domain Change Event Handling

   • When a domain change is detected, trigger a domain migration process
   • Log the change with timestamp and details for future reference
   • Store both old and new domains in a persistent option for reference

2. Extend the internally Function

   2.1. Add Domain Change Detection Parameter

   • Modify the internally function to accept an optional $domain_change parameter
   • Update function signature: public static function internally( $from, $to, $domain_change = false )
   • Add documentation explaining the new parameter's purpose

   2.2. Domain-Specific Logic

   • Add conditional logic to handle domain change scenarios differently
   • For domain changes, generate URLs with both old and new domains
   • Update the Activity object to include domain change information

3. Actor Profile Management

   3.1. Update Actor Identifiers

   • Modify the Blog profile to handle both old and new domains
   • Update user profiles to maintain both @user@olddomain.com and @user@newdomain.com identifiers
   • Store the mapping between old and new identifiers

   3.2. Extend alsoKnownAs Property

   • Ensure all old domain URLs are added to the alsoKnownAs property
   • Create a helper method to generate domain-specific actor URLs
   • Update both user and blog alsoKnownAs properties

4. Request Routing and Profile Serving

   4.1. Modify get_by_username Method

   • Extend to check for usernames with both old and new domains
   • Add domain-aware username parsing to extract the base username
   • Implement domain detection to determine which profile version to serve

   4.2. Update get_by_various Method

   • Enhance to handle resources from both old and new domains
   • Add domain detection logic to map between domain variants
   • Maintain backward compatibility with existing implementations

   4.3. Enhance template_redirect Hook

   • Modify to detect requests coming to the old domain
   • Add conditional logic to serve appropriate actor profiles
   • Implement proper handling of both domain variants

   4.4. Update redirect_canonical Hook

   • Prevent unnecessary redirects for ActivityPub requests to old domains
   • Add domain-specific handling for actor profile requests
   • Maintain the canonical URL structure while supporting legacy URLs

5. Migration Process Implementation

   5.1. Create a Domain Migration Function

   • Implement a function to handle the entire domain migration process
   • Process all user accounts and the blog account
   • Generate appropriate Move activities for all affected actors

   5.2. User Interface for Domain Migration

   • Add admin interface elements to manage domain migrations
   • Provide status information about ongoing migrations
   • Allow manual triggering of the migration process

6. Testing and Validation

   6.1. Test Cases

   • Develop test cases for domain migration scenarios
   • Test with various combinations of user profiles and blog profiles
   • Validate both incoming and outgoing federation

   6.2. Compatibility Testing

   • Test with various ActivityPub implementations (Mastodon, Pleroma, etc.)
   • Verify that followers are maintained across domain changes
   • Ensure proper handling of mentions and interactions

7. Implementation Approach

   I recommend a phased implementation approach:

   • Phase 1: Implement domain change detection and basic internally function updates
   • Phase 2: Extend actor profile management and request routing
   • Phase 3: Complete the migration process and admin interface
   • Phase 4: Comprehensive testing and refinement

[mattwiebe]

We might not need any admin UI to start, just take action automatically when home option changes.

We might gate this functionality behind a constant initially while we put it through its paces on dotcom.

[obenland]

Hm, this doesn't feel overly useful in the details?

We shouldn't need a separate class, adding an init() function in Move that adds the update_option callback should be sufficient.
The internally function should not need to be extended for domain changes.
Are any of the things in "Request Routing and Profile Serving" needed?
User Interface for Domain Migration should also not be needed.

[pfefferle]

The question is: Do we need to have a context for movedTo? So that we only show it on the old domain, but not on the new one, to prevent inceptions like this:

[mattwiebe]

this doesn't feel overly useful in the details?

Yeah I just wanted to get the conversation started, I already noted we won't need admin UI.

The internally function should not need to be extended for domain changes

This is maybe true. I am assuming that we need some specifc domain-switch metadata to be stored to ensure that the moving parts of the transition, when both profile URLs need to be served in the right way from their respective domains. But that logic can also live in the home option listener.

To get a bit more specific: any of our old-style profile URLs, especially the default ones for the Blog Actor, will need special handling.

Eg on my https://altwiebe.wordpress.com/@altwiebe.wordpress.com handle, if I upgrade to altwiebe.blog, My new profile URL will be one of https://altwiebe.blog/@altwiebe.blog or https://altwiebe.blog/?author=0. In either case I need to explicitly remember how to serve the former https://altwiebe.wordpress.com/@altwiebe.wordpress.com handle, which is no longer a dynamic match for the new home option's domain.

Are any of the things in "Request Routing and Profile Serving" needed?

I am assuming so at this point, to ensure that we can properly serve the old Blog Actor when requested by Mastodon etc to verify that the Move is valid. We might be able to avoid it if we just make sure that Actors::get_by_* methods work properly with the old domain requests.

[mattwiebe]

The question is: Do we need to have a context for movedTo? So that we only show it on the old domain, but not on the new one, to prevent inceptions

I don't understand what I'm seeing there? I would like to understand :)

[pfefferle]

I made a Move to change my ID from https://pfefferle.org/@pfefferle.org to https://pfefferle.org/?author=0 but because both (movedTo and alsoKnownAs) infos are in the same Actor JSON, Mastodon displays it like I moved from one Account to the same... Compare the WebFinger Identifiers... It says I moved from pfefferle.org@pfefferle.org to pfefferle.org@pfefferle.org 🙄

[obenland]

In either case I need to explicitly remember how to serve the former https://altwiebe.wordpress.com/@altwiebe.wordpress.com handle, which is no longer a dynamic match for the new home option's domain.

Is that possible? On Dotcom I'd expect it to be forwarded to the new primary domain.

In case it's not obvious, I'm not terribly familiar with how Moves work in detail (yet)—do we even need to be able to serve the old profile? Or is it enough to reference it in also_known_as of the new URL, while sending out the Move activity to followers that points to that?

[pfefferle]

The main question is, if the fields in the Actor will be checked or if Mastodon fully relies on the Move Activity we send.

[pfefferle]

It could be that the movedTo might only be used for the UI!

[obenland]

It's not mentioned in tons of places…

[mattwiebe]

Is that possible? On Dotcom I'd expect it to be forwarded to the new primary domain.

This may require a little sunrise.php hacking to short circuit domain redirects on certain ActivityPub requests related to profiles and webfinger.

do we even need to be able to serve the old profile? Or is it enough to reference it in also_known_as of the new URL, while sending out the Move activity to followers that points to that?

That is my memory of the flow. It may turn out to be incorrect. The old profile has to be served from the old domain in order for the Move request to be verified against the publicKey. It's possible that the remote server receiving a Move request would rely on a cached representation of the Actor, but it's possible that they won't even have a copy and will need to fetch it. (If I was writing the server software, I would re-fetch it anyway when processing something of this importance.)

I think that some of @pfefferle's problems above is because there's no difference in what's served by https://pfefferle.org/@pfefferle.org vs https://pfefferle.org/?author=1. They should not have the same signature with id fields etc. The same will go for domain switch. The originating ID needs to preserve its state, I think. Again, I could be wrong here, but this is the assumption I am operating under.

My next steps are to spin up a temp Mastodon instance to test a bunch of this against.

[mattwiebe]

tl;dr skip to Conclusion below for next steps, which are much clearer even at this early juncture without "real" testing.

Spent too much time today setting up Mastodon test instances but I want to know exactly what happens. masto.host is not giving me the logs I want by default, but I found Cloudron which was a pretty good experience (once I upgraded the specs on the instance which was griiiinding).

While some things were installing, I played around with Move::internally, commenting out any actions, I just wanted to see what it generates on my @wp.test@wp.test Blog Actor on my local test instance. I ran this (while exiting early and dumping the Activity here and preventing adding to the outbox. I did:

$from = 'http://wp.test/@wp.test';
$to   = 'http://wp.test/?author=0';
\Activitypub\Move::internally( $from, $to );

To simulate moving off of the pretty ID and to the generic ID based one we are now preferring. The output of print_r( $activity->to_array() ) was:

Array
(
    [@context] => Array
        (
            [0] => https://www.w3.org/ns/activitystreams
        )

    [id] => http://wp.test/?author=0#activity-move-1743101724
    [type] => Move
    [object] => http://wp.test/?author=0
    [actor] => http://wp.test/@wp.test
    [target] => http://wp.test/?author=0
    [origin] => http://wp.test/@wp.test
)

Which already seems wrong due to the id. The originating Actor here is $from, that should be reflected in the ID. And then I found that this id is generated here in set_object, which leads me to ask if maybe we are setting the wrong object here? According to the Draft Data Portability spec, section 4.1:

1. The user creates a new actor at username@new.example
2. The user marks the new actor as accepting a move with the alsoKnownAs property.
3. The user marks the old actor as having moved with the movedTo property.
4. The user sends a Move activity from the old actor to all followers.

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "type": "Move",
  "actor": "https://old.example/users/username",
  "object": "https://old.example/users/username",
  "target": "https://new.example/users/username"
}

5. Each follower checks the alsoKnownAs property of the new account and movedTo property of the old account.
6. Each follower sends a Follow activity to the new account.
7. Each follower sends an Undo Follow activity to the old account.
8. The old account's profile URI redirects to the new account's profile URI.

---

So no. 4 shows the old URI in the object, case confirmed, we have a bug in Move::internally. It should be $activity->set_object( $to ); here. I'll file a PR for that. Maybe it's responsible for some of the weirdness above @pfefferle ?

One other thought is that for any type of internal Move, we kind of probably should delete all of that Actor's followers, since they won't necessarily transfer over to the new, Moved Actor? And sure enough, section 4.2 - Results has this spelled out:

1. The old account's profile URI redirects to the new account.
2. The new account's followers is a subset of the old account's followers.
3. The new account's following is a subset of the old account's following.
4. The old account's followers list is empty.
5. Each follower's following list includes the ID of the new account.

---

So although the accounts are the same, they need to be treated differently depending on which one is being requested. This is going to be tricky. This also is kind of begging for my fully virtualized "Real Actors" proposal. We'd simply have two different Actors for $from and $to in all cases. I think I can make this work without that but it would have simplified a lot (while of course making everything more complicated in many areas).

---

Conclusion: we are going to need to serve both the $from and $to profiles independently of each other throughout the Move process. This means:

1. We'll need to be able to query on the $from value and serve the Actor data with that as the source of truth. So the various Actors::from_* methods will need to support this and vary their data based on which variant is requested. (This may really only be an issue for the Blog Actor).

• I assume that we'll need to serve this both through Webfinger and the profile URL ID itself.

2. We need to wipe out all Followers for the $from Actor, to allow those who send a Follow to the $to Actor to be properly handled.

• We will also need to properly handle the Undo Follow Activity on the $from Actor. We may need to store those Followers in some other fashion after wiping them all out to prepare for those that re-Follow the new ID
• The potential Follower loss after a Move makes me hesitate to do it to Move all accounts to the newer query param style.

3. We have a bug in Move::internally that I'll submit a PR for.