Correction: check_webfinger!

Mastodon is not the fediverse and in my check_webfinger! post, I’m afraid I made that assumption. In particular, I concluded

So, from the perspective of mastodon, the domain component of your identifier you are known as is determined by which domain serves your actor document rather than the domain serving the original “well known” webfinger document.

which is not necessarily true if you consider the fediverse outside of Mastodon.

Instead, it seems that I should have said that the domain component of your identifier is determined by the domain component of the subject field returned in the webfinger response from the domain that serves your actor document when mastodon makes its 2nd webfinger request which is done in the check_webfinger! method.

  def check_webfinger!
    webfinger                            = webfinger!("acct:#{@username}@#{@domain}")
    confirmed_username, confirmed_domain = split_acct(webfinger.subject)

In the code above, the @domain passed to webfinger! is the domain of the server providing the activitypub actor document but the confirmed_domain can be different (e.g. your personal domain) if your original “well known” webfinger document was not pointing to a Mastodon server for providing the actor document.

Therefore, if you have a static personal website, it is not necessary to also host the actor document there as long as the fediverse node providing the actor document is smart enough to provide your personal domain in the subject when mastodon makes a webfinger call to it. A caveat is that such a fediverse node accomodating personal domains would not be able to distinguish between bob@a.com and bob@b.com when mastodon webfingers server.com for bob@server.com.

check_webfinger!

The notes I made in Mastodon Discovery skipped over a noteworthy step. In general, after mastodon fetches and parses the “well known” webfinger document (the so-called JSON Resource Descriptor), there is a 3 step process to learn about the actor referenced in that document.

  1. fetch_resource
  2. check_webfinger!
  3. create_account

As mentioned previously, in the first step, a very comprehensive json document for the actor is fetched and in the third step, an account is created for that actor if does not already exist. However, between those two steps, mastodon does another webfinger lookup since, for instance, the domain serving the actor document may be a different domain than the one that originally served the first “well known” webfinger document. Prior to this check, some instance variables are set:

    @uri      = @json['id']
    @username = @json['preferredUsername']
    @domain   = Addressable::URI.parse(@uri).normalized_host

The @uri instance variable is the location of the actor document and the @domain instance variable is the domain that serves the actor document. After these variables are set, the check is performed:

    check_webfinger! unless only_key

This check enforces that the domain component of your identifier is the domain that serves your actor document. (It inspects the subject of the “well known” document and if the username and domain of the subject match the instance variables above, the ‘self’ resource link is required to be the same as the @uri instance variable. If the subject does not match, one more webfinger lookup for the redirection is allowed.)

So, from the perspective of mastodon, the domain component of your identifier you are known as is determined by which domain serves your actor document rather than the domain serving the original “well known” webfinger document. It seems if your domain is a static site and you want to be known by an identifier associated with your domain, your domain needs to serve the actor document in addition to “well known” webfinger document.