There are two kinds of "collections" in ActivityPub:
-
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]Collectionobjects withitemsproperty. However, in practice they are different. For example, it's reasonable toUpdatea playlist to change its name, but what anUpdateof afollowerscollection would mean?Usually, I argue that containers and views shouldn't be mixed. Don't add
itemsto your thread/playlist/album, create a separate collection instead.Are there other options?
@mariusor How do you deal with this problem in GoActivityPub?
RE: https://mastodon.social/users/dansup/statuses/115596404697985830
-
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]Collectionobjects withitemsproperty. However, in practice they are different. For example, it's reasonable toUpdatea playlist to change its name, but what anUpdateof afollowerscollection would mean?Usually, I argue that containers and views shouldn't be mixed. Don't add
itemsto your thread/playlist/album, create a separate collection instead.Are there other options?
@mariusor How do you deal with this problem in GoActivityPub?
RE: https://mastodon.social/users/dansup/statuses/115596404697985830
@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
-
@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
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
firstandnext? -
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
firstandnext?@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.
-
@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.
@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).
-
@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).
@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) -
@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)@mariusor Do you have any other reserved properties (in addition to
id,itemsand 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
Notewith arepliesproperty, does the server create a replies collection automatically?
