An instance is what is accessible via a domain. e.g. https://mastodon.social. regardless of scaling, operating system process, etc.
Introducing an “instance actor” for properties of an instance feels good to me. A bit like “eat your own dog food”.
if it has been specified what an “instance actor” is and what it can do, then the “single actor” of an instance can be the “instance actor” as soon as it fulfills the requirements of an "instance actor
I Agree!
I mostly agree, if you add the protocol and port to that definition. The definition of “origin” used for “same origin policies” could be a good guideline, but there are probably other possibilities.
I don’t know how that idiom applies here, but I prefer the principle of low coupling. One shouldn’t need to implement an “instance actor” to provide instance metadata. That said, I don’t think that was the primary purpose of this FEP, but it was mentioned as a potential use of instance actors so I suppose it’s relevant to discuss it in that context.
There are two requirements listed in the FEP for an “instance actor” (AKA application actor). The actor resource can be retrieved without authentication. Many servers implement that behavior for all actors so that’s not a problem (although it’s also doesn’t help much to define how an “instance actor” is different from other actors). The other requirement is that it has an Application type. I think many single actor instances are going to be Person actor types, so changing that to Application to also qualify as an instance actor is not going to be desirable. AP does technically allow both Person and Application to be specified as an actor type, but I suspect there would be interop problems with that approach.
The type of instance actor should not play a role. I see no reason to restrict this in the FEP.
I want to. It’s a simple as that. FEP is not a consensus driven process, what the author wants rules supreme.
Anyway, I added a fediverse feature for this fep:
A Fediverse Enhancement Proposal (FEP) is a document that provides information to the Fediverse community. The goal of a FEP is to improve interoperability and well-being of diverse services, applications and communities that form the Fediverse.
This sounds a bit contradictory to me.
FEP-2677 was implemented in Mobilizon: feat(activitypub): implement FEP-2677 to identify the application actor used for federation (!1507) · Merge requests · Framasoft / Mobilizon · GitLab
Perhaps it’s time to add “Implementations” section?
In a way, that’s unfortunate. On one hand, I have concerns about nodeinfo becoming required for federation when webfinger is already required. On the other, since “Application Actor” is not a well-defined concept, they and the extended nodeinfo support probably won’t become a general federation requirement and instead be an implementation-specific consideration.
I still believe we should have defined Application Actor better (requirements, behaviors, recommended practices) before, or in addition to, defining a discovery mechanism for a poorly-defined concept.
There has been some discussion about the definitions of Application and Service types in the SocialCG and guidance has been added to the AS2 primers. Of note is the guidance to Service instead of Application for server-level (or instance-level) actors and primarily use Application to represent client software (although the bot examples don’t seem consistent with this guidance).
If the SocialCG wants to hasten people forking the ActivityPub specification, this is exactly the type of move that leads to it. I’ll be refraining on further comments on their actions again for some time.
To clarify, the ActivityPub specification doesn’t refer to either Application or Service. This is an Activity Streams 2.0 topic although the primer discusses the implementation-specific use of those actor types in a server context (which may or may not be an AP server).
I agree that proposed definitions are not ideal. My suggestion: Clarify the definitions of Application and Service types · Issue #563 · w3c/activitystreams · GitHub
Application = any software application, server or client
Service = bot account (something that behaves like a Person, but automated)
The FEP could side-step the issue by removing the requirement for the “Application Actor” to have an AS2 Application type. Instead, whatever actor is identified by the NodeInfo https://www.w3.org/ns/activitystreams#Application relation is the application actor, regardless of type (subject to AP inbox/outbox and other requirements, of course).
Until the W3C releases the next Candidate Recommendation, I will not make any changes to the FEP due to their discussions.
I’ve opened a PR for Mastodon to implement this FEP here, but the decision will be with the Mastodon core team: Implement FEP-2677 allowing discovery of the instance application actor by ThisIsMissEm · Pull Request #28584 · mastodon/mastodon · GitHub
As an aside, I would like to see the webfinger of the instance’s own URL result in the appropriate response linking to the instance actor be standardised. e.g.,
https://mastodon.social/.well-known/webfinger?resource=https://mastodon.social/
On Mastodon, it seems to give the Instance Actor as I’d expect. However, I don’t believe this is currently standardised.
Interesting! I strongly prefer this approach since a Webfinger endpoint is already required for Mastodon federation and nodeinfo is not.
The problem with this is: What if I want to use https://mastodon.social as the URI of the main actor for my single user instance? So me. I will want requests to this actor to require using signed requests.
Using your proposed webfinger approach makes this impossible.
I’m assuming you don’t mean Mastodon literally here since the Webfinger resolution in that context would require an “acct:” URI for the user actor. However, for another server implementation, would the following work (ignoring Mastodon interop for the moment)?
https://server.example/.well-known/webfinger?resource=https://server.example/
returning…
{
"subject": "https://server.example/",
"links": [
{
"rel": "https://www.w3.org/ns/activitystreams#Application",
"type": "application/activity+json",
"href": "https://server.example/ApplicationActor"
},
{
"rel": "self",
"type": "application/activity+json",
"href": "https://server.example/"
}
]
}
That’s not compatible with Mastodon, so for interop one might also want to support:
https://server.example/.well-known/webfinger?resource=acct:user@server.example
returning…
{
"subject": "acct:user@server.example",
"links": [
{
"rel": "self",
"type": "application/activity+json",
"href": "https://server.example/"
}
]
}
There’s a different here though, between you as a Person, @helge, and the server operating as your server. This is something that comes up time and again in RDF contexts, like whilst both represent you, both are not “you”. Even Person is not “you” strictly speaking, it’s just a representation of you. (this gets into the whole weird world of representing data about something vs representing something in the physical world.