more details on actor/dispatch relation

architecture design proposal.md

@@ -170,16 +170,16 @@ 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).
+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) which is currently triggered only within the `Scheduler` [class](https://github.com/Automattic/wordpress-activitypub/blob/master/includes/class-scheduler.php#L14-L15).
 
 
 ## Possibilities
 ActivityPub knows several [actor types](https://www.w3.org/TR/activitystreams-core/#actors):
-- Application
-- Group
-- Organization
-- Person
-- Service
+- `Application`
+- `Group`
+- `Organization`
+- `Person`
+- `Service`
 
 The specifications allow for a lot of flexibility in their use. As WordPress websites serve a variety of tasks and goals, providing more detailed capabilities and options in this area **may prove challenging to accomplish in a user-friendly manner**.
 
@@ -198,7 +198,7 @@ Other WordPress actor types might have valid use cases, like actors for categori
 ### Problems
 
 - Overall complexity may lead to programming and usage errors.
-- Naming collisions become more likely.
+- 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