Follow as a WordPress instance – Some questions

[Menrath]

Background:
Currently the plugin gives the following actors: an application@example.com with imaginary user-ID of -1 and depending on the setting there is a blog-actor (imaginary user-id: 0) and user-actors.

I am currently implementing following as an instance in the course of adding other ActivityPub actors as "Event Sources" in my companion plugin Event Bridge for ActivityPub.

Question 1:
Many solutions could work, it's hard for me to decide which one to use. I really would appreciate sharing your thoughts on this matter, as they are highly dependent on future features/development of the ActivityPub plugin.

• Option1: It's straightforward to just use the application actor for that as it is always available. But the drawbacks are, the application actor is not well decorated, it's name icon and description are not-friendly to other humans. And the application actor cannot easily be followed back. And other nice things like the followers collection will currently not work.
• Option 2: Don't offer such feature when the Blog-Actor to is not enabled.
• Option 3: Adding an explicit WordPress user for that.

Question 2:
As I am saving external events within a post-type that has ActivityPub enabled, I of course have to make sure that these posts do not get federated via the ActivityPub plugin. I decided to use the nice filter activitypub_is_post_disabled. Anyway I wondered if I should also just set the post meta activitypub_content_visibility to ACTIVITYPUB_CONTENT_VISIBILITY_LOCAL too.

[pfefferle]

My first idea would be to use the constants to force enable the blog-user and use that!

I will think about that a bit more and come back to you next week.

[Menrath]

I forgot to go into one detail, consider it as an optional offer for a Pull Request, but I am totally fine, if you don't think it is worth adopting such things in the ActivityPub plugin. I don't even know myself if I would prefer it that way.

Anyway I wondered if I should also just set the post meta activitypub_content_visibility to ACTIVITYPUB_CONTENT_VISIBILITY_LOCAL too.

I was wondering if unifying this behavior could be of interest. For instance by using a post meta field like _activitypub_remote_cached¹ and an additional check in the ActivityPub template filter.

if ( self::is_cached_external_post( $post ) ) {
	\wp_safe_redirect( $post->guid, 301 );
	exit;
}

¹ Of course using the guid as the ActivityPub ID (which I would recommend anyway to everyone implementing such things!) and storing the hosts of the follows (even after they are unfollowed), and comparing those could solve this too, together with maintaining a transient that stores the post_ids of cached remote content. Oh how I love WordPress coding 🔥

[Menrath]

And some input to your initial suggestion:

My first idea would be to use the constants to force enable the blog-user and use that!

I would not activate the blog-actor from a third party plugin. But place a notice that the blog actor has to be enabled first. In a subsequent step it then would be great to be able to "lock" that the blog actor has to be active: allowing another plugin to filter the validation function of the activitypub_actor_mode setting to prevent the blog actor from being disabled at the same time as triggering an admin notice.

@Laurin-W suggested an additional option: What about always actually enabling the blog-actor, but just change it's behaviour, i.e. enable announcing of posts from the users?