From FEP-ceee:
The Instance Actor’s URI will be the
hrefproperty of alinkwith arelproperty ofhttps://www.w3.org/ns/activitystreams#Service
So I’m extremely confused what ceee is trying to propose, if not that.
I’m mostly focused on the actor aspect, sure, but also the link relation aspect. For this thread, I’m not trying to talk specifics about 2677 or ceee, but rather, the general idea underpinning both – that there is one or more service-level actor(s) with some purpose, and that they need to be discovered in a standardized way.
To talk specifics about ceee (ironic, given what I just said): you suggest using Webfinger properties (while leaving any further details out-of-scope). Based on the example given, I think it would make more sense to swap the usage of properties with the usage of rel. For example, instead of properties.as:relationship = moderation and properties.as:relationship = administration, it makes more sense to use rel = moderation and rel = administration. This is similar to how XMPP Service Discovery works.
To talk specifics about 2677: conceptually, it 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.
I’ll be leaving the above two paragraphs as separate comments on each FEP’s dedicated thread, btw, so as to leave this thread focused on the issue of “what is a service-level actor” and “what is its purpose” and “why/how should it be discovered”. Per So, what even is an instance actor? - #7 by trwnh I am collecting use cases and characteristics to try to answer such questions.