A publicly readable "inbox" of events for non-actor objects


#1

Suppose I have an object, for which I’d like to be able to provide an OrderedCollection of activities related to it. For example, imagine an Issue object displayed on a web page, and under the description there’s a list of the comments and/or other related events. If you look at this example you can see comments and other events displayed together, and if you choose “show history only” you’ll see only non-comment events.

If the object for which I’d like to display events is an ActivityPub actor, then I can make sure all the related events land in its inbox, right? And make that inbox publicly accessible (possibly filtering out any private/team/staff/admin related events). But what if the object isn’t an actor? This leads me to ask:

  1. Should an object become an actor whenever I want to provide a view of events related to it? For example should every issue of every repo be an actor?
  2. If not, how do I provide the collection-of-events?

If the answer to (1) is no, i.e. don’t make it an actor, then we can just add some field to the object, whose value is a collection of events. I’d like to propose, that we give this property a standard name, so that it can be easily recognized. But to avoid confusion, that name probably shouldn’t be “inbox”. It may be tempting to use “inbox” because it’s standard, but it’s also misleading, because it’s not an actual inbox, because no delivery happens there. It’s just a collection generated from the inbox of some parent object that is an actor and has a real inbox.

I’d like to suggest the name “events” for this property. It’s not a final name, and open to feedback. It’s just the name I’m using in Vervis to provide a collection of events related to issues, much like those events in the example I linked. (and hmm I don’t have a specific suggestion for the JSON-LD context that would define this property)

Thoughts and feedback very welcome!!! What do you think and what do you use in your projects :slightly_smiling_face:


#2

I agree that a new property for this is probably best. However if we are talking about a collection of Activity objects it should be called activities. After all, Event is a completely different type of object. It would be confusing even for native English speakers, and doubly so for nonnative.


#3

@rialtate, good point! I forgot “event” is being used in the calendar sense. Switching to “activities” then :slight_smile:


#4

I’d argue it’s better to name a collection after the meaning and not after what it is storing.

If I get a collection of “activities” then what does that actually mean? That’s a name that describes “inbox”, “outbox”, “likes”, any collection whose contents are only Activity types, etc. It’s so vague it’s actually meaning-less!

However, if it is named something like “responses” or “replies” or “history” or “objectOf”, then suddenly a collection of activities has a much clearer intended meaning behind it.

My two cents.


#5

@_cj, @rialtate, hmmmmm I’m wondering which meaningful name it could have then.

The meaning of the collection is related events or related activities. Hmm but maybe there is a better description. For example, for a ticket, related events would include status changes, mentions in other tickets, merge requests mentioning the ticket, people being assigned to the ticket or unassigned, things like that. Hmm a word that comes to my mind it “updates”, but things like mentions in other tickets aren’t necessarily updates, they’re just related information interesting to people.

Perhaps a better definition is “news about this object” or “activities related to this object”.

Hmmm how about relatedActivities for the property name? Another one is interestingActivities but I think it may be too specific, because not all cases of “activities related to this non-actor object” are necessarily about being interesting to humans.

Hmm or maybe something with the word “timeline”? Or “history”?


#6

I don’t see why an Ticket/Issue should not be an actor.

  • I can follow it (Follow to inbox (S2S))
  • I can post comments (Note to inbox(S2S))
  • I can update metadata (Update to inbox(S2S))

All these Activities that happened since creation of the issue are then available in the outbox.

What are the reasons to not make an Ticket/Issue an Actor? ^^


#7

Well, this touches 2 different questions.

  1. Should everything be an actor? If not, then imagine my original question about an “events” property, applied to some object that isn’t an actor.
  2. Should tickets be actors? That deserves its own discussion, and indeed, following discussion on IRC, my current proposal is here. In that proposal, tickets aren’t actors. But it’s still just a proposal and feedback is very welcome :slight_smile:

#8

@_cj @rialtate does the name relatedActivities sound reasonable?


#9

Seems like I misunderstand actors, will have to look into AP again.


#10

Still sounds too vague to me, one app’s “related” activities may be semantically different than your app’s. Also still has the “what” it is in the name (activity), which isn’t helpful. How about simply history? And then separate collections for the objects list this ticket needs (list of replies, list of tags, list of state changes, etc)


#11

Sounds good! history chosen as the property name :slight_smile: