describe Users class more

+ some style improvements

architecture design proposal.md

@@ -18,9 +18,10 @@ The following terms are used:
 - **Actors:** ActivityPub [Actor Objects](https://www.w3.org/TR/activitypub/#actor-objects)
 - **Actor Types:** ActivityPub [Actor Types](https://www.w3.org/TR/activitystreams-vocabulary/#actor-types)
 - **WordPress actor types:** Things on WordPress that can be mapped to actors:
-    - WordPress users
-    - Whole site/blog (relay)
-    - (custom) post types
+    - WordPress users →`Person`
+    - Whole Blog →`Application` or `Group`
+    - post types → e.g. `Organization`
+    - custom definitions → custom actor types
 - **Mapping:** Which WordPress actor types are actually are mapped to any ActivityPub actors at all and to which one.
 
 ## Content related
@@ -111,6 +112,7 @@ available for a given post type are greyed out in the user interface:
 ## Backend
 
 Currently, only one hard-coded transformer exists in [`includes/transformer/class post.php`](https://github.com/Automattic/wordpress-activitypub/blob/master/includes/transformer/class post.php).
+
 ```php
 /**
  * WordPress Post Transformer
@@ -238,7 +240,7 @@ If multiple plugins want to individually federate their content (like events, pr
 
 It seems like it is the best if collisions are avoided in the first place by encouraging the use of prefixes, like `category_<category>`.
 
-Anyway it seems the question has to be raised wheter activitypub should store a history of all past and currently mapped actors.
+Anyway it seems the question has to be raised wheter activitypub should store a history of all past and currently mapped actors. Currently the ActivityPub plugin is still written with WordPress users being the default ActivityPub actors in mind. 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](https://github.com/Automattic/wordpress-activitypub/blob/master/includes/collection/class-users.php).
 
 ### Existing collisions
 - **Easy:** Either we just tell the user to resolve all conflicts before a WordPress actor type can be activated at all
@@ -249,13 +251,12 @@ Anyway it seems the question has to be raised wheter activitypub should store a
 - **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? 
 
 
 ### Proposal of how plugins register WordPress-actor types
+TODO: This gives no information of how posts get dispatched to which actor.
 
 ```php
 interface ActorType {