added collision dedection of new actors #3

ruru4143 · 2023-10-03T16:38:38+02:00

ruru4143 commented

2023-10-03 16:38:38 +02:00

the current proposal of actor type registration doesn't include a function to check actor collision. This is needed to abort e.g. user or tribe_organizer creation.

ruru4143 added 1 commit 2023-10-03 16:38:39 +02:00

added collision dedection of new actors via registration function 00f08b2162

linos was assigned by ruru4143

2023-10-03 16:38:48 +02:00

openforfuture was assigned by ruru4143

2023-10-03 16:38:48 +02:00

openforfuture was unassigned by ruru4143

2023-10-03 16:39:04 +02:00

linos commented

2023-10-03 16:49:49 +02:00

I think it is not guranteed yet, that there must be a function like this. For sure the ActivityPub plugin must get to know that there is a new actor type ready to be applied. But the ActivityPub plugin itself could then do the checks for future collissions:

The wordpress actor-type must explain the activitypub plugin from which post type and how the actor name is created. Then the WordPress ActivityPub plugin could just apply a filter for 'save_post' and for example check whether the newly saved tribe_organizer has the same name as an already enabled user actor.

Note: I think we always have to remeber: what triggers the scheduling of ActivityPub sendings: it's when a user hits publish or update post. From this point the ActivityPlugin gets triggered and must find it's way what to do.

I think it is not guranteed yet, that there must be a function like this. For sure the ActivityPub plugin must get to know that there is a new actor type ready to be applied. But the ActivityPub plugin itself could then do the checks for future collissions: The wordpress actor-type must explain the activitypub plugin from which post type and how the actor name is created. Then the WordPress ActivityPub plugin could just apply a filter for 'save_post' and for example check whether the newly saved `tribe_organizer` has the same name as an already enabled user actor. Note: I think we always have to remeber: what triggers the scheduling of ActivityPub sendings: it's when a user hits publish or update post. From this point the ActivityPlugin gets triggered and must find it's way what to do.

ruru4143 commented

2023-10-03 17:05:37 +02:00

For this proposal our interface ActorType needs to be changed and it removes a lot of freedoms for the plugin registering ActorTypes. e.g. they can not use new database tables or fields created by them (idk if thats a practice some do) or creating new "global" actors, which aren't bound to a specific structure.

Yes, they could do it by working around our restriction by paring they db-structure with a post_type or creating a new post_type "plugin_global_actors".

I would prefer to add an good example how to interfere post/user creation and leave the control (and responsibility) to the plugin developer.

For this proposal our `interface ActorType` needs to be changed and it removes a lot of freedoms for the plugin registering ActorTypes. e.g. they can not use new database tables or fields created by them (idk if thats a practice some do) or creating new "global" actors, which aren't bound to a specific structure. Yes, they could do it by working around our restriction by paring they db-structure with a post_type or creating a new post_type "plugin_global_actors". I would prefer to add an good example how to interfere post/user creation and leave the control (and responsibility) to the plugin developer.

linos commented

2023-10-05 14:45:00 +02:00

I think we have to share our investigations and feature requests first with the upstream developers and discuss together what is possible in the near future before getting too much in detail.