Are all activity ids expected to be resolvable?

I’ve been trying to add the ActivityPub protocol to my content management website following this tutorial (How to implement a basic ActivityPub server - Official Mastodon Blog) After finding some answers in this forum about adding the digest header, I’ve hit a dead end with getting 202 responses from my Follow request. At this point through debugging, I’ve narrowed down the issue to the IDs.

Which leads me to my actual question. I saw some discussion on the potential issue being that all URIs need to be real reachable resources on the internet. So do we need to keep a copy of all actions that get sent out and make them resolvable? Follows, Accepts, Creates, Accounces, etc? The tutorial said

For our purposes, we don’t actually need to host this document publicly, although ideally both the activity and the object would be separately available under their respective id

I was hoping to get clarification on that. Thank you.

Theoretically, yes. From the spec:

3.1 … Publicly dereferencable URIs, such as HTTPS URIs, with their authority belonging to that of their originating server. (Publicly facing content SHOULD use HTTPS URIs).
3.2 … The HTTP GET method may be dereferenced against an object’s id property to retrieve the activity. Servers…MUST present the ActivityStreams object representation in response to application/ld+json; profile="https://www.w3.org/ns/activitystreams"

In practice, though, many implementions don’t fully satisfy this, eg Mastodon’s Follow, Delete, and Undo activities:

(Granted, fragments generally aren’t expected to be sent to HTTP servers, and the Delete and Undo behavior above is the same without those fragments, so Mastodon’s HTTP server may be stripping the fragments early in the process.)

Some types of objects generally do need to be fetchable, eg actors, objects of Announces, etc. You can search your server logs for your ids to see if any other instances are trying to fetch them. Generally though, if you’re delivering an activity to a remote inbox, that instance will verify it by its signature, not by refetching its id. If you’re getting a 202 but your activity doesn’t seem to be happening, signature verification is often the problem.

1 Like

Thanks for the insight. I was debating on attempting to store and serve every single activity but maybe i’ll keep debugging it. My signature seems to pass because I get 202, when i screw up the signature, I correctly get a 401

this should only be done for activities that are public. private activities may be dereferenceable if signatures are provided, or perhaps not at all (it depends on which authentication/authorization mechanisms you support, and activitypub does not specify a mechanism – it just recommends using one.)

generally you do not have to dereference activities, and you probably don’t have to dereference most objects either – the payload delivered to your inbox typically contains all the information you need. however, it is certainly possible for a project to not inline an object and to instead reference it by its iri, at which point you will probably end up having to fetch it.