diff --git a/architecture design proposal.md b/architecture design proposal.md
index b85d5df..ac876ff 100755
--- a/architecture design proposal.md	
+++ b/architecture design proposal.md	
@@ -165,6 +165,7 @@ Note that depending on which options are enabled, the method of federating via A
 `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) which is currently triggered only within the `Scheduler` [class](https://github.com/Automattic/wordpress-activitypub/blob/master/includes/class-scheduler.php#L14-L15).
+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](https://github.com/Automattic/wordpress-activitypub/blob/master/includes/collection/class-users.php).
 
 ## Possibilities
 ActivityPub knows several [actor types](https://www.w3.org/TR/activitystreams-core/#actors):
@@ -223,7 +224,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. 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).
+Anyway it seems the question has to be raised wheter activitypub should store a history of all past and currently mapped actors.
 
 ### Existing collisions
 - **Easy:** Either we just tell the user to resolve all conflicts before a WordPress actor type can be activated at all