Currently /users/{id} and other endpoints return ActivityStreams object only when first mime type in Accept header of the request is set to application/activity+json.
However, according to ActivityPub spec objects must be retrieved with an Accept header of application/ld+json; profile="https://www.w3.org/ns/activitystreams":
POST requests (eg. to the inbox) MUST be made with a Content-Type of application/ld+json; profile="https://www.w3.org/ns/activitystreams" and GET requests (see also 3.2 Retrieving objects) with an Accept header of application/ld+json; profile="https://www.w3.org/ns/activitystreams". Servers SHOULD interpret a Content-Type or Accept header of application/activity+json as equivalent to application/ld+json; profile="https://www.w3.org/ns/activitystreams" for server-to-server interactions.
This means BirdsiteLIVE is not compatible with spec-compliant servers. I think application/ld+json; profile="https://www.w3.org/ns/activitystreams" type should be supported too, in addition to application/activity+json.
Currently
/users/{id}
and other endpoints return ActivityStreams object only when first mime type inAccept
header of the request is set toapplication/activity+json
.However, according to ActivityPub spec objects must be retrieved with an
Accept
header ofapplication/ld+json; profile="https://www.w3.org/ns/activitystreams"
:-- https://www.w3.org/TR/activitypub/#server-to-server-interactions
This means BirdsiteLIVE is not compatible with spec-compliant servers. I think
application/ld+json; profile="https://www.w3.org/ns/activitystreams"
type should be supported too, in addition toapplication/activity+json
.