Is there a way to detect AP s2s compatibility?

Is there anything in the spec about a way for a server to broadcast that it has some kind of ActivityPub compatibility? I skimmed over the spec just now and couldn’t find anything but maybe I’m just reading poorly.

I’m looking for something where: given a host name like arbitrary.example.social, something like a .well-known I can ping to see if they have any AP compatibility at all. Right now I’m checking api/v1/instance which a lot of implementations support, but I wanted to see if there’s some kind of top-level Actor that an s2s implementation should have.

I was hoping for ServiceInfo to be something people would be interested in. It was meant to be JSON-LD documents that could highlight for example different features supported by an AP server, among other things. Unfortunately didn’t see much interest in it so haven’t been working on it.

Personally I would like something that is flexible and extensible, just like AP, but not just for AP, since the federated web is much larger.

No, there’s no standard for discovering ActivityPub and it doesn’t really make sense because of the way ActivityPub works. What you’re basically saying is that you want to be able to discover arbitrary Actor id. This is basically like asking to discover all valid URLs on a website – short of an enumeration attack or plain guessing, you would need the equivalent of a sitemap. This is why Webfinger has been used in most existing implementations, as it allows for exactly that kind of URL discovery based on some other piece of information (that information being an acct: URI in the form of username@domain).

1 Like

Another way of looking at this is that ActivityPub, as a protocol, doesn’t say anything about servers. There’s no concept of a server in the protocol, and it would be additional complexity that may not make sense for all implementations. For example, one server might serve as the host for many domain names, or one domain name might host actors from many different server implementations, by use of a reverse proxy. How would a global server actor for a domain name handle these cases?

I’m personally a little suspicious of “fediverse-wide” stat collection efforts, as they often feel a little self-congratulatory, and sometimes border on intrusive (when someone’s private, personal instance is listed publicly because they happen to reply to some thread or follow somebody’s who’s following list got scraped)

1 Like

For my implementation, I decided to add custom keys to my NodeInfo. Though I’m not using this myself (yet) because being able to correctly federate with other implementations is a higher priority for me than supporting my own features across instances.

1 Like