Questions about trying to set up WebFinger properly

Hi,

I’m setting up a new Akkoma instance and I’m trying to set up WebFinger properly before using it so I don’t screw anything up. I have the instance in a subdomain but I’d like my profiles to have just the domain.

I followed the docs and I set up the configuration file like this:

config :pleroma, Pleroma.Web.Endpoint, url: [host: “fedi.omaera.org”, scheme: “https”, port: 443],
[…]
config :pleroma, Pleroma.Web.WebFinger, domain: “omaera.org

  1. Is there a way to check if it’s working properly before posting?
  2. WebFinger[.]net doesn’t resolve my user because it’s not checking host-meta so it’s knocking omaera[.]org, not fedi[.]omaera[.]org as indicated by host-meta. Is this okay?
  3. I already created my admin account before this. Should I recreate it, or should I’ve done this change before I created any account?
  4. I’m using Mangane FE which uses the “fqn” field of the accounts API endpoint. That field returns the nickname with the host, not the WebFinger domain. Therefore it shows z411@fedi[.]omaera[.]org, not z411@omaera[.]org. Is there a field that holds the WebFinger domain so I can fix the FE to show it properly?

All help is greatly appreciated.

The answer to most of the questions is mentioned in the documentation, albeit the documentation for this specific setup only targets users with prior technical knowledge and mentions this. Setting up split domains without understanding the basics of WebFinger is not recommended.
https://docs.akkoma.dev/stable/configuration/how_to_serve_another_domain_for_webfinger/

WebFinger.net does the correct thing here. As the docs instruct, WebFInger esoltuion must be reachable via the advertised WebFinger domain.

Mixing accounts created with different WebFinger domains is a bad idea. As the docs say:

An important risk if you set up your Akkoma instance incorrectly is to create two users (with different acct: URIs) with conflicting author/actor URIs.

If WebFinger lookups as described at the start work and api/v1/instance lists the expected WebFinger domain under uri everything should be fine. I assume WebFinger.net checks the former.

I did read the documentation several times. The documentation mentions this:

When you add @user@example.org, a webfinger query is performed. This is done in two steps:

  1. Querying https://example.org/.well-known/host-meta (where the domain of the URL matches the domain part of the acct: URI) to get information on how to perform the query.

If you recall how webfinger queries work, the first step is to query https://example.org/.well-known/host-meta, which will contain an URL template.

This is what I am doing. It is explained that WebFinger queries host-meta, which contains the URL template, then will query the URL in the template. In my server https://omaera.org/.well-known/host-meta is returning the following:

<Link type="application/xrd+xml" template="https://fedi.omaera.org/.well-known/webfinger?resource={uri}" rel="lrdd" /></XRD>

Which contains the URI to the subdomain. WebFinger[.]net doesn’t query host-meta at all, and instead just tries to query https://omaera.org/.well-known/webfinger. Sure I can add the redirect for that instead, but shouldn’t in that case the docs instruct to return a 301 for /.well-known/webfinger instead of /.well-known/host-meta? What is the point host-meta then if it’s not being queried as explained in the step 1 of the documentation?

Someone else already asked this: No mention of host-meta which can be used to redirect webfinger requests · Issue #28 · swicg/activitypub-webfinger · GitHub
The response was the following:

Oh, hm, I think the expectation is that (at least in Mastodon) you need to redirect the /.well-known/webfinger endpoint entirely, not that you use /.well-known/host-meta or /.well-known/host-meta.json.

The use of host-meta as a “second layer of indirection” is something that mostly a holdover from the OStatus days, IIRC. Most projects that aren’t Mastodon or Pleroma will not check host-meta at all, and will instead always skip straight to the /.well-known/webfinger endpoint. I don’t think it makes sense to unnecessarily pressure everyone into adopting host-meta or supporting variable LRDD endpoints, where WebFinger is in fact a profile of LRDD that serves specifically JRD instead of XRD.

In that case it’s better to just redirect /.well-known/webfinger altogether, as Mastodon docs instruct (Configuring your environment - Mastodon documentation).

I haven’t yet posted with that account and I am curious where the acct URI is saved in the database. It’s certainly not in the users table. That said I’ll remake the user just in case as it has no posts.

Looking at Akkoma source code for the instance endpoint I can’t see how it could return the WebFinger domain:

def render("show.json", _) do
    instance = Config.get(:instance)

    %{
      uri: Pleroma.Web.Endpoint.url(),

Pleroma.Web.Endpoint.url() holds the instance subdomain URL, not the WebFinger one. WebFinger is under Pleroma.Web.WebFinger.domain().

I’ve been looking at the code and it mostly looks like Akkoma doesn’t really care about the WebFinger domain at all (as opposed to Mastodon where the WebFinger domain actually represents user accounts) and it’s only focused in responding WebFinger queries correctly if asked as an afterthought, but the main domain used everywhere is always the host URL. Am I wrong in this assumption?

Sorry, I missed the doc only shows a redirect for host-meta. As the parts you quoted from elsewhere already alluded to, WebFinger spec directly specify the .well-known/webfinger path:

The path component of a WebFinger URI MUST be the well-known path “/.well-known/webfinger”. A WebFinger URI MUST contain a query component that encodes the query target and optional link relation types as specified in Section 4.1.

If you could, opening a PR improving the docs for this setup clearing up all the points you struggled with might be helpful for future instance admins

I haven’t yet posted with that account and I am curious where the acct URI is saved in the database.

For local users it’s not saved in the database, but remote instance which already encountered the user in some form will have the old domain under nickname and will be confused if it suddenly changes.

Looking at Akkoma source code for the instance endpoint I can’t see how it could return the WebFinger domain: […]

The part you’ve copied is an old version and this was changed for Mastodon-compatibility recently; here is the current one:

    %{
      uri: Pleroma.Web.WebFinger.domain(),

I see - yeah it seems the host-meta thing is something Mastodon/Pleroma/Akkoma do but it’s not really in the spec, so I will open a PR for that. Therefore just to be sure I will be redirecting both:

location ~ ^/.well-known/(host-meta|webfinger) {
        return 301 https://fedi.omaera.org$request_uri;
}

I see, I haven’t made any post with that account so theoretically it shouldn’t have issues.

Ah I see, makes sense. I am using the stable version and I am looking at code from the v3.15.2 tag so in that case I will pull from develop and build from there instead of using OTP.

This clarifies things a lot, thanks.

I tried creating accounts and following myself, it worked fine from Mastodon and Akkoma, it shows:

test1@omaera.org

But from a Pleroma instance when using Remote Follow it shows:

test1@fedi.omaera.org

Did Pleroma not implement this fully? Would I have problems talking with people on Pleroma?

Also I talked to you about this in the issue tracker, but I noticed is that Pleroma does use the WebFinger domain in the fqn field, as merged in this patch:

Akkoma never merged this change.

Merged the change myself but while it fixes the frontends, Pleroma instances still don’t use the WebFinger domain for remote follows, strange.

I tested hosting a Pleroma instance and the issue persists so I’ll take it to them.
About the fqn, I submitted a PR. Thanks for your time.