Updating an Offer


#1

Offer is a type of Activity, which “Indicates that the actor is offering the object.”

Update is an a type of Activity, which “Indicates that the actor has updated the object.”

How would an actor indicate that it has updated the Offer? For example, to change the target?

Related questions:

  • Has anybody used Offer? If so, how did you use it?
  • Has anybody tried to Update an Offer?

Offer should be Object, not Activity
#2

I’m not aware of an implementation using Offer currently.

However, the AS specification says the domain (permitted value types) for object is Object, and since Offer (via Activity) extends from Object, it seems like one could do:

{
  "id": "https://example.com/update/1",
  "type": "Update",
  "object": {
    "id": "https://example.com/same/old/offer/id",
    "type": "Offer",
    "object": "https://example.com/same/old/object",
    "target": [
      "https://example.com/same/old/target",
      "https://example.com/new/additional/target"
    ]
  }
}

This may be a surprising result as I would expect most application developers think Update can only work on the “nouns” of the ActivityStreams extensions (Note, Article, etc). I haven’t given enough thought to the ramifications of using an Update on the “verbs” (activities) to know whether it is a good or bad idea.


#3

I think your suggestion is fine @_cj, there are already common similar case, like Undo applied on Follow, which are both activities :slight_smile:


#4

I agree @eliotberriot, the Undo use case is pretty clear that the object is an Activity. The concept of an Undo captures this as well as the ActivityStreams documentation itself.

My surprise wasn’t whether “in general, can an Activity be an object value” but rather “specifically for an Update can an Activity be an object value”. The by-the-books answer is “yes”. But thinking of the semantic meaning of an Update and after countless hours of experience working with the examples (and their implicit biases) I realized I had subconsciously assumed it was originally intended for the things of the Fediverse, not the doings.

On the one hand, Undo has a pretty clear semantic meaning behind having an Activity as the object. Whatever the app did, apply the inverse function to return to the original state. This is easy to write code for: it is a consistent transformation across all types.

On the other hand, an application getting an Update with an Activity is not a consistent transformation across all types. Take the two following examples.

One: My interpretation of getting an Update with a Follow that has a new object would involve the application:

  1. Detecting the specific property difference and understanding this means “undo following the previous value, begin following the new value”
  2. Undo-ing any actions done in Section 7.5 of the ActivityPub spec
  3. Re-processing the updated Follow (based on the aforementioned section)

Two: My interpretation of getting an Update on a Create that has a new object would involve the application:

  1. Detecting the specific property difference and understanding the object difference means “delete the old value, create the new one”
  2. Delete any data referring to the old Create object. This requires my application to have stored the original Create (not an IRI reference to it) in order to know the old object, since the federated peer no longer has that connection. If I didn’t store this in my app, then uh oh.
  3. Process the Create as normal.

My alternative preferences for the above examples would be:

  • Example 1: An Undo of the first Follow, send a new Follow
  • Example 2: A Delete, send a new Create

Note that these two examples therefore show that there is no common inverse function for an Update with an Activity for an object (each of the above requires special logic). Unlike the Undo use case.

This is why for Update specifically, I think ActivityPub extension spec writers need to be very careful in defining what it means to…

  1. Update their specific Activity, and/or
  2. Update an Activity whose object or target contains a value of their type.

This makes me lean towards a design rule of “Prefer to Update nouns, not verbs (Activity)”, but I don’t know for sure. I guess this is the beginning of some “deep” thought I mentioned before, but I still have not convinced myself.


#5

Agree with “Prefer to Update nouns , not verbs ( Activity )”.

See also Offer should be Object, not Activity


#6

“An Activity is a subtype of Object,” so we should be prepared to handle Activities as Objects in AS documents. An implementer can recurse into the tree if they aren’t using inheritance, so it shouldn’t be a problem in practice as long as programmers know not to hardcode an arbitrary depth to crawling the document.

Umm, yeah. It’s going to be a disaster. :rofl: