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? -
@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?@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 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.
@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.
repliesis a part of the vocabulary. Does your server support it? -
@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.
repliesis a part of the vocabulary. Does your server support it?@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 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.
@mariusor I've started to collect information here: https://codeberg.org/silverpill/feps/src/branch/main/9f9f/fep-9f9f.md
-
@mariusor I've started to collect information here: https://codeberg.org/silverpill/feps/src/branch/main/9f9f/fep-9f9f.md
@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:
-
@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.
@mariusor Could you tell me more about how
repliesand 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
Createactivity).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 Could you tell me more about how
repliesand 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
Createactivity).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
@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.
-
@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.
@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...
-
@mariusor Could you tell me more about how
repliesand 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
Createactivity).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
@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?
Ciao! Sembra che tu sia interessato a questa conversazione, ma non hai ancora un account.
Stanco di dover scorrere gli stessi post a ogni visita? Quando registri un account, tornerai sempre esattamente dove eri rimasto e potrai scegliere di essere avvisato delle nuove risposte (tramite email o notifica push). Potrai anche salvare segnalibri e votare i post per mostrare il tuo apprezzamento agli altri membri della comunità.
Con il tuo contributo, questo post potrebbe essere ancora migliore 💗
Registrati Accedi