Conversation

Notices

1. Embed this notice
   silverpill (silverpill@mitra.social)'s status on Monday, 24-Nov-2025 02:27:15 JST silverpill

   • dansup
   • marius

   There are two kinds of "collections" in ActivityPub:

   - Containers. These are basically objects that represent groups of other objects: threads, playlists and photo albums. ActivityPub clients can create, update and delete them.
   - Views. These are generated on the fly by the server, can be paginated and filtered. Inbox and outbox are most common examples.

   Both are supposed to be [Ordered]Collection objects with items property. However, they are in practice they are different. For example, it's reasonable to Update a playlist to change its name, but what an Update of a followers collection would mean?

   Usually, I argue that containers and views shouldn't be mixed. Don't add items to your thread/playlist/album, create a separate collection instead.

   Are there other options?

   @mariusor How do you deal with this problem in GoActivityPub?

   @dansup

   RE: https://mastodon.social/users/dansup/statuses/115596404697985830

   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Monday, 24-Nov-2025 05:53:53 JST silverpill

     in reply to

     • marius

     @mariusor

     I allow all collections' properties to be modified with Update activities with the exception of the items property itself.

     Do you allow to update special collections like inbox and outbox?

     What about overwriting pagination properties like first and next?

   • Embed this notice
     marius (mariusor@metalhead.club)'s status on Monday, 24-Nov-2025 05:53:55 JST marius

     in reply to

     @silverpill I allow all collections' properties to be modified with Update activities with the exception of the items property itself. For those I allow Add/Remove/Move, etc.

     I don't see a reason to make a distinction between what you call views and containers.

     If there would be a distinction to make, I would consider views as random object arrays that are accesible at a certain URL (and I would add them in the Streams property of an Actor). Instead of a generated CollectionPage, you would only get its items.

     pro@dansup@mastodon.social

   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Monday, 24-Nov-2025 07:15:37 JST silverpill

     in reply to

     • marius

     @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?

   • Embed this notice
     marius (mariusor@metalhead.club)'s status on Monday, 24-Nov-2025 07:15:39 JST marius

     in reply to

     @silverpill basically a storage to be able to work with GoActivityPub needs only 4 operations (the docs have 5 including Create, but that will go away soon):

     Load (IRI, Filters),
     Save (Object)
     AddTo (Collection, Object)
     RemoveFrom (Collection, Object)

     https://pkg.go.dev/github.com/go-ap/processing#Store

   • Embed this notice
     marius (mariusor@metalhead.club)'s status on Monday, 24-Nov-2025 07:15:40 JST marius

     in reply to

     @silverpill collections for GoActivityPub are not really special. A collection is an object which can be operated on with most of the Activity vocabulary to various degrees of success (based on what's in the spec, or based on what felt sensible at the time).

     The only way in which they are *special* is that when processing activities the collection ID gets extracted from the actor it belongs to, and gets operated on (for example to add an activity to an outbox or inbox).

   • Embed this notice
     marius (mariusor@metalhead.club)'s status on Monday, 24-Nov-2025 07:15:41 JST marius

     in reply to

     @silverpill yes to first question, and no to second question because collection pages are indeed dynamic. When a collection gets retrieved from storage, if there are filters on it, they get applied and the resulting object becomes a collection page where first, next, previous are computed dynamically based on the filters.

     I haven't found a good method to do away with this conceit yet.

   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Tuesday, 25-Nov-2025 07:39:38 JST silverpill

     in reply to

     • marius

     @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?

   • Embed this notice
     marius (mariusor@metalhead.club)'s status on Tuesday, 25-Nov-2025 07:39:40 JST marius

     in reply to

     @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.

   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Tuesday, 25-Nov-2025 21:37:22 JST silverpill

     in reply to

     • marius

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

   • Embed this notice
     marius (mariusor@metalhead.club)'s status on Tuesday, 25-Nov-2025 21:37:24 JST marius

     in reply to

     @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.