Collections that are modifiable by actors other than their owner

ActivityPub Server to Server
1

Continuing on my outbox questions, here’s the general construct I need: a collection that belongs to an actor that other actors can add objects to, with the owner having the ability to intervene. Examples:

  • Walls, again — both owned by users and groups
  • Photo albums in groups, where any member can upload a photo
  • Discussion boards in groups, where any member can create a topic

In all these cases, there needs to be the ability for the collection owner to refuse the activity/object to be added to the collection, for example due to their privacy settings — a user should be able to only allow their friends to post on their wall. The collection owner should also be able to arbitrarily delete objects from the collection, for spam prevention or moderation purposes, or, really, any reason because they own the thing.

What I suggest:

  • Adding an object to a collection is done by specifying the collection ID in its partOf field, and then sending it to the collection owner.
    • If the receiving server accepts the addition, it simply responds with 200 OK and stores the object in its database. It can then forward it to anyone it deems appropriate for the purpose of data consistency.
    • If it does not because that would violate owner’s privacy settings, it responds with 403 Unauthorized. The originating server may reflect that in its UI.
  • Deletion from the owner side is done by the owner sending a Delete with the original object ID as the object to the server that hosts the object being deleted, and optionally to any servers that it forwarded the object to earlier.

Is this okay?

2

Maybe Add and Accept would be more correct here?

A user could Add the object to the collection, and send that activity to the collection owner, which could then send Accept{Add} to any relevant inboxes

Another possible activity would be Offer, I’m not really sure what it’s for

3

I use it for friend requests in the form of Offer{Follow}

4

The way I see it, Offer is for when you want to suggest an Activity to be Accepted or Rejected by another actor. If the actor Accepts the Offer, that Activity can be published and its side effects can be processed. If not, then it won’t.

Offer{Follow} is one way to use Offer, sure. So would Offer{Create}, Offer{Add}, Offer{Delete}, etc.

5

By ActivityPub’s spec, Follow activities are already supposed to go through the Accept/Reject flow, so I would drop the Offer there (no implementation I know of uses Offer for follow requests, they use Follow as a request itself).

https://www.w3.org/TR/activitypub/#follow-activity-inbox

Using Offer to offer to Add to a wall/album etc. does sound like a good way to do that.