I have a couple of clarifications regarding what GoActivityPub does, that might be useful for this FEP:
On "Updating collections"
I think it's worth clarifying that Add, Remove, Move refer to operations on the items/orderedItems property of the collection.
Perhaps also clarifying IF these operations should update the updated property of the collection, which I think they should.
Additionally I think that clarifying that the other properties of the collection can/should be modified through Update activities using the normal ActivityPub flow.
I think it's worth adding the standard term used for "cursor pagination" in the technical literature, which to the best of my knowledge is "keyset pagination".
On Access control
This section can be expanded a little, I'm not sure there's any FEP's that proposes this idea already, but it can be generally applied to all local objects a service exposes.
The "SHOULD be filtered based on the permissions of a user" is pretty vague, so I'd clarify that the "user" is reconstituted based on whichever authorization mechanism the user-agent is using (OAuth2, HTTP-Signatures, or something else) and which contains a valid Actor ID. (Eg, in the case of HTTP Signatures, we retrieve the Public Key and consider its Owner as the authorized user)
If that's not possible, only Public addressed content is returned.
Secondly, I think the method of building the access control list could be detailed.
In GoActivityPub I'm using all the recipient fields (To, CC, Bto, BCC), so including the blind ones, to build the list of Actor IDs that then get checked against the authorized user from above. Also the "Audience" property can be used.
And a last thing that I'm doing in GoActivityPub, is that there's two levels of access control checks for collections:
- The collection object itself needs to be accessible to the authorized user.
- The individual items in the items/orderedItems list get filtered separately based on their own recipients ACL against the same authorized user.
In conclusion, I'm not sure if all these ideas are valid to be used on a larger scale, but some feel "common sense" enough that they might be generally applicable.
I have a couple of clarifications regarding what GoActivityPub does, that might be useful for this FEP:
### On "Updating collections"
I think it's worth clarifying that `Add`, `Remove`, `Move` refer to operations on the items/orderedItems property of the collection.
Perhaps also clarifying **IF** these operations should update the `updated` property of the collection, which I think they should.
Additionally I think that clarifying that the other properties of the collection can/should be modified through `Update` activities using the normal ActivityPub flow.
### On Pagination
I think it's worth adding the standard term used for "cursor pagination" in the technical literature, which to the best of my knowledge is "keyset pagination".
### On Access control
This section can be expanded a little, I'm not sure there's any FEP's that proposes this idea already, but it can be generally applied to _all_ local objects a service exposes.
The "SHOULD be filtered based on the permissions of a user" is pretty vague, so I'd clarify that the "user" is reconstituted based on whichever authorization mechanism the user-agent is using (OAuth2, HTTP-Signatures, or something else) and which contains a valid Actor ID. (Eg, in the case of HTTP Signatures, we retrieve the Public Key and consider its `Owner` as the **authorized user**)
If that's not possible, only Public addressed content is returned.
Secondly, I think the method of building the access control list could be detailed.
In GoActivityPub I'm using all the recipient fields (To, CC, Bto, BCC), so including the blind ones, to build the list of Actor IDs that then get checked against the authorized user from above. Also the "Audience" property can be used.
And a last thing that I'm doing in GoActivityPub, is that there's two levels of access control checks for collections:
1. The collection object itself needs to be accessible to the authorized user.
2. The individual items in the items/orderedItems list get filtered separately based on their own recipients ACL against the same authorized user.
___
In conclusion, I'm not sure if all these ideas are valid to be used on a larger scale, but some feel "common sense" enough that they might be generally applicable.