Event-Federation/documentation
7
1
Fork 0
Code Issues 2 Pull requests Projects Releases Wiki Activity

Move paragraph about user being the default actors to another place

Browse source
This commit is contained in:
André Menrath 2023-10-10 12:58:37 +02:00
parent 597111d650
commit 26a2ef658e
1 changed files with 2 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

3
architecture design proposal.md
View file

@ -165,6 +165,7 @@ Note that depending on which options are enabled, the method of federating via A
`author`-actors. `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). 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 ## Possibilities
ActivityPub knows several [actor types](https://www.w3.org/TR/activitystreams-core/#actors): 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>`. 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 ### Existing collisions
- **Easy:** Either we just tell the user to resolve all conflicts before a WordPress actor type can be activated at all - **Easy:** Either we just tell the user to resolve all conflicts before a WordPress actor type can be activated at all