Separate Instance Actor and Blog Profile for Delete Actor Implementation

[Jiwoon-Kim]

Problem
Currently, the handling of Delete Activities is ambiguous when it comes to Actor removal. It is not always clear whether the Delete should apply only to the Actor profile or also cascade to all related Objects (posts, notes, media, etc.).

Proposal
Introduce a clearer separation between:

• Instance-level Actor (Application): @yourdomain.com@yourdomain.com
• Blog/Profile-level Actor (Organization or Group): @blog@yourdomain.com

This separation ensures that when a Delete Activity targets an Actor:

• We can remove just the Actor profile, while leaving the handling of their historical Objects (Note, Article, Image, etc.) up to the server.
• This avoids the problem of generating a Delete for every individual Note or Object created by that Actor.

Key Considerations

• A Delete for an Actor still needs to be federated to all remote servers where that Actor has followers.
• To ensure delivery efficiency, the shared inbox should always be used for Actor deletions.
• Actor deletion can be treated as a special case in the federation logic, distinct from content deletion.

Benefits

• Cleaner separation of concerns between application-level identity and profile-level identity.
• Reduced network overhead (no per-object Delete).
• Consistency across federation when a user or blog is fully removed.

[obenland]

This will be solved by #2046.

[Jiwoon-Kim]

https://seb.jambor.dev/posts/understanding-activitypub-part-4-threads/#the-instance-actor

[pfefferle]

WordPress already uses an instance (Application) Actor.

Here an example: https://public-api.wordpress.com/wpcom/activitypub-1.0/sites/239423076/application

[Jiwoon-Kim]

I’ve confirmed on Mastodon that a WordPress.com site on the free plan does indeed expose an Application actor. However, I noticed that this doesn’t appear for paid plans or self-hosted WordPress sites, which I found a bit puzzling.

Also, the example of the instance actor you shared looks very similar to the default blog handle format I’ve often seen in WordPress, which made me curious about how exactly it’s being generated.

[pfefferle]

The Application Actor is a default Actor for all WordPress.com and plugin users and can't be disabled. It is not meant to be followed, so it is not exposed anywhere publicly.

Here a self-hosted example: https://notiz.blog/wp-api/activitypub/1.0/application

[Jiwoon-Kim]

[pfefferle]

Sure, it will come up if you search for it! But you can not follow the account.

[Jiwoon-Kim]

What stood out to me was that the default blog handle format, where the domain is repeated in the identifier, doesn’t look very clean. If it were presented instead as an instance-level handle, I wouldn’t really mind it.

Of course, users can change this, but in cases like the free WordPress.com plan where the handle cannot be customized, this becomes more of an issue. For example, I’ve noticed compatibility problems with Misskey, which suggests there’s a concrete area for improvement here.

[Jiwoon-Kim]

Sure, it will come up if you search for it! But you can not follow the account.

Hmm, on Misskey the status shows as pending, so that part looks correct. However, it still appears as if the account can be followed normally from Mastodon.

[pfefferle]

I think there is no way to prevent that, but let me know if you find a solution!

[Jiwoon-Kim]

I was mainly curious whether this is just a UI presentation issue or if it actually behaves that way. Of course, I understand that following has no real effect in this case. Still, I think it’s useful to identify whether the observed behavior is a bug or simply expected.

[pfefferle]

@Jiwoon-Kim thanks for bringing this up again, I found a glitch and implemented a reject: #2101