FEP-2677: Identifying the Application Actor

[thisismissem]

@stevebate

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/

@stevebate this does actually work with Mastodon:

Though there should probably be an alias in there for https://mastodon.social/ since that was the requested resource.

[thisismissem]

See also, the recent change to support acct:mastodon.social@mastodon.social as a webfinger resource: Add fallback redirection when getting a webfinger query `WEB_DOMAIN@WEB_DOMAIN` by ClearlyClaire · Pull Request #28592 · mastodon/mastodon · GitHub

[trwnh]

conceptually, this FEP seems to be largely proposing an alternative schema for NodeInfo. Which is to say, instead of NodeInfo 2.0 or 2.1 or the upcoming 2.2, you could instead get information about the network node (or service) via an AS2 document. Consequently, it might be worth considering using a rel-value of https://www.w3.org/ns/activitystreams rather than https://www.w3.org/ns/activitystreams#Application.

[helge]

@trwnh

conceptually, this FEP seems to be largely proposing an alternative schema for NodeInfo.

NO!!! How can one say this? This FEP does not change a schema. This FEP uses an existing schema, and adds an entry.

This FEP is simple to implement and easy to test, while being precise (that’s why the rel is #Application).

[trwnh]

The requirement of the current FEP is that the /.well-known/nodeinfo contains an additional link with relation type

if you’re using .well-known/nodeinfo then you would expect the rel value to follow a similar pattern to how nodeinfo 2.0, 2.1, etc schemas are declared on the other links, no? why specify the #Application fragment?

[helge]

Because I want to. Is it so hard to accept that a FEP author has opinions?

[stevebate]

NodeInfo uses JRD for the top level “index” document. The “protocol” appears to me to expect the JRD links to reference nodeinfo documents of various versions. It’s not clear from the informal protocol description if that’s the only types of links that are expected to be there. If so, adding non-nodeinfo JRD links is a clear misuse of the protocol.

If the nodeinfo protocol does officially allow arbitrary links in the JRD document, it is effectively equivalent to WebFinger with an implicit and fixed resource URI.

That said, there is some precedent for using nodeinfo to identify special actors. However, in the few cases I’ve seen so far, that information was specified in the metadata section of the nodeinfo document. If the FEP must use nodeinfo (I think the formally standardized WebFinger is a better choice), then I think the special actor information should be in the nodeinfo metadata since that’s more consistent with current practice. Although the metadata has no schema definition, it would be easy to define an FEP-specific JSON metadata schema that defines some standard special actor properties (one that allows any other properties for compatibility with existing nodeinfo documents). I believe this would be more consistent with the intended usage of the nodeinfo protocol.

[trwnh]

@stevebate

NodeInfo uses JRD for the top level “index” document. The “protocol” appears to me to expect the JRD links to reference nodeinfo documents of various versions. It’s not clear from the informal protocol description if that’s the only types of links that are expected to be there. If so, adding non-nodeinfo JRD links is a clear misuse of the protocol.

Per nodeinfo/PROTOCOL.md at 72c25eea1cb5995740080c0c0e5eb5abf488a4b1 · jhass/nodeinfo · GitHub –

The term “server” in this document refers to software providing metadata about itself on a host.

• (This IMO makes NodeInfo redundant with host-meta, at least in use case)

Servers must provide the well-known path /.well-known/nodeinfo and provide a JRD document referencing the supported documents via Link elements.

• Still feels like host-meta.json does the same thing. I imagine that

Currently the following relations are known: [listing various schemas for NodeInfo versions]

Discovery for media types other than application/json is left unspecified.

And perhaps most notably –

A server may provide additional representations.

• So it seems like you could use a rel-value which indicates some other relation. not just NodeInfo schemas. This means that the rel-value could be AS2-related to indicate an AS2 representation of the node. Maybe even #actor if the intent is that the AS2 representation MUST be an actor. Or whatever your preference is, depending on intended semantics.

---

@stevebate

If the FEP must use nodeinfo (I think the formally standardized WebFinger is a better choice), then I think the special actor information should be in the nodeinfo metadata since that’s more consistent with current practice.

There’s basically three different options, maybe four:

• NodeInfo top-level link
  • NodeInfo metadata
• Web Host Metadata (host-meta and host-meta.json, as defined in RFC 6415)
• WebFinger (RFC 7033) query for some resource (the host?)

Personally my preference is host metadata, since it doesn’t actually require the information that NodeInfo requires. (Detailed criticisms of NodeInfo are out-of-scope for this thread, but suffice to say that /.well-known/nodeinfo and /.well-known/host-meta.json are largely equivalent, and the host-meta could just as easily include the nodeinfo rel-values on links.)

[stevebate]

Do you know of an example of an AP Fediverse server implementation that uses host-meta for anything other than providing a link to WebFinger? There may be one, but I haven’t seen it. Of the three possibilities we’ve discussed, host-meta would be at the bottom of the preference list for me. As I’ve said before, using NodeInfo for “application actor” discovery adds an additional service requirement for AP Fediverse federation (based on the unauthorized fetch use case described in the FEP). WebFinger is already required and can support this use case (including providing links to nodeinfo resources, but I’m not necessarily recommending that using that way).

[trwnh]

@stevebate

Of the three possibilities we’ve discussed, host-meta would be at the bottom of the preference list for me. As I’ve said before, using NodeInfo for “application actor” discovery adds an additional service requirement for AP Fediverse federation (based on the unauthorized fetch use case described in the FEP). WebFinger is already required and can support this use case

Anything that requires discovery about the host will indeed add an additional service requirement. Webfinger does at least have other uses, sure, but you need to define a “host resource” and then query it. I think it’s fine to use host-meta because if there’s ever a situation where host-meta is required for federation, then this indicates that the concept of a “host” is required for federation. I remain unconvinced that having metadata about the host is required at this point, hence the other thread trying to establish use-cases and characteristics. If a compelling requirement is found, then FEPs like this one or similar will play a larger role.

As you expressed:

@stevebate

[Putting host metadata on the “instance actor”] would require any implementation that wants to provide metadata (about FEP support, for example) to have an instance-level actor with additional inbox/outbox and other actor-related requirements. It seems like an unnecessary coupling of independent features.

@stevebate

WebFinger can provide metadata for any resource. The Mastodon -iverse uses it with an “acct:*” URI to convert account names to actor URIs, but for instance actors I think it makes more sense to treat the instance itself as a resource and the instance-level actor link as metadata for that instance.

host-meta is the service-level equivalent of WebFinger, i.e., it doesn’t require defining a “host resource”. (I suppose NodeInfo can work for providing host metadata as well, but frankly the NodeInfo well-known endpoint doesn’t really need to exist.)

[stevebate]

@trwnh

Anything that requires discovery about the host will indeed add an additional service requirement.

Sorry. I should have used different phrasing. In other words, it will require an additional service for federation. This will require studying, understanding and implementing an additional specification.

[MediaFormat]

I think the webfinger option makes the most sense in terms of reusing existing “infrastructure” however the concept of an instance actor, in my mind shouldn’t be so user-facing (isn’t the goal only machine to machine type activities), and in this way seems more akin to what we would find in node-info.

[Johann150]

I would like to +1 what @stevebate and others already said: In the current way of how the fediverse works, using Webfinger is pretty much mandatory. It is also specified suitable for resolving any kind of URI if I’m not mistaken. Since multiple people came up with the idea of using the base URL of the instance as the webfinger resource, it seem to me to be quite a straightforward (canonical?) solution. The fact that this way is already implemented in Mastodon adds to that opinion.

@helge

This FEP is simple to implement and easy to test, while being precise (that’s why the rel is #Application).

Since hosting webfinger is already a requirement, adding separate path should be quite simple. On the other hand, as mentioned by others, nodeinfo is not an interoperability requirement so I don’t quite understand why you categorically say that it categorically simple to implement.

@helge

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?

If the understanding of “single user instance” as mentioned elsewhere in this thread is “the instance implementations technical capability limits it to serving and handling only a single actor object” then there can never be another actor, therefore I would say the only actor that is there must be the application/instance actor. Wouldn’t the only issue then be the self-imposed requirement for it to be an Application type actor?

And to be clear, my idea is not to have all the info as a result of webfingering the instance URL. The Webfinger of the root URL would also just lead to the instance actor, after that I guess there shouldn’t be a problem with continuing like the rest of the FEP. Maybe it could even be an alternative, but that would complicate consuming implementations of course.

---

On the process itself, I find it very strange that you on the one hand demand respect and full acceptance for your opinion as the author of the FEP while also talking badly of the SocialCG for doing the same kind of thing.

@helge

NO!!! How can one say this?

@helge

Because I want to.