Representing the cause of an activity
Technical Discussion
7
Posts
2
Posters
0
Views
-
In Activity Streams 2.0, we can represent the result of an activity using the
resultproperty. Here, when the actor accepts aFollowactivity, the result is that the follower is added to the actor'sfollowerscollection.{ "@context": "https://www.w3.org/ns/activitystreams", "id": "https://social.example/accept/12931", "type": "Accept", "actor": "https://social.example/person/24405", "to": ["as:Public", "https://other.example/person/21356"], "object": { "id": "https://other.example/follow/30360", "type": "Follow", "to": ["as:Public", "https://social.example/person/24405"], "actor": "https://other.example/person/21356", "object": "https://social.example/person/24405" }, "result": { "id": "https://social.example/add/11066", "type": "Add", "actor": "https://social.example/person/24405", "to": ["as:Public", "https://other.example/person/21356"], "object": "https://other.example/person/21356", "target": "https://social.example/person/24405/followers" } }My question is: how can the
Addactivity refer to the activity that caused it? I don't think we have a standard property for this. My best guess right now iscontextor maybeinstrument, neither of which seems ideal. I think an extension inverse property, likeresultOf, might be the best option. -
@evan hi Evan, I think we would need some examples of what you consider a cause to be in order to develop this idea further
-
@evan@activitypub.space @evan@cosocial.ca i.e. can another activity be considered a cause which raises the question of whether an activity stream stream can be considered a network graph delivered overtime
-
@evan I don’t know just random driving thoughts
-
@evan hi Evan, I think we would need some examples of what you consider a cause to be in order to develop this idea further
sivy@hachyderm.io I used an example in my original post! The
resultproperty describes this relationship.https://www.w3.org/TR/activitystreams-vocabulary/#dfn-result
Here are a few more:
- When an actor arrives at a place, the actor updates their own location
- When an actor likes an object, the actor adds the object to their liked collection
- When an actor unfollows someone, the actor removes that someone from their following collection
So, I see it particularly useful for the side-effects defined by ActivityPub, but there may be other good uses.
-
@evan this is what happens when you read the fedi at stoplights.
I'd think some kind of link to the "triggering" activity in the result.
(I'm speaking from a very old and rusty memory of AP, but)
Is a result an activity? Can it live on it's own? If not, it seems like a processor can make the assumption that object → result? Otherwise, a link to the triggering activity by id could work. But what to call that link? <shrugs>
-
Dagnabbit. Here's a comment from 11 years ago on this topic!
https://github.com/w3c/activitystreams/issues/20#issuecomment-58034202
Gli ultimi otto messaggi ricevuti dalla Federazione
-
If I used an object observer for a topic/context, and proceeded to delete that context, the object observer would go away too.
That is, unless you're inferring that I take steps to preserve the object observer for some period of time (if not forever?)
-
Dagnabbit. Here's a comment from 11 years ago on this topic!
https://github.com/w3c/activitystreams/issues/20#issuecomment-58034202
-
it feels like an unnecessary abstraction for the purposes of skirting around a limitation in the ActivityPub specification.
What limitation?
The problem is not that ActivityPub has a limitation, the problem is that it doesn't have enough. It can't be used to build a real application because it doesn't specify what is valid and what is not. it doesn't even specify what an "actor" is.
Fortunately, the answers to these questions were found and documented in FEP-fe34 and FEP-2277. Object observers are likely compatible with both FEP-fe34 and FEP-2277. Other ideas are not compatible.
In your proposed structure (feel free to correct if wrong), a resolvable context would declare an observer property pointing to an Actor, who would be federating actions out on its behalf.
Yes. I think some property can also be added to posts to simplify discovery e.g. Note.contextObserver.
However, it has the same technical hurdle — lack of existing implementation — than the alternative, which is to multi-type the collection into ["OrderedCollection", "Service"] or similar.
So ["OrderedCollection", "Service"] is supposed to be an actor that is also a dynamic container? That doesn't make any sense, and I don't know how to implement that in C2S setting. It also conflicts with FEP-fe34 and FEP-2277.
-
@julian mastodon has a level between "followers-only" and "mentioned-only", which represents exactly this case -- "limited". this means that there are addressees who are not are not accounts, and who are not your followers. to mastodon, these are basically "unknown recipients", and it records the fact that they were addressed but not who they are (its database model doesn't support this)
but activitypub only has actors and collections (while overlooking that the same thing might be both)
-
@julian yes, this is an area where AP actually contradicts AS2 for no good reason. semantically it should be origin, but the side effects of AP are defined wrt target.
-
@julian that's pretty much exactly what happens iirc, except instead of "it isn't an actor", the check mastodon does is "it isn't a Person/Group/Organization/Application/Service".
multityping [OrderedCollection, Service] as you propose would cause mastodon to try to process it as an actor, but likely fail when it doesn't pass the webfinger assertion and therefore can't be converted to an Account entity.
-
@julian if "no one POSTs to outbox" is an argument for axing the outbox, then i don't know what we'd be discussing, because what would be left? i mean, maybe we can say "addressing collections no longer expands delivery to items", but then we presumably need an alternative that doesn't involve addressing actors one-by-one.
-
trwnh@mastodon.social said in Context deletion vs. Removal brainstorming:
> also Remove is defined with respect to object+target, not object+origin.That's fine, I'll make the corresponding change.
I was basing it off this line in the AS spec:
> If specified, the origin indicates the context from which the object is being removed. [[source](https://www.w3.org/TR/activitystreams-vocabulary/#dfn-remove)]
