Determining ActivityPub API support

[evanp]

"As an ActivityPub API client developer, I want to have a reliable way to tell if an actor supports the ActivityPub API, so I can set my client to read-only mode if not."

[evanp]

I think the current best practice is that the server returns a 405 Method Not Allowed. However, the only way to test this is to try posting an activity. If the api is allowed, the test activity will go through.

[evanp]

Is this a duplicate of #3?

[mediaformat]

the only way to test this is to try posting an activity. If the api is allowed, the test activity will go through.

You may find out sooner, for example post oauth flow, an apps first action may be to fetch the users actor, and follow up fetching the inbox.

Mastodon for example returns CORS

Access to fetch at https://example.social/users/fulano/inbox from origin https://example.app has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.

In another case, Pleroma has partial support: Not providing a proxyUrl endpoint, nor being able to fetch from the sharedInbox endpoint.

That said, as far as user experience goes, composing an Activity/Object and finding out that something is unsupported while trying to post it is pretty terrible.

I am very much in favour of a signal for which Activity/Object types and Extensions are (POST) supported.

[mediaformat]

For prior art FEP-9fde seeks to solves some of the same issues, albeit for Mastodon API compatible servers.

[silverpill]

For prior art FEP-9fde seeks to solves some of the same issues, albeit for Mastodon API compatible servers.

FEP-844e: Capability discovery proposes an alternative, ActivityPub-native discovery mechanism.

[evanp]

I realized today that an OPTIONS request is probably all we need to see if the outbox accepts POST requests.

[mediaformat]

It might be useful to know which Activity/Object Types and Extensions are supported.

[mediaformat]

Expanding on @evanp user story:

"As a client API developer I would like a reliable way to determine which Activities, Actor and Objects types are supported by the server."

Moved to #56

[trwnh]

Is this a duplicate of #3?

this is at least a subset of #3 if not an outright duplicate

I realized today that an OPTIONS request is probably all we need to see if the outbox accepts POST requests.

this is indeed the way to determine ahead-of-time whether POSTing activities is allowed. the same OPTIONS call can also include a WWW-Authenticate header for signaling the supported auth-scheme(s) and Accept-Post for which Content-Type format(s) are supported. also useful would be Link headers for rel="http://www.w3.org/ns/ldp#constrainedBy" and maybe rel="profile"

[trwnh]

the way to determine ahead-of-time whether POSTing activities is allowed

addendum: mark nottingham recommends HEAD with Link header and rel="describedby", for cacheability purposes.

https://www.mnot.net/blog/2012/10/29/NO_OPTIONS

this works well for cases where optimistic GET/POST has no real downsides, but is complicated by the fact that in linked data there might be cases where the thing and the description have the same URI. this is problematic for other reasons, but it's unclear whether the "description of the outbox" can be separated from "the outbox" cleanly... and whether it amounts to any functional difference, since the real issue imo is that http headers are a sort of "shadow content" compared to the actual body content. also imo, cacheability could be extended to apply to more than just GET/HEAD and some POST requests (perhaps on presence of freshness information?) -- OPTIONS seems perfectly cacheable to me, unless i'm overlooking something.

[TallTed]

Cacheability is a red herring. It doesn't apply to TLS sessions, i.e., HTTPS, that is, encryption over the wire, at all. HTTP can be cached, but we're long past that — see, for instance, "HTTPS Everywhere!"

In the simplest case, OPTIONS tells you what HTTP operations the server is capable of. In the most complicated case, it tells you what can operations the currently authenticated user can perform on the targeted resource. Again, not very cacheable, in most ways that might matter for cacheability to bring a benefit.

[trwnh]

the thing is, OPTIONS is also already used in LDN for the Accept-Post header, but the Accept-Post header in theory could be returned with a HEAD/GET as well?

OPTIONS /foo HTTP/1.1

HTTP/1.1 200 OK
Allow: GET, HEAD, OPTIONS, POST
Accept-Post: application/activity+json
WWW-Authenticate: Bearer
Link: <constraints>; rel="http://www.w3.org/ns/ldp#constrainedBy"
Link: <profile>; rel="profile"

HEAD /foo HTTP/1.1

HTTP/1.1 200 OK
Allow: GET, HEAD, OPTIONS, POST
Accept-Post: application/activity+json
WWW-Authenticate: Bearer
Link: <constraints>; rel="http://www.w3.org/ns/ldp#constrainedBy"
Link: <profile>; rel="profile"

conversely https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Methods/OPTIONS even has an example that includes a Cache-Control header in response to an OPTIONS request, despite OPTIONS supposedly being specified as "not cacheable"

OPTIONS / HTTP/2
Host: example.org
User-Agent: curl/8.7.1
Accept: */*

HTTP/1.1 204 No Content
Allow: OPTIONS, GET, HEAD, POST
Cache-Control: max-age=604800
Date: Thu, 13 Oct 2016 11:45:00 GMT
Server: EOS (lax004/2813)

[TallTed]

I haven't dug into the depths of this, but I can say that examples and other documentation are not always correct. I don't know that the example cited here is incorrect, but it would not surprise me. Please remember that mozilla.org is not the final authority on HTTP/S.