Move Mastodon handle to @dwk@dwk.io (apex WebFinger delegation)

[davidwkeith]

Goal

Move my Mastodon identity from @dwk@📟.dwk.io to @dwk@dwk.io, while the instance itself keeps running (and serving the Mastodon client/APIs) at 📟.dwk.io.

This is the LOCAL_DOMAIN ≠ WEB_DOMAIN split:

• LOCAL_DOMAIN=dwk.io — the domain in the handle (@dwk@dwk.io)
• WEB_DOMAIN=📟.dwk.io — where the server/web UI/API lives (unchanged)

Note: @dwk/workers acctDomain is not involved — that would only matter if @dwk/workers were hosting the actor, which it is not. Mastodon stays the server.

Context

• The instance is on managed hosting, so LOCAL_DOMAIN/WEB_DOMAIN are provider-controlled — they can't be set via env/shell.
• The instance already federates as @dwk@📟.dwk.io, so this is an identity migration, not an in-place rename. Changing LOCAL_DOMAIN produces a different actor; existing follows/signatures do not carry over automatically.
• dwk.io's apex already serves this website (this repo), so the whole apex can't be handed to the Mastodon provider — only the three .well-known discovery paths need to reach the Mastodon server.

Work required

1. Provider ticket — set the domain split

Open a support request with the managed host asking them to:

• Confirm they support a WebFinger/handle domain (LOCAL_DOMAIN) that differs from the web domain (WEB_DOMAIN).
• Set LOCAL_DOMAIN=dwk.io and WEB_DOMAIN=📟.dwk.io.
• Confirm whether they serve the apex /.well-known/* or expect us to (see step 3 — we serve it).

2. Migrate the existing identity

Because @dwk@📟.dwk.io already exists and federates, pick one:

• Account Move (keeps followers, not posts): stand up the dwk.io identity, then Settings → Account → Move to a new account, which fires a Move activity so followers re-follow the new handle. Preferred if the current follow graph is worth keeping.
• Destructive reconfigure: provider flips the domains and the old handle/follow graph is dropped. Only if there's nothing to preserve.

3. Apex WebFinger delegation on dwk.io (this repo / Cloudflare)

Once handles are @…@dwk.io, the apex dwk.io must answer discovery by pointing at the Mastodon server. Delegate only these paths (leave the rest of the site untouched):

• /.well-known/webfinger
• /.well-known/host-meta
• /.well-known/nodeinfo

Preferred: a Cloudflare Redirect Rule (302, preserve query string) forwarding those paths to https://<punycode>.dwk.io…. Use the punycode A-label (xn--…) for the 📟.dwk.io target host — the emoji label is display-only; DNS/TLS/WebFinger operate on the A-label.

when  http.request.uri.path starts_with "/.well-known/webfinger"
  or  http.request.uri.path eq "/.well-known/host-meta"
  or  http.request.uri.path eq "/.well-known/nodeinfo"
then  302 → concat("https://<xn--…>.dwk.io", http.request.uri.path, "?", http.request.uri.query)

Redirecting (rather than serving our own JRD) keeps Mastodon as the single source of truth — correct signatures and the FEP-2c59 back-link. If we ever want the apex self-contained, @dwk/webfinger could serve the JRD instead, but that's not needed here.

Verification

curl 'https://dwk.io/.well-known/webfinger?resource=acct:dwk@dwk.io'
# → JRD with subject "acct:dwk@dwk.io" and a self link to the 📟.dwk.io actor

Then search @dwk@dwk.io from another server and confirm it resolves and can be followed.

Outcome

	Before	After
Handle	@dwk@📟.dwk.io	@dwk@dwk.io
API base / client login (WEB_DOMAIN)	📟.dwk.io	📟.dwk.io (unchanged)
Apex dwk.io /.well-known/*	site	redirected to 📟.dwk.io