nostr:nprofile1qy2hwumn8ghj7un9d3shjtnyd968gmewwp6kyqpq6aef0yqmns3cmj407d0laqen5l3w5lflm5flc25raxrnhrn20enqds834j nostr:nprofile1qy2hwumn8ghj7un9d3shjtnyd968gmewwp6kyqpq6a2rqwxetkllufxsyjjjddphp7qzxap...
@silverpill @nprofile1q... @nprofile1q... @nprofile1q...
>Usually it's an extra database query. With AcceptFeatureRequest, you can apply side effects right away.
If you are receiving Accept for something, there's probably a check somewhere if the Accepted thing exists to you anyway. Not doing so in the context of this FEP would result in adding a possibly non-existent Object to a Collection. If you store AP Activities/Objects as JSON in your DB the type comes for free with the existence check. If your AP data is more normalized, then yes you would have to join tables using indexes, or possibly re-query the DB to include the type.
Reject might need the same checking as Accept or might not depending on the target.
>Usually it's an extra database query. With AcceptFeatureRequest, you can apply side effects right away.
If you are receiving Accept for something, there's probably a check somewhere if the Accepted thing exists to you anyway. Not doing so in the context of this FEP would result in adding a possibly non-existent Object to a Collection. If you store AP Activities/Objects as JSON in your DB the type comes for free with the existence check. If your AP data is more normalized, then yes you would have to join tables using indexes, or possibly re-query the DB to include the type.
Reject might need the same checking as Accept or might not depending on the target.
1