@julian in your webfinger controller for nodebb, you could support discovery of the instance actor via url:

https://community.nodebb.org/.well-known/webfinger?resource=https://community.nodebb.org/

Where the resource is exactly `base_url` from nconf

@julian in your webfinger controller for nodebb, you could support discovery of the instance actor via url:

https://community.nodebb.org/.well-known/webfinger?resource=https://community.nodebb.org/

Where the resource is exactly `base_url` from nconf

@thisismissem @julian this assumes that the base url is the instance actor, which it might not be

@trwnh@mastodon.social @thisismissem@hachyderm.io @julian@community.nodebb.org yep. misskey does this differently. @instance.actor is transfem.social's actor. using base url would not work

@trwnh@mastodon.social @thisismissem@hachyderm.io @julian@community.nodebb.org i think akkoma's is something like /internal/fetch

@trwnh@mastodon.social @thisismissem@hachyderm.io @julian@community.nodebb.org Yes. https://akkoma.dev/AkkomaGang/akkoma/issues/855 (citing myself lol)

@puppygirlhornypost2 @thisismissem @julian more generally, the concept of an "instance actor" isn't well-defined

what most softwares call an "instance actor" is really more of a proxy actor, used primarily to sign fetches, not necessarily representing the service itself. i don't know why you'd want to discover such an actor outside of an http signature processing context. if you wanted to have a Service actor it would probably be best exposed via a specific link relation or rdf/jsonld predicate

@trwnh@mastodon.social @thisismissem@hachyderm.io @julian@community.nodebb.org It's kind of annoying when they're used to sign fetches. Some software expects that you are signing the request with the actor who made the request so if you fetch a private post but it's signed with the instance actor's keys it might not hand over the object. Even more generally the concept of an "instance" is not well-defined (which is why some software does not expect instance actors to be fetching objects, only individual actors). In reality instances may have more than actor acting on behalf of the instance. The one used for forwarding reports and fetching is usually referred to as "instance actor". Misskey has a relay actor (@relay.actor) which is also part of the software and how it behaves. Misskey's instance actor is also used to send Flag activities (anonymizing reports). If I suspend a remote misskey (or fork) instance's actor then I will no longer get reports forwarded to my instance from that instance. I'm unsure of what happens if I ignore the relay actor (in fact, I'm not really sure what relay actors are used for and that kinda scares me since I know akkoma also has one). There's not much documentation on how system/service accounts behave on specific instance software (and how they behave in relation to other instance software)

@trwnh@mastodon.social @thisismissem@hachyderm.io @julian@community.nodebb.org Unfortunately as these are not specified by a standard (AP2 does not make any reference to instances nor the concept of an AS service actor type being used as an instance actor) there is no universal path to resolve them. We can't even have universal properties as some software exposes the following/follower collection, some doesn't etc

@thisismissem @puppygirlhornypost2 @trwnh @julian This sometimes is indicated by metadata.federation.enabled flag in NodeInfo