Automated activity specifying what triggered it

ActivityPub
1

tl;dr: I’d like activities published automatically (as a reaction to some other activity) to be able to state which activity triggered them. Looking for a property to use for this.

I’ll try to write this post as simply as I can, but I expect it may still be confusing and difficult to read. If it is, please let me know and I’ll clarify things or add a diagram etc. whatever can help me be understood :slight_smile:

Context

  • I’m working on ForgeFed
  • I’m designing and implementing a simple OCAP model/prototype for remote collaboration on repos, issues, PRs, etc. since (AFAIK) there’s no standard OCAP mechanism on the fediverse yet
  • I’d like it to be possible for implementations to understand (and display to the user) why a certain capability/delegation was sent to them, which human action is the reason for this capability being given to them
  • There are chains of automated delegations, so it’s not obvious what the original cause of the delegation is, without explicitly stating it (and anyway, stating it clearly is a lot nicer than having the implementation dig and infer and guess)

What an OCAP looks like right now (not final, suggestions welcome):

  • type: Grant
  • attributedTo: sender who is giving the access
  • target: recipient who is receiving access
  • context: The collaboratively editable resource/document/object, into which access is being granted
  • object: The kind of access being given, the role of the recipient within the resource

Example

  • Alice is a member of group A
  • Bob is a member of group B
  • Alice sends a Grant activity, inviting group B to have some access to a resource managed by group A:
id:           https://example.dev/grant1
type:         Grant
attributedTo: Alice
target:       Group B
context:      (Some resource managed by group A)
object:       Collaborator role

So, Alice is giving Group B access to resource as a collaborator. More precisely, Alice is giving this access to the members of Group B, to be collaborators on the resource.

Now group B delegates this access to its members, by sending its own Grant activity, to Bob. This new Grant tells Bob he now has collaborator access to a certain resource. But Bob would like to know, why he’s receiving this access from the Group B actor. And Group B provides him with this info, in 2 pieces:

  1. The Grant that group B sent has a parentCapability, pointing to the grant that Alice sent
  2. The Grant that group B sent has some “reason” property pointing to the fact that Bob is a member of group B, perhaps by pointing to the activity that added him there

From this info Bob can deduce: Group B received access to such and such resource, and it’s delegated to me because I’m a member of group B.

The Question

The question is, which property to use for pointing to the reason that the automated delegation was sent? Examples for reasons:

  • When a user creates a new group, the group sends back a Grant giving this user admin access to the group, so the “reason” would be the ID URI of the Create activity
  • If Group B is invited to have access to all the resources under group A (using a Grant activity of course), then whenever there’s a new resource created under group A, it needs to delegate access, sending a Grant to group B (which in turn delegates to its members). The “reasons” for the Grants that group A sends to group B are the original Grant that invited group B to access all of A’s resources, and the Create that created the new resource
  • Bob is being given access to a resource because he’s a member of group B, so the “reason” is the Grant that added Bob to group B

I wanted to (ab)use the context property but realized I’m already using it to specify the resource into which access is being granted. So I looked at the standard AS2 properties, and the only relevant thing I could find it inReplyTo. But I find it slightly confusing, because in this scenario it’s not an actual reply back to the sender, but rather a reaction possibly pointing to some other recipient.

I’m considering to just define custom properties for this. Instead of “object” and “context” use something like “role” and “resource”, in some AP extension vocabulary, perhaps ForgeFed itself if there’s no better place (perhaps a FEP is the best place?). And similarly I’d define a custom property for the “reason”. Maybe something like “inReactionTo” or just “reason”.

Another option perhaps: To use context for the reason(s) and find some other property to specify the resource in Grant activities.

Thoughts, suggestions, ideas? :pray:

Thank you for reading <3

2 Likes
2

(Didn’t read in detail yet, just want to bring to attention my toot on behalf of @bengo working on OCAP related things: ActivityPub ZCAPs)

3

So, I came up with a solution that should work for now, please comment if you have feedback :slight_smile:

  • Some actions on the fediverse are human instructions, and some actions are automated work that fulfills those instructions, taking care of the small detail
  • I’d like activities that are this sort of automated work, to be able to point at the human instruction they’re fulfilling
  • I’m adding a custom property fulfills, whose domain and range are Activity
  • Whenever a Grant activity is sent as part of the automatic behind-the-scenes detail, the fulfills property will be used to specify which human-meaningful activity is being fulfilled/supported/carried out by this automatic Grant
  • I’m still not sure whether to make fulfills a functional property (i.e. at most one value), in ForgeFed it seems there’s no need for multiple values so I’m tending go do with Yes and switch later to No if a relevant use case comes up (I think it’s less mess than switching in the other direction?)
4

@aschrijver thank you for linking to that AP ZCAP draft! It’s not relevant to my specific question but since I’m also working on OCAPs I’m glad to know about related efforts being done :slight_smile:

1 Like
5

Perhaps origin is the property you’re looking for?

The origin property is applicable to any type of activity for which the English preposition “from” can be considered applicable in the sense of identifying the origin, source or provenance of the activity’s object.

6

Have a look at the PROV-O vocabulary. It provides terms and classes to the describe the providence (i.e. the origin and history) of things.

It can be used to describe the providence of grants and thus explain why grants are generated.

For example this could be described by a PROV activity:

id: https://example.dev/grant-activtiy
type: prov:Activity
generated: https://example.dev/admin-access-to-new-group
prov:wasInformedBy: https://example.dev/create-new-group-activity

It might make sense to define your own specialized activity:

id: https://ocap.voc/GrantAdminAccessOnGroupCreation
rdfs:subClassOf: prov:Activity

and use this as type.

Note: a prov:Activity is a different kind of activity then an ActivityStreams activity. But it could be the object of a ActivityStream activity…

7

Phew. Trying to sum up the last ActivityPub meetings.
We want really to use context only for Groups (“grouping things”) …
My “feeling” is that context isn’t for the reasons.

The idea of the meeting group before was to federate Activities for inReplyTo …
It is a mess, we were tired after 3 hours : Summing up ideas from initial AS vocab discussion and for ActivityPub C2S · GitHub

but to keep it simple, how about

instrument

Identifies one or more objects used (or to be used) in the completion of an Activity.

8

i’d use context for this on first glance – Activity Vocabulary says the following:

Identifies the context within which the object exists or an activity was performed.

The notion of “context” used is intentionally vague. The intended function is to serve as a means of grouping objects and activities that share a common originating context or purpose. An example could be all activities relating to a common project or event.

your example use of context as “some resource managed by group a” might be better fit for tag if i had to guess? (attachment could work too)

of course, you also have the option of defining all this more explicitly in the ForgeFed namespace rather than trying to overload AS2 properties. but in this specific case i really think context works.

9

Thank you for all these suggestions! I’m on a tight schedule right now so I’ll say very briefly:

  • I’m not excited about context being used just for grouping things using Group; I hope to join the discussion on this in the future but for now going to continue making use of context where it makes sense (helps me save time, not needing to look for alternatives for now)
  • The PROV ontology is a nice opportunity for reuse, I’ll study it in the future, for now preferring a simpler solution since I just need to pick 1 property for 1 specific use case
  • tag and attachment are too general, they don’t mean anything in this context, while instrument and origin’s definitions don’t match the use case

So for now going to use a custom fulfills and keep your input for later :slight_smile:

10

I’d argue tag being general is not an issue. A tagged object is an associated or referenced object. It makes perfect sense to me – “here’s the context in which this grant exists, and i’m going to tag the associated resources you can now manage.” The semantic heavy lifting is done by the Grant type you have already defined as an extension.