x_x that’s a lot! and even then, it doesn’t account for extensions…
the actions i would want to control access to are things like:
- GET ldp:inbox
- POST as:outbox
- POST as:proxyUrl
the modulation of these actions is where the dragons are. say for example you want only some POSTed payloads to pass through the as:outbox. we don’t have a common way of describing those restrictions, but in plain english you can imagine some restrictions/conditions like “it is a Like activity” ([a as:Like;]). this is inherently a shape constraint, hence why i suggested SHACL at all.
english: “allow POSTing to the outbox any activity that matches this shape”
json(-ld) description that could be a RAR:
"authorization_details": [{
"@context": {...},
"path": "outbox", // this is @type: @vocab -> as:outbox
"method": "POST", // this is @type: @vocab -> http:POST
"shape": {...} // this is applied to the content/body
}]
we would need to agree on a context for terms used in the RAR just like we (hopefully!) agree on a context for terms used in an activity.
if the “API” used different endpoints (i.e. different collections you could POST to), then perhaps we wouldn’t strictly need to understand shapes. say for example that liking an object involved POSTing a Like activity not to your outbox, but instead to an endpoint that forwards the Like activity to one or more of the following dispatch targets:
- the object’s as:likes collection
- your as:outbox collection
- your as:liked collection or similar
this is basically what mastodon does when you POST /api/v1/statuses/:id/favourite, although a more streamlined design would be a single endpoint a la /api/v1/favourites. you could advertise this endpoint in the as:endpoints mapping:
{
"type": "Person",
"name": "Alice",
"endpoints": {
"proxyUrl": "...",
"_:like": {"id": "..."}, // POST a Like activity here as described above
"_:share": {"id": "..."},
"//": "..." // and so on
}
}
the outbox would still accept arbitrary activities but not necessarily tie the “side effects” to those. but again, unfortunately, activitypub’s current design does attach the “side effects” to the outbox activities and forces everything to flow through the outbox, thus necessitating this discussion about shape constraints of some kind.
i think you could try to extract ux-level concerns such as “like any object”, “share any object”, etc, but you wouldn’t be able to modulate any further than that without shapes, e.g. you can’t request access to “like and unlike objects within a specific context” or so on. there’s a tradeoff in how complex you want to allow these details to be, which both empowers and confuses people. (it’d be easier to extract these as separate endpoints, though…)
