There are two kinds of "collections" in ActivityPub:

[silverpill@mitra.social]

@mariusor Do you have any other reserved properties (in addition to id, items and pagination properties)?

This doesn't feel right to me, and creates a problem for nomadic AP where clients submit signed activities and servers can't overwrite any property.

>the docs have 5 including Create, but that will go away soon

That's another interesting aspect of collections. If a client submits a Note with a replies property, does the server create a replies collection automatically?

[mariusor@metalhead.club]

@silverpill only an actor that owns the collection can operate on it, and only the server that resides on the same host can operate on collections with that host. Ie, all the logic I'm describing refers to client to server, collections that reside on other servers are not really relevant.

And I don't know if I mentioned it before, mostly GoActivityPub focuses on the vanilla specification, the fancy use-cases in FEPs, like nomadic identity, are outside the scope until we can make use dynamic object types - which is not the case at the moment, we're limited to plain Activity vocabulary.

[silverpill@mitra.social]

@mariusor I understand, and this is not a criticism of your implementation. I think the problem I described is not limited to nomadic AP, the vanilla specification doesn't tell us how clients should work with collections, so we need to figure it out by ourselves and document in a FEP.

>we're limited to plain Activity vocabulary.

replies is a part of the vocabulary. Does your server support it?

[mariusor@metalhead.club]

@silverpill yes, I was thinking of the nomadic identity aspect when I said that.

So, for GoAP: a user wants to upload an image, it can specify recipients, the client builds an Image AP object out of that (including a reply collection) and wraps it in a Create collection, sends it to the server (C2S).

Server saves Image locally, creates all collections for the Image that are not empty in the Image (like replies, likes, shares, etc) adds it to outbox of user's Actor, adds it to local follower's Inbox or sends it to remote followers Inbox (S2S). If it's in reply to something(s) loads the object(s) and disseminates it to the recipients.

[silverpill@mitra.social]

@mariusor I've started to collect information here: https://codeberg.org/silverpill/feps/src/branch/main/9f9f/fep-9f9f.md

[mariusor@metalhead.club]

@silverpill regarding pagination, I do

next=URL encoded ID of the latest item in the items' collection

prev=URL encoded ID of the first item in the items' collection.

This is very verbose, but I haven't found a better solution that doesn't require additional storage or context (like DB ids for example).

As always, for examples you can look at federated.id:

https://federated.id/inbox?maxItems=100

[silverpill@mitra.social]

@mariusor Could you tell me more about how replies and similar properties are treated by GoAP servers?

I initially imagined that clients would put collection ID there, but regular ActivityPub clients (not FEP-ae97) are not supposed to mint identifiers.

So I decided to remove this from my Collections FEP and recommend explicit creation instead (via Create activity).

One possible solution is to introduce a special value (such as null), that tells server that it should create a collection:

{
  "type": "Note",
  "replies": null
}

cc @trwnh

[mariusor@metalhead.club]

@silverpill the Go ActivityPub state machine creates all collections that appear as properties in an object. So if the client has filled the replies collection with an IRI that is namespaced to the instance (or better yet, the user), it creates that an OrderedCollection using that as an ID.

So for your example, there would not be a replies created.

However the servers built with GoActivityPub have no universal rule about clients not being able to generate IDs. When they receive an object with ID they try to create it, if it fails, it fails, if it succeeds... cool. This helps with allowing users to have nice URLs for their content.

@trwnh

[mariusor@metalhead.club]

@silverpill basically I did it like this because I wanted to short-circuit clients having to send Create activities that create the collections at the same time.

I can think of a flow where you create all collections that you want the actor/object to have, then you create the actor/object by setting those collections' ids in the right places, but it feels a little unwholesome.

With the automatic creation, I can also set ownership on the collections to the actor that created them, or the actor that they belong to.

In GoAP this relies a lot on URL paths having meaning and not being opaque blobs as the specs say, which might not be for everyone...

@trwnh

[mariusor@metalhead.club]

@silverpill PS. did I miss where the spec forbids clients passing IDs to the Create objects, or am I right that it could be a valid mechanism?

@trwnh