think about a Follow activity for example. who's to say that a Follow needs to be Accepted? why do we not expect or require people to Accept a Like, Announce, etc?

you could generalize the pattern of Activity -> Accept(Activity) -> Add(Activity) to special collection

and these things happen even if we don't reify them as activities. just because you never generated an Add targeting the followers collection doesn't mean that this didn't implicitly happen. it just means you don't have a description of this happening

from a behavioral standpoint this seems as good a mechanism as any to have "approved interactions" as long as those actions have an Activity.

but it's also important to recognize that there is a distinction and disconnect between "action" and "result". often in fedi we care more about result than action. for example, the Create(Note) is less important than the Note itself

so we might likewise say that state is (or should be) bound to results, not actions. if state were bound to actions, we would need to replay actions or search backwards to find the most recent state-invalidating action

and authorization is itself a result or action

so in the example of Follow -> Accept(Follow) we can say that the Accept is the "action", while the Add targeting the followers collection is the "result". the final state that we care about (the ultimate result) is what's in that collection

if we wanted to generalize to other interactions then we can "prove" authorization either by reifying an action or reifying a result. the former would have us describe an Accept or Add; the latter would have us Create an authorization object

but we have duality at play here -- mainly, the activity-object duality, which is that activities are also objects; actions are also resources (and therefore in some ways results). actions or activities can result in other resources which may themselves be activities.

so we can say that a Create resulted in both a Note and an Accept, and this Accept itself resulted in both an Add and a Create, and this latter Create resulted in an authorization object

to be fair this is probably more detail than most people care about; after all, in fedi we usually only care about results. so for keeping track of state, we make all the activities implicit except for the initial Create and maybe an Accept (at least in the case of Follow)

given this, we could also make a distinction between just performing an Activity vs Creating it as a resource, by issuing a Create(Activity) instead of an Activity

so for example we could do Create(Accept), odd as it may be

the thing that i'm not sure about is, basically this all stems from a question about using an Accept as the "authorization object" but not knowing how to handle revocation. if you were to perform the Accept itself then it would persist in your outbox, and can you later Delete the Accept? is that even allowed? so you need a way to more or less "decompose" the Accept activity into its "activity" half and its "resource" half, where the former has side effects (like RPC) and the latter sticks around

of course it's entirely possible that some other vocabulary would be better for describing these "authorization objects"; maybe they don't need to be Accept activities. and therein lies the issue which sparked this line of reasoning. semantically, it's not wrong to describe an authorization as an Accept activity; the activity-object duality makes it somewhat natural. but it's not clear when it functions as an activity and when it functions as an object

trying to fit this onto AP, the only way i can see this working is:

1) client does AP POST to outbox: Create(Accept)
2) outbox handler returns 201 Created with an id on the Create and an inner id on the Accept
3) client does raw LDN to AP inbox using the inner id and inner payload of the Accept that was just Created

not good, huh

the other "solution" is to allow using AP to Delete arbitrary past activities, which sounds... a lot worse