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

add one more proposal for the transformer table: show origin

Browse source
This commit is contained in:
André Menrath 2023-10-05 14:11:29 +02:00
parent 1b890d6c56
commit 933efdb1ca
1 changed files with 4 additions and 2 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

6
architecture design proposal.md
View file

@ -95,7 +95,8 @@ available for a given post type are greyed out in the user interface:
**y:** WordPress post types **y:** WordPress post types
- For any custom post type, if there is a custom transformer registered, indicate that one should be selected as default (or select it right ahead?). - For any custom post type, if there is a custom transformer registered, indicate that one should be selected as default (or select it right ahead?).
- Should not differ too much from the current view: Maybe completely hide the current Activity Object Type part of the settings and only show the buttons for `enable` and `disable` and move the transformer table to an advanced settings page. - Should not differ too much from the current view: Maybe completely hide the current activity object type part of the settings and only show the buttons for `enable` and `disable` and move the transformer table to an advanced settings page.
- Maybe make the tables more advanced and cleary show the origin of the transformer (built-in, etc.) and maybe a Pop-Up with a description.
### Problems ### Problems
@ -174,7 +175,6 @@ Note that depending on which options are enabled, the method of federating via A
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).
## 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):
- `Application` - `Application`
@ -228,6 +228,7 @@ We keep in mind that every post type shall only ever send as a `Create` Activity
- Maybe forbid, that a user can automatically announce a post, because it's the "lowest level". - Maybe forbid, that a user can automatically announce a post, because it's the "lowest level".
## Actor collisions ## Actor collisions
Each ActivityPub actor must have a [unique ID](https://www.w3.org/TR/activitypub/#obj-id). In our case this is a HTTPS URI. Each ActivityPub actor must have a [unique ID](https://www.w3.org/TR/activitypub/#obj-id). In our case this is a HTTPS URI.
But in reality [webfinger](https://webfinger.net/) is used: `@actor-name@instance.tld`. Actors like Persons and Groups and Applications have Public Keys attached to them, as well as their ID is probably cached by most software. So assigning some actor-name to something new also can cause unintended behavior. But in reality [webfinger](https://webfinger.net/) is used: `@actor-name@instance.tld`. Actors like Persons and Groups and Applications have Public Keys attached to them, as well as their ID is probably cached by most software. So assigning some actor-name to something new also can cause unintended behavior.
@ -248,6 +249,7 @@ Anyway it seems the question has to be raised wheter activitypub should store a
- **Complex** ... - **Complex** ...
## Conclusion ## 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. - 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? - Additionally, shouldn't the user have a detailed overview in each case if the actor management should get more complex?