@julian in your webfinger controller for nodebb, you could support discovery of the instance actor via url:
-
@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 I was going to contribute it, but uhhh, no can do: https://github.com/NodeBB/NodeBB/issues/13391
I don't see a clearly documented path for development, so whilst I could probably make the required code change, I can't verify it would work
-
@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
-
@thisismissem @julian this assumes that the base url is the instance actor, which it might not be
@[email protected] @[email protected] @[email protected] yep. misskey does this differently. @instance.actor is transfem.social's actor. using base url would not work
-
@[email protected] @[email protected] @[email protected] yep. misskey does this differently. @instance.actor is transfem.social's actor. using base url would not work
@[email protected] @[email protected] @[email protected] i think akkoma's is something like /internal/fetch
-
@[email protected] @[email protected] @[email protected] i think akkoma's is something like /internal/fetch
@[email protected] @[email protected] @[email protected] Yes. https://akkoma.dev/AkkomaGang/akkoma/issues/855 (citing myself lol)
-
@[email protected] @[email protected] @[email protected] 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
-
@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
@[email protected] @[email protected] @[email protected] 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)
-
@[email protected] @[email protected] @[email protected] 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)
@[email protected] @[email protected] @[email protected] 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
-
@[email protected] @[email protected] @[email protected] 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
@puppygirlhornypost2 @trwnh @julian context for where this came from: trying to figure out if a given nodebb server is currently federating (i.e., has AP enabled)
-
@puppygirlhornypost2 @trwnh @julian context for where this came from: trying to figure out if a given nodebb server is currently federating (i.e., has AP enabled)
@thisismissem @puppygirlhornypost2 @trwnh @julian This sometimes is indicated by
metadata.federation.enabledflag in NodeInfo -
@thisismissem @puppygirlhornypost2 @trwnh @julian This sometimes is indicated by
metadata.federation.enabledflag in NodeInfo@[email protected] is that part of the nodeinfo spec?
