Posting Collection/OrderedCollection to an inbox

ActivityPub Server to Server
1

The code base which I have forked from supports receiving Collections and OrderedCollections as objects in the inbox. The contained activities are handled as if they had been received individually.

As far as I saw this is at least not explicitly mentioned in the specification(s), and what I read suggests to me this is not correct. Since collections are not activities, this does not seem to be covered by the following:

An HTTP POST request (with authorization of the submitting user) is then made to the inbox, with the Activity as the body of the request.
– ActivityPub (emphasis mine)

My question: Is this covered by the specification and/or do other servers implement it?

An example use case would be sending multiple delete/undo activities at once. This is because we allow users to

  1. Announce the same object multiple times, and
  2. Undo all Announces of an object at the same time.

Since we deliver Delete/Undo activities to the whole known network because we do not know who may have fetched it, and there is overhead associated with each delivery / HTTP request / deliver queue item, it is desirable to group these activities. For this use case it is important that activities are understood properly by our peers and not discarded, hence this question.

2

that sounds pretty non-standard, yeah. you could technically have an activity with multiple types or multiple objects, but not a Collection.

example of multiple types:

actor: alice
type: [Create, Add]
object: post
target: collection

this could be interpreted as “Create object” and also “Add object to target”. in plain english this would be “alice created a post and added it to a collection”. upon receipt in the inbox, it has the side effects of both Create and Add as defined by activitypub’s s2s delivery section.

example of multiple objects:

actor: alice
type: Create
object: [post1, post2, post3, ...]

this could be interpreted as “Create each item in object”. in plain english, “alice created x posts”. it has the side effects of Create as defined in activitypub’s s2s delivery section, but across multiple objects.

of course the obvious caveat here is that most implementations do not understand more than the most basic of activities, as they are not working with a generic activitypub Server that has predictable side effects, but they are instead translating the activity to internal models and then passing them off to handlers with their own project-specific side effects. (i mean, look at how mastodon-style poll votes work. 'nuff said.)

if you are okay with these activities possibly being misunderstood or dropped, then you could take the second approach above and send out an Undo where object is an array:

actor: misskist
type: Undo
object: [announce1, announce2, announce3, ...]

this also only works if the remote server implementation stores the id of each announce it receives and can lookup/translate that to some internal database entity or whatever.

3

It doesn’t appear to be mentioned in the specification. Mastodon supports posting either activity collections or individual activities to the inbox.

4

really? surely this is not intended behavior if so.

5

I’m not a Mastodon developer or a Ruby programmer, but it looks intentional to me. The AP inboxes controller passes the incoming request body to the ActivityPub::ProcessingWorker which passes it to the ActivityPub::ProcessCollectionService. In that service the message is handled with:

    case @json['type']
    when 'Collection', 'CollectionPage'
      process_items @json['items']
    when 'OrderedCollection', 'OrderedCollectionPage'
      process_items @json['orderedItems']
    else
      process_items [@json]
    end

It looks to me that a single item is actually normalized to a collection for further internal processing. The process_items method looks up a handler factory for each item (Create, Follow, etc.) and then dispatches the item to that handler.

Edit: The code snippet I quoted was committed prior to the AP specification being released (Aug 2017) so maybe it was based on some evolving understanding of AP at the time. ???

2 Likes
6

it looks like that code was added in https://github.com/mastodon/mastodon/pull/4216

Gargron:

I expect the inbox to receive one Activity at a time

puckipedia: Add ActivityPub inbox by Gargron · Pull Request #4216 · mastodon/mastodon · GitHub

It seems you’re expecting the inbox to get an OrderedCollection? Unlike WebSub, ActivityPub just POSTs the Create/Update/Delete/other Activity directly into the inbox:

Gargron: https://github.com/mastodon/mastodon/pull/4216#issuecomment-315597555

No, I expect to use this parser class for everything though

so i guess it is not intended, but it might end up working as you describe regardless? in any case, i would not depend on this behavior at all. it is not standardized and it is not part of the activitypub spec. that misskey happens to do the same thing is entirely a coincidence.

3 Likes