Proposal (draft): management of activity pub actors

[ruru4143]

This document outlines suggestions for the further development of the WordPress ActivityPub plugin regarding its interoperability with other WordPress plugins that could enhance ActivityPub functionality.

This work has been done within the course of a project aiming at better event-federation within WordPress: repository, website. The goal of our proposals can be found in the first part (#541) regarding wp_post to activitypub object transformation.

The main part of this proposal: Scroll down to Mapping: Actors and Dispatching.

Terms used

The following terms are used:

• post type: post types and custom post types within WordPress
• actors: ActivityPub Actor Objects
• actor types: ActivityPub Actor Types
• WordPress actor types: Things on WordPress that can be mapped to actors, e.g.:
  • WordPress users →Person
  • Whole Blog →Application or Group
  • Post types → e.g., Organization
• Actor mapper: Describes the mapping of WordPress actor types to any ActivityPub actors.
• publish/dispatch: Sending a Create, Update or Announce Activity.

Principals of the changes proposed to the ActivityPub plugin

The WordPress ActivityPub plugin

• should not get any more complex by default, the out-of-the box functionality/features and simplicity should be similar to version 1.0.0.
• offers other plugins the possibility to register new WordPress actor types, e.g. the tribe_organizer post type of The Event Calendar.
• handles the controls collisions of actor names:
  • collisions that are already present during activation of a WordPress actor type on the settings page
  • collisions that happen afterwards (e.g., a new user registering with the same username as the blog-wide actor)
  • (maybe) show notifications/warnings when using an actor name which has been used and followed by in the past, as there may be issues due to caching of the old public key.
• maybe distinguishes between the default user interface and advanced sections which give the user more fine-grained control

Mapping: Actors and Dispatching (early draft)

More comprehensive actor management would benefit our project aims and potentially meet the needs of others in the future. Nevertheless, its importance is considerably lower than that of Transformer management. In the future, the following factors may become more important when larger websites should be using the ActivityPub plugin.

Current situation

Currently, the admin user interface in v1.0.0 gives very limited options.

- [ ] Enable `blog`-actor
- [ ] Enable `author`-actors

Note that depending on which options are enabled, the method of federating via ActivityPub varies significantly:

• If the blog-actor is enabled, but the author-actors are not, posts are attributed and created by the blog actor.
• If both options are enabled the blog-actor will announce (boost) the posts of the author-actors.

Currently, the whole logic controlling this is written within the Activity_Dispatcher class which is currently triggered only within the Scheduler class.
Furthermore, although a blog actor is available, the ActivityPub plugin is still written in such a way that WordPress users are the default ActivityPub actors. This also reflects in things like the class which is responsible for the actor lookup is still called Users and yet handles the Blog and the Application user too, see the Source.

Possibilities

ActivityPub knows several actor types:

• Application
• Group
• Organization
• Person
• Service

The ActivityPub specification allows for immense flexibility in its application. As WordPress websites fulfill a variety of tasks and objectives, it is challenging to implement control features and options for actor management that are more capable without sacrificing user-friendliness.

What features does our Event Federation project need?

• For maximum Mobilizon compatibility we would love to have simply an actor of type Application, preferable called @[email protected], that announces all events. Nonetheless, in theory, a Mobilizon instance should have the capability to follow any other actor as well. More or less this can already be achieved with the current blog-actor.
• Additionally, for example, organizers in The Event Calendar could also offer their own actor of type Organizer or Group to publicize events (getting referred to via attributedTo) if the author-actors are enabled, or create events (being the actor directly) if the author-actors are not enabled.
• Optional: As events are sometimes published a long time before they start, adding the possibility that events get announced again at a scheduled time before the start, e.g. by sending an Announce activity.

Other features

Other WordPress actor types might have valid use cases, like actors for categories, or specific post types in general: "I only want to see the blog updates, but I do not want to spam my timeline with each product they post on their website, even if they choose to federate them."

Problems:

• Overall complexity may lead to programming and usage errors.
• Naming collisions become more likely. See below.
• Who is the actor, who is the attributedTo, who is just sending an Announce of a post?

Proposed starting point for evaluating use cases

We keep in mind that every post shall only ever be sent as a Create Activity once, by one single actor.
Therefore when the ActivityPub plugin makes use of a certain WordPress actor type, the WordPress actor type must exactly return one actor, which may depend on the current post being published and on the user doing the action (latter information should also be available within the WP_Post object).

User Interface:

	User	Event organizers	Product Relay	Relay(Blog)	Categories
post	C	-	-	A	A
page	C	-	-	A	O
tribe_events	O	C	-	A	0
product	O	-	C	0	0

x: Actor mapper
y: WordPress post types
C: Create — can only be assigned once per row
A: Announce — can be assigned multiple times per row, but only if a Create has been assigned before

• Only allow setting something to Announce, when a Create is already set.
• Maybe forbid, that a user can automatically announce a post, because it's the "lowest level".

Actor collisions

Each ActivityPub actor must have a unique ID. In our case this is an HTTPS URI.
But in reality webfinger is used: @[email protected]. Actors like Persons and Groups and Applications have public keys attached to them, as well as their ID is probably cached by most software. So assigning some actor-name to something new also can cause unintended behavior.

If multiple plugins want to individually federate their content (like events, products, and blog posts or even the built-in WordPress categories), they must be able to have something like an actor API, the ActivityPub plugin can register. The ActivityPub plugin being the main coordinator is necessary because actors are globally unique.

• For existing (collision was created before the installation/activation of the plugin)
• For new collisions (collision was/will be created after the installation/activation of the plugin)

It seems like it is the best if collisions are avoided in the first place by encouraging the use of prefixes, like category_<category>.

Existing collisions

• Easy: Either we just tell the user to resolve all conflicts before a WordPress actor type can be activated at all
• Complex: We let him choose alternatives for conflicts.

New collisions

• Easy Forbid the saving of new users or posts that would conflict with an existing actor.
• Complex …

Conclusion

• Anyway it seems the question has to be raised whether the ActivityPub plugin should store a history of all past and currently mapped actors.
• Additionally, shouldn't the user have a detailed overview in each case if the actor management should get more complex?