diff --git a/architecture design proposal.md b/architecture design proposal.md index 72d2d1a..b69466a 100755 --- a/architecture design proposal.md +++ b/architecture design proposal.md @@ -27,15 +27,16 @@ The following terms are used: - **post type:** Post type and custom post types within WordPress - **Object Type:** ActivityPub [Object-Type](https://www.w3.org/TR/activitystreams-vocabulary/#object-types) -- **Transformers:** a piece of code that transfers a WordPress post of a specific WordPress post type to an ActivityPub object of a specific WordPress-object-type. For example a transformer that can transform: +- **Transformers:** a piece of code that converts items of a particular WordPress post type to an ActivityPub object of (a) specified type(s). For example a transformer that can transform: - `post` to a `Note` - `post` to a `Article` - `post` to `Note`, `Article`, `Image`, `Audio` or `Article` depending on the [post-format](https://wordpress.org/documentation/article/post-formats/) - `tribe_events` (Event post the of [The Event Calendar](https://wordpress.org/plugins/the-events-calendar/)) to `Event` + - `podcast` (Podcast post of [Podlove Podcast Publisher](https://github.com/podlove/podlove-publisher)) to `PodcastEpisode` as ([proposed and implemented by Castopod](https://code.castopod.org/adaures/castopod/-/blob/main/app/Libraries/PodcastEpisode.php)) ## General -- **publish:** Sending a `Create`, `Update` or `Announce` [Activity](https://www.w3.org/TR/activitypub/#create-activity-outbox). +- **publish/dispatch:** Sending a `Create`, `Update` or `Announce` [Activity](https://www.w3.org/TR/activitypub/#create-activity-outbox). # Principals of the changes proposed to the ActivityPub plugin @@ -47,6 +48,7 @@ The WordPress ActivityPub plugin - 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 admin user interface and advanced sections which give the user more fine-grained control: * transformer management * actor management @@ -58,8 +60,8 @@ Our primary goal is to make it possible that events created within an event plug Nevertheless, we see a lot of other cases that can benefit, if we achieve this using a modularized approach as proposed below. The following list indicates examples what might be those other benefits: - Other types of content get federated in a more feature rich way: - - `PodcastEpisode` (as proposed by CastoPod) - - `Question` (as used by Mastodon) + - `PodcastEpisode` [as proposed by CastoPod](https://code.castopod.org/adaures/castopod/-/blob/main/app/Libraries/PodcastEpisode.php) + - `Question` - `Product` - ... - ActivityPub offers features how to deal with multilingual content ([contentMap - see Example 115](https://www.w3.org/TR/activitystreams-vocabulary/#dfn-contentmap)) which could be implemented differently by multilingual and translation plugins (example search for the current use of `->set_content_map` within the ActivityPub plugin). @@ -101,7 +103,7 @@ x: ActivityPub object-types, y: WordPress post types - Should a transformer be always a many-to-one relationship or may it be a many-to-many one. -- Do we really want to manage which transformers apply to what directly or do users prefer a setting like "let a certain plugin take care of this post type"? Then further configuration would have to be managed by the other plugins. +- Highly unlikely: Do we really want to manage which transformers apply to what directly or do users prefer a setting like "let a certain plugin take care of this post type"? Then further configuration would have to be managed by the other plugins. ## Backend @@ -152,10 +154,11 @@ Possible alternatives and solutions: - Don't use an interface with implementations, (miss)use class extensions. -# Actor Mapping Management +# Mapping: Actors and Dispatching 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 @@ -167,6 +170,9 @@ Note that depending on which options are enabled, the method of federating via A - If both are enabled the `blog`-actor will announce (boosting) the posts of the `author`-actors. +Currently the whole logic controlling this is written within the `Activity_Dispatcher` [class](https://github.com/Automattic/wordpress-activitypub/blob/master/includes/class-activity-dispatcher.php#L21). + + ## Possibilities ActivityPub knows several [actor types](https://www.w3.org/TR/activitystreams-core/#actors): - Application @@ -183,6 +189,8 @@ The specifications allow for a lot of flexibility in their use. As WordPress web - Additionally, for example, organizers in [The Event Calendar](https://wordpress.org/plugins/the-events-calendar/) could also offer their own actor of type `Organizer` or `Group` to publicize events, or create events if the `author`-actors are not enabled. +- Optional: As events are sometimes published a long time before they start, adding the posibility 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 site, even if they choose to federate them."