Based on feedback in the thread, I’m considering changing all occurrences of “instance” with “server” in FEP-ceee to more closely-align with ActivityPub Rec terminology. The definition will remain the same. Any comments before I do that?
This changes the title of the FEP which will change the title hash and require renaming of related discussion threads and tracking issues.
+1 for “server”
I think “instance” is more appropriate when talking about an installation of software.
I’ll wait a day or so before changing the FEP in case there are other opinions.
That’s one of several ways I’ve seen “instance” used. Unfortunately, “installation” is as ambiguous and vague as “instance”. Also, in some contexts, “instance” and “server” are used as synonyms.
This GitHub user with the username, silverpill 
, wrote in a NodeInfo issue:
NodeInfo 2.2 defines “instance” as “a concrete installation of a software running on a server”.
This may be confusing because people often use “instance” and “server” interchangeably.
Unfortunately, “server” is as ambiguous as “instance”. If the FEP definition is reasonably precise, then the specific word is less of a concern for me if it corresponds to at least one of the common usages.
Sometimes “server” is used to mean the hardware platform that’s running the software (including virtual hardware) . That seems to be the meaning in the NodeInfo definition of “instance” (“running on a server”). Other times, it’s the process or group of processes executing the software.
In the Wikipedia article about the Fediverse, they appear to say “server” and “instance” are the same (it’s not clear to me if they are using both hardware and software definitions of “server” in the same sentence).
While a traditional social networking site will host all its content on servers owned by the parent company, the decentralized social media sites that make up the fediverse allow any individual or organization to host their own servers (referred to as an “instance”).
In any case, I’m fine with “server” (to replace “instance”, as defined in the FEP) since the term is not as Mastodon-related and the word is frequently used in the AP Rec.
I’ve submitted a PR to change the use “instance” to “server” in the FEP (including the title, which requires a new FEP identifier). I also added a section to discuss several current or potential uses cases for server-level actors.
I assume that when the PR is merged, the related discussion topic and issue titles will also be changed to the new FEP identifier.
@stevebate I’m going to implement instance actor discovery using WebFinger. However, I want to stick with Mastodon’s link format where rel value is self. Is it considered valid according to FEP-d556?
The reason for using self is twofold. Web origin lookup is used for “remote interaction” mechanism and I’d rather follow de-facto standard (Mastodon behavior) to avoid any issues. Also, in my software server actor has type Application (it represents an HTTP client), so https://www.w3.org/ns/activitystreams#Service feels inappropriate.
I’m traveling right now, but if IIRC, the Service rel was used instead of self because someone was concerned about a single user server with a user actor and an server actor, each with a JRD link served for the server endpoint resource. When I have a moment, I could investigate adding some text to discuss using self for the server actor when there’s no clash with a user actor. I think it should be ok.
I submitted an FEP PR related to your question.
Thank you! Here’s my implementation of FEP-d556: https://mitra.social/.well-known/webfinger?resource=https://mitra.social
I think it would help future implementers if you specify requirements using RFC-2119 words. Also, consider adding a definition of the “server prefix”. Should it include the trailing slash? Probably not, because that slash belongs to the path component of an URI, whereas you define server as “origin”, which only includes scheme, host and port.
I intentionally didn’t use RFC-2119 words, because I don’t consider this a formal requirements document. I think we overuse that RFC in some places. However, I’ll reconsider that.
I’ll review the definition of server prefix. I agree it probably should not include a trailing slash.
This would be really useful for addressing activities to the moderation team responsible for a server. Right now that’s something that can’t be done.
However, the FEP showed the example of a moderation actor link as:
{
"rel": "https://www.w3.org/ns/activitystreams#Service",
"type": "application/activity+json",
"href": "https://server.example/moderation-actor",
"properties": {
"https://www.w3.org/ns/activitystreams#relationship": "moderation"
}
},
When really I think this would be a Group Actor.
{
"rel": "https://www.w3.org/ns/activitystreams#Group",
"type": "application/activity+json",
"href": "https://server.example/moderation-actor",
"properties": {
"https://www.w3.org/ns/activitystreams#relationship": "moderation"
}
},
(it also duplicates the actor href in that example)
Ref: Moderation Group Actor · Issue #24 · swicg/activitypub-trust-and-safety · GitHub
the bigger problem is not whether the actor is of type Service or Group, the bigger problem is that the link relation is nonsensical, and the use of as:relationship as a property also doesn’t make sense.
if your goal is to address activities to the moderation team, then i don’t think you need this FEP at all. either define something like a moderationInbox endpoint in endpoints, or signal that the actor is being managed in some other way – perhaps via attributedTo or generator, or some extension property that specifically means “this is the host that is responsible for the object”.
The rel URI is not specifying the AS type of the actor. That’s defined in the actor resource. It’s defining the type of relationship. In this case, the actors are providing server-level services.
As stated prior to the examples…
The type of the Server-level Actor itself is not required to be the same as the relation type.
The actor can be any type.
These are server-level service relationships. An actor can provide multiple services. In this example, the same actor is providing administration and moderation services. However, I don’t mind changing the actor URIs to be different and add more text about the case I just described.
The type of the actor is unrelated to the relationship type (see my response to @thisismissem ). That misunderstanding may why you think it’s nonsensical? I don’t know, since you didn’t provide any rationale for the claim. The as:relationship property is shown as an example of using properties to disambiguate services. Those property keys can be any URI. It could be a urn:uuid:... if everyone agreed on the meaning of it.
I’m looking forward to seeing the details in an alternate FEP, but there are several potential issues with this approach. First, the endpoints property is actor-level. This FEP is providing metadata about server-level services. If someone wants to know the moderation actor/endpoint for a server, your proposal requires that they dereference some actor somehow and hope that their specific moderation inbox is the one that supports server-level moderation (not necessarily true since it could be an actor-specific endpoint). The other issue is that unlike the sharedInbox endpoint, which is not an inbox for any specific actor (or any actor at all), this activity is about services provided by specific server-level actors. Those actor resources potentially have other useful information and service metadata. For example, if they are a Group, it may reference the member actors.
In general, there is no way to “follow your nose” from an inbox endpoint to an actor. (It is theoretically possible if the inbox endpoint is actually the URI of an inbox OrderedCollection and there’s a attributedTo property on the collection, but this is not the way most inbox endpoints in the Fediverse are implemented and the AP Rec doesn’t require it.)
Also, moderation is just a specific example of a server-level service supported by the FEP. There are many other possible types of services. The moderationInbox (and other properties) are a specific suggestion for a specific use care (less general than what’s proposed in this FEP).
My apologies, I was a bit checked out while making that post and neglected to justify that claim.
The reason I say that the rel is “nonsensical” is that the term being used is not a link relation, it is a class. I know that the intention is to (re)define it as “providing server-level services”, but that’s not what the term identified by that IRI means. It would be best to define an actual link relation with a clear and unambiguous meaning, and then use that.
The other part of this is that “providing server-level services” is pretty vague at best and doesn’t actually indicate the purpose of the linked resource. Rather than having two links with the same relation but disambiguated by some property, just define a different relationship. (In that light, it’s pretty ironic that as:relationship was used in properties when that should have been a clear indicator that it should be a relationship instead.) The semantics being captured here are that resource A, the subject, “is being moderated by” or “has a moderation actor” resource B, the href. This would best be expressed as rel=…/moderation or rel=…/moderatedBy or whatever you want to call it.
I’ve held the general critique for a while that this whole “trying to discover a server-level actor” that has been the subject of several FEPs, well… it needs more time in the oven. What is the true purpose of discovering such an actor? Because simply saying that it’s an “instance actor” or “service actor” or “application actor” or “server-level actor” doesn’t actually communicate a purpose. Mastodon might provision an actor that is not attached to a user or account, and it might use that actor to proxy signed fetches, but why would this actor need to be discovered? It’s just doing fetches. The only time you’d be discovering it is when you get a signed fetch and the keyId is controlled by that proxy actor. Pleroma provisions two actors – an internal.fetch actor, and an internal.relay actor. If you want to discover the latter, it would be helpful to know that it is a “relay” specifically.
Basically, what I’m trying to say is that before formalizing a way to discover such actors, we need to formalize a definition for these actors. To wit:
I’m not disagreeing with this, but trying to discover such actors before defining such metadata is putting the cart before the horse.
This is actually weirdness on part of the AP spec, but the endpoints are generally expected to be shared server-wide: ActivityPub
A json object which maps additional (typically server/domain-wide) endpoints which may be useful either for this actor or someone referencing this actor. This mapping may be nested inside the actor document as the value or may be a link to a JSON-LD document with these properties.
This came up in a GitHub issue quite a while back about whether the endpoints are indeed “actor-wide” or not, and the conclusion seems to be that they actually are not. They are controlled by the server (so the actor can’t Update themselves and modify or remove the endpoints). There was some consideration about whether the endpoints property should be @type: @id (indicating that it is a resource), or if it should be @id: @nest (indicating that the property should be unpacked, and that inner properties are actually properties of the parent resource). The more correct conclusion of the two is that it is @type: @id and refers to a resource, specifically one that is under the control of the server. It’s just that the resource MAY be embedded as an anonymous or “blank node” with no id of its own.
The URI is a “class” (type) in AS2, but not here. However, I understand how this can cause confusion. I’m not opposed to a different default rel URI although I’d prefer to not mint a new one.
The FEP was originally proposed as an alternative to FEP-2267 which uses https://www.w3.org/ns/activitystreams#Application as the relation type and leaves many other details relatively unspecified compared to this FEP. However, some AP server implementations have already implemented some interpretation of FEP-2677.
It’s “vague”, as in, abstract. The FEP is not intended to define domain-specific services details. The key concept is that these are server-level resources versus user-level actor resources.
To be clear, the as:relationship property is an example. Any properties could be used to disambiguate the Service resource relationships. Domain-specific relationship URIs at the link level could be used too, but then one loses the ability to ask for all the services provided by a server. Of course, that could be addressed by adding an rdf:type property of as:Service in the properties.
Also the FEP states (could be worded better):
… an implementation could have different server-level actors that serve different purposes. It’s also possible that another FEP will define standard
relURIs for common roles. In that case, [those] FEP roles should be preferred …
I disagree that one cannot define an abstract discovery framework without knowing all the possible metadata for anything that might be discovered. For example, the WebFinger protocol itself is this type of abstract framework that supports resource discovery (and other use cases) without specifying the metadata for all possible discovered resources.
I agree. But “typically server/domain-wide” means it’s ambiguous whether endpoints are actor or server level or some other scope (like Group-scoped sharedInbox endpoints for actors in those groups). I don’t see any conclusions described in the GH issue you referenced. I think this is one of those, unfortunately common, AP/AS2 cases where it is “whatever you want it to be”.
You mention “blank nodes”, but that’s only relevant in a JSON-LD/RDF context which doesn’t apply here. Evan has said there’s no other data model for AP JSON than the document itself (specifically, there’s no RDF data model). Given that information, a reasonable interpretation is that endpoints are actor-level data (since they are objects embedded in the actor JSON documents) that might happen to have the same value for all actors hosted by a server. I have some interest in the endpoints topic in the context of defining C2S extensions, but that’s a topic for a different thread.
Can we use FEP-888d namespace to define link relations?
yeah, 888d lets you define whatever you want and provides some basic resolution for some rdf stuff (at the moment, this is just content negotiation for turtle, rdf/xml, and jsonld), but it doesn’t have to be rdf stuff. you can define link relations, and you can even link to arbitrary subresources like images or test cases or whatever you want – if none of the htaccess rules match anything, the last one will fall back to just returning the file at that location.
also conceptually there’s not much difference between a link relation and an object property. in both cases, the IRI describes the relation between the subject and the object, regardless of whether it’s used as a rel-value or as a predicate/property. for example:
<link rel="http://webfinger.net/rel/avatar" href="http://example.com/image.png" />
{
"http://webfinger.net/rel/avatar": "http://example.com/image.png"
}
the above two constructs are basically the same thing semantically, just using different mechanisms. you could do something like this instead:
"_links": {
"type": "Link",
"rel": "http://webfinger.net/rel/avatar",
"href": "http://example.com/image.png"
}
but in most cases it actually makes a lot of sense to just translate the rel directly into a property key.
If someone wants to write an FEP to define domain-specific rel URIs using fep-888d or something else, that would be great. @thisismissem? I’d prefer that the people associated with those domains (like moderation) do that, since I don’t have much experience with the topic. I can update d556 to state that other link rels (besides as:Service and “self”) can be used if the rel is well-defined (preferably in an FEP). Like @trwnh has said, this would reduce the need to use link properties for disambiguation. It would also make the link semantics more meaningful and would reduce the need to dereference the service to get metadata to determine the purpose of the service.
The domain-specific URIs could be defined in d556, but I think it makes sense for them to be specified separately. There may be alternative proposals for a domain’s link rel URIs, for example. There might also be domain-specific requirements related to the object of a WebFinger link (like requirements for specific types of a linked actor or requirements for extended properties).
oooh, okay, thanks for explaining that @stevebate
So I don’t really mind whether it’s a moderationInbox or a server-wide discoverable Moderation group actors. All we need for better moderation is some mechanism to address activities to the moderation team, because currently we have nothing of the sort.