Add more examples and needs

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."