Merge branch 'remove-actor-mapping-proposal'

architecture design proposal.md

@@ -111,7 +111,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).
+Currently, only one hard-coded transformer exists in `includes/transformer/class post.php` ([Source](https://github.com/Automattic/wordpress-activitypub/blob/master/includes/transformer/class-post.php)).
 
 ```php
 /**
@@ -208,6 +208,7 @@ We keep in mind that every post type shall only ever send as a `Create` Activity
 
 **User Interface:**
 
+
 |                  | users | tribe_organizers | custom |  blog | category |
 | -----------------|:-----:|:----------------:|:------:|:-----:|:--------:|
 | **post**         | C     | O                | O      | A     | A        |
@@ -251,21 +252,7 @@ Anyway it seems the question has to be raised wheter activitypub should store a
 ## 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 {
-    public function getActorTypeName(); // returns name of the ActorType
-    public function listActorsOfThisType(); // returns array of actors of this type
-    public function listPostsForThisActor($actor); // returns array of posts
-}
-```
-
-The registration of an actor type also registers every actor that is currently in the `listActorsOfThisType()`-list.
-
+  
 
 # Appendix