FEP-0391: Special collection proofs


This is a discussion thread for the proposed FEP-0391: Special collection proofs.
Please use this thread to discuss the proposed FEP and any potential problems
or improvements that can be addressed.


Some properties represent special collections, such as:

  • outbox ([ActivityPub][AP])
  • inbox ([ActivityPub][AP])
  • followers ([ActivityPub][AP])
  • following ([ActivityPub][AP])
  • liked ([ActivityPub][AP])
  • likes ([ActivityPub][AP])
  • shares ([ActivityPub][AP])
  • replies (FEP-7458)
  • context (FEP-7888)

Verifying that any given object is part of a special collection is usually only possible by resolving that collection and checking its items one-by-one until the current object is found. This can be inefficient to verify. It would be easier if there was an inverse claim for each claim made about an object being part of a special collection. This FEP aims to define some properties that can be used to make those inverse claims.

cc @Claire @erincandescent @jenniferplusplus @dumspterqueer and i guess everyone else who was involved in the discussion for FEP-5624: FEP-5624: Per-object reply control policies

This FEP is mostly the synthesis of what was discussed there. The only thing missing currently is signalling properties, like whether the object/actor supports generating stamps, whether they automatically or manually grant stamps, hinting who might be approved ahead of time, and so on. I’m also considering whether or not to add explicit “stamp types” like ApproveReply, ApproveLike, and so on; it may or may not be appropriate, given that the current state of this FEP is focused more around verification and validation rather than “approval”. Nonetheless, the current mechanism for detecting a “stamp” is to check if it’s an Add activity and it’s attributedTo another activity. (It may be enough to simply check for attributedTo presence on the Add, or otherwise check if actor == attributedTo. I leave this up to implementers and to the discussion.)

Quick summary:

  • When an activity that has a side effect of adding something to a special collection is received, you respond with an Add that is attributedTo the activity with the side effect.
  • When you receive an activity that is attributedTo one of your activities, you Update your activity to include the received activity as the result of your activity.
    • If your activity was a Create, then:
      • if the target of the stamp was context, then Update the object to add a contextProof.
      • if the target of the stamp was inReplyTo.replies, then Update the object to add an inReplyToProof.
1 Like

Verifying presence in outbox

Activity <A>'s actor (<A>.actor) is actor <B>
Inverse claim
Actor <B>'s outbox collection (<B>.outbox) contains activity <A>

This is not particularly useful to prove.

This would be useful for verifying the attribution of the activity to the actor (https://github.com/w3c/activitypub/issues/432#issuecomment-2015521544), because <A> as:actor <B> . does not necessarily imply <B> as:outbox/as:items/rdf:rest*/rdf:first <A> . and it is possible that activity <B> is making a false claim in order to impersonate actor <A>.

activities are generally verified by either fetching the activity directly or by deferring to the http signature at time of delivery or by using an embedded ld signature/proof. therefore proving an activity is in the outbox/inbox is not very useful; you usually only care about the activity itself, and the outbox is just a discovery endpoint.

one exception i can think of (requires further thought) is using the “stamp” behavior to signal successful delivery, but this risks an infinite loop and also isn’t really a “side effect” of an activity. it’s a side effect of POST to outbox/inbox. so it shouldn’t generate a stamp.

The resulting stamp activity SHOULD be attributedTo the activity that caused the side-effect

It would be better to use another property (e.g. resultOf).

I know that definition of attributedTo property says this is possible, but still, in practice attributedTo is used to specify who owns an object.

The concept of ownership probably deserves its own FEP. For example when a Note is fetched, the client should verify attributedTo to avoid impersonation (by doing the same origin check or by comparing the value of attributedTo with proof.verificationMethod) . As far as I know, this is not described anywhere.

One point of distinction is that this is “attributedTo” on an activity. The ownership is already determined by “actor” property.

The meaning of the property shouldn’t depend on the object type. “attributed to the completion of another activity” is very different from “attributed to the actor”.
Also, how we can determine that given object is an activity? Currently one can’t rely solely on the actor property because some implementations add it to Note objects too (Pleroma). The only reliable way I have found is "has(actor) and not has(attributedTo)".

The domain of actor is explicitly marked as Activity so that would be a bug in Pleroma

EDIT: Stop putting `actor` on non-Activity objects (#3269) · Issues · Pleroma / pleroma · GitLab

EDIT 2: #770 - Stop putting `actor` on non-Activity objects - AkkomaGang/akkoma - Akkoma Development


has(actor) AND ( has(object) OR has(target) ) would work in practice but not in theory (as it would leave out IntransitiveActivity that has neither object nor target, e.g. Question, but Question is treated like an Object anyway so this is kind of a moot point)

1 Like

Well, in an RDF Schema sense IIUC, using a property with a domain of class Activity entails that the subject is of the Activity class. In other words, that means Pleroma’s behavior is semantically equivalent to stating "type": ["Note", "Activity"], which doesn’t make much sense.

(Of course, this is a quite pedantic argument.)

@silverpill Pleroma merged their MR to stop putting actor on objects. I’m not sure if they put attributedTo on their activities, but they shouldn’t / don’t need to do that. Do you know if this is the case?

@trwnh No, I’ve never seen attributedTo in activities.

(btw, the merged commit might have unintended side effects: Stop putting `actor` on non-Activity objects (#3269) · Issues · Pleroma / pleroma · GitLab)