i don’t think there’s a “current” way; what you’ve linked is simply the most recent proposal in a line of multiple proposals (and specifications).
your “entry point” for information in general is going to be one of the following:
/.well-known/host-meta defined in RFC 6415.
- Note that the RFC requires web host metadata to be served in
application/xrd+xml at least, although you may use the HTTP Accept header to content-negotiate for other formats, and requesting application/json or application/jrd+json is provided for in the RFC.
/.well-known/host-meta.json is also defined in the RFC as a way to skip content negotiation and always return the JRD.
/.well-known/nodeinfo defined in NodeInfo.
- Note that NodeInfo is largely focused on statistics, and its schema makes certain statistics required instead of optional.
/.well-known/webfinger defined in RFC 7033, although you need to specify a resource:
?resource=acct:domain.example@domain.example assumes that an acct URI (RFC 7565) whose userpart matches the host will always represent the host service.
- Compare with email (SMTP as defined in RFC 5321), where a localpart of
postmaster (case-insensitive) is special-cased and hard-coded to always go to the server itself.
- Note that the result might be an individual (as:Person), in the case of personal websites as is popular in the IndieWeb ecosystem (where the distinction between the website and the person might not be made).
?resource=https://domain.example assumes that the base domain always represents the service.
- Note that it is unclear whether
https://domain.example should be or is equivalent to https://domain.example/ in this processing context.
- Note that it is unclear that the root resource
/ should always refer to the website or host itself and not to something else, such as its homepage.
- HTTP
GET defined in RFC 9110, although the resource name to request is arbitrary, and you may need to follow some link relation or property path.
GET /
- Note that, as above with the WebFinger case where an https: URI is used, it is unclear that the root resource
/ should always refer to the website or host itself and not to something else, such as its homepage.
GET an actor, then check some link relation or property assumed to point to the host service:
https://www.w3.org/ns/activitystreams#generator, although this doesn’t always point to a “host service”, since the property is defined to point to a “generator” instead, like how an HTML document might use <meta name="generator" to specify some framework which generated the HTML document- You could define some “host” link relation or property whose definition is specified to point to “an entity hosting the current object”. The link target or property value would tell you where the host metadata is located.
https://www.w3.org/ns/ldp#inbox could be a better place to put such “capabilities”, since the idea of “capabilities” is more appropriately a property of the inbox and not a property of the service.
Personally, I dislike NodeInfo the most, as I do not think statistics should be required to be exposed, and I find it to be duplicative of the more general host-meta. However, I do recognize that the requirement to deal with XML is distasteful to a lot of developers, so full support for host-meta would not be popular. It is worth noting that host-meta actually used to widely supported in the OStatus days, as XML was already used for Atom feeds and even the precursor to WebFinger (LRDD, which behaved like WebFinger but also required XML while allowing JSON via content negotiation). These days, host-meta is still used around the web, but not so much in the fediverse. It might be feasible for the fediverse to have “partial support” by way of serving host-meta.json but not host-meta.
WebFinger is currently required to talk to Mastodon et al right now, but is also not strictly “necessary” if that’s not a consideration for you. Also note that Mastodon is exploring dropping the WebFinger requirement, so it might not be required forever.
I think the most straightforward approach is to use the actor’s identifier as a starting point, since you already have to fetch the actor for basically everything else. From there, I don’t think as:generator is the right path – while it is accurate to say that in many/most cases the actor’s “generator” is some host service, that doesn’t mean that “generator” and “host” are the same property or always necessarily equivalent properties. So I’d at least recommend defining a property for “host”:
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
@prefix as: <https://www.w3.org/ns/activitystreams#>.
_:host
rdfs:label "is hosted by";
rdfs:comment "Indicates that the current resource is subject to some authority";
rdfs:range _:Host.
# the following statements are debatable...
_:Host rdfs:subClassOf as:Service.
But I’d also recommend signaling the constraints on what kinds of messages an inbox can receive, and what it will do with them. In Linked Data Notifications, there is a concept of an inbox being “constrained by” (http://www.w3.org/ns/ldp#constrainedBy) something, perhaps a set of requirements or behaviors or some profile or specification or other. You could for example declare at minimum:
{
"id": "https://actor.example/",
"inbox": {
"id": "https://inbox.example/",
"http://www.w3.org/ns/ldp#constrainedBy": [
{"id": "https://constraints.example/"}
]
}
}
LDN recommends making these available in HTTP headers, so that you can do HEAD /inbox or similar, and obtain a Link whose rel is http://www.w3.org/ns/ldp#constrainedBy which might give more info.
There is one problem here that we are punting further down the road: what do any of these identifiers mean? How do we go from an identifier to knowing more about the constraints that are included within that thing? We have two options:
- Make definitions of constraints available out-of-band. For example, we might all agree that
https://docs.joinmastodon.org/spec/activitypub or https://w3id.org/fep/xxxx should dereference to a certain set of constraints about what that inbox can or cannot receive. (To some extent, this is how context documents are handled in later JSON-LD adjacent specs, like VC/DID/CID – you are not supposed to dereference the @context identifiers at runtime.)
- Make definitions of constraints available in-band. For example, doing an HTTP GET against an http: or https: name should return some information about what those constraints are. But in most cases, this is better treated as a convenience for obtaining definitions and you should really be doing option 1 here.
We might then provide more and more detailed information about the constraints, using appropriate formats. Maybe a SHACL shape graph could describe exactly what shape activities are supposed to have. Maybe certain shapes would trigger certain behaviors, and a vocabulary for behaviors could be devises or agreed upon. You can take a natural language statement like:
This inbox supports payloads where
the `type` includes `Like`,
and `actor` and `object` are present with at least one value.
and turn it into something like this:
@prefix sh: <http://www.w3.org/ns/shacl#>.
@prefix as: <https://www.w3.org/ns/activitystreams#>.
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
_:LikeShape
sh:property
_:LikesMustHaveTypeOfLike,
_:LikesMustHaveRequiredProperties.
_:LikesMustHaveTypeOfLike
sh:path rdf:type;
sh:hasValue as:Like.
_:LikesMustHaveRequiredProperties
sh:name "Required properties for Like activities";
sh:description "Like activities must have at least one actor and one object";
sh:path
as:actor,
as:object;
sh:minCount 1.
or vice-versa, as it may be hardcoded into the processor’s logic. The granularity can be as simple as just an identifier, or it can be as detailed as providing the same information in both HTML natural language documentation as well as one or more RDF formats bearing a shape graph. The important thing is that everyone understands the same terms to mean the same things – for example, there should be no dispute about what https://www.w3.org/TR/activitypub includes in its constraints. If your inbox says it is constrained by ActivityPub and some other actor takes this to mean they can send you a Listen or Arrive activity, and you can’t actually handle Listen or Arrive activities, then this is a miscommunication due to ambiguity. For this reason, I think defining bespoke constraint profiles in something like a FEP is probably a better approach.