add one more proposal for the transformer table: show origin
This commit is contained in:
parent
1b890d6c56
commit
933efdb1ca
1 changed files with 4 additions and 2 deletions
|
@ -95,7 +95,8 @@ available for a given post type are greyed out in the user interface:
|
|||
**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?).
|
||||
- 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
|
||||
|
||||
|
@ -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).
|
||||
|
||||
|
||||
## Possibilities
|
||||
ActivityPub knows several [actor types](https://www.w3.org/TR/activitystreams-core/#actors):
|
||||
- `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".
|
||||
|
||||
## 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.
|
||||
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** ...
|
||||
|
||||
## 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?
|
||||
|
|
Loading…
Reference in a new issue