nostr:nprofile1qy2hwumn8ghj7un9d3shjtnyd968gmewwp6kyqpqdf0nthpgzfmvxrzj0cfypmmt45l0y770j260auqhm3l45hp3uhkqvrnptm You ideally should verify that AcceptFeatured refers to the type of the Object as expe...
@Phantasm
You ideally should verify that AcceptFeatured refers to the type of the Object as expected, effectively doing the same thing anyway.
It is not the same thing because you skip one expensive operation: determining the subtype of activity.
You also need to add that as a supported type to your Acccept/Reject validator since they are basically the same, you have to modify your activity builder, if you have one, to create these new types if you wish to support creation and not just ingestion.
Is that a problem? I already have different parsers and different builders for different activities.
The same argument can be made about Create/Update Activities which operate on a bunch of Object types. CreateNote/UpdateNote/UpdateActor/... doesn't make sense in my head as well.
Create and Update have an embedded object, so they do not require specialized names.
You ideally should verify that AcceptFeatured refers to the type of the Object as expected, effectively doing the same thing anyway.
It is not the same thing because you skip one expensive operation: determining the subtype of activity.
You also need to add that as a supported type to your Acccept/Reject validator since they are basically the same, you have to modify your activity builder, if you have one, to create these new types if you wish to support creation and not just ingestion.
Is that a problem? I already have different parsers and different builders for different activities.
The same argument can be made about Create/Update Activities which operate on a bunch of Object types. CreateNote/UpdateNote/UpdateActor/... doesn't make sense in my head as well.
Create and Update have an embedded object, so they do not require specialized names.
1