Multiple domain support

[erlend-sh]

Takahe is a new ActivityPub server with support for multiple domains on the same server (“virtual hosting”).

Virtual hosting of multiple domains on a single ActivityPub server removes the need to run a whole new server for every person or organisation that brings their own domain.

Also relevant: https://jacobian.org/til/my-mastodon-instance/

[aumetra]

Hmm, interesting. Probably doable with the current database schema.
We already have a domain field (used for Webfinger resolution at the moment) that we could actually fill with the domain that's supposed to be associated with the user.

Gonna look into their code how exactly it's implemented, because right now I only have a rough idea on how it's supposed to work.

[aumetra]

Either we can do host-based routing or we do it similar to Takahe where they have [username]@[domain] routes.
The first one would keep the routes compatible with the current layout and wouldn't require a breaking change.

[erlend-sh]

https://shadowfacts.net/2023/activitypub-portable-identity/

There is, to the best of my knowledge, only one single ActivityPub project that supports multiple domains: Takahē. Multiple accounts across different domains being backed by the same host doesn’t get us all the way to portable identity. But the architectural decisions required to support it go a long way towards that vision. I have not taken the time to trawl through the code and work out if it’s actually using the domain to look up AP objects in its database or if it, like Mastodon and others, is still just extracting the database ID from a path component and using that for the lookup. Either way, by virtue of supporting multiple domains already, I think Takahē is much closer to reaching this vision.

Seems multi-domain might also be relevant to #172

[aumetra]

The article makes some interesting points that I will try to include in potential designs.

The key is just that looking up an object uses the entire URL, treating it as an opaque identifier rather than trying to parse it and pull out pieces

That's already something we are doing, so we are already somewhat doing what they are envisioning on that front.

You point your identity at the new server (either by changing your DNS records, or by updating your information in the resolver’s directory described before).

Domains users bring themselves should probably also feature some kind of TXT record validation to verify that the user is actually allowed to have their account hosted on that particular domain, so other users on the same instance can't just use their domain.

I personally wouldn't want someone else using, for example, my aumetra.xyz domain for their own account.

There needs to be some public identity resolver that anyone can use. The simplest way to implement this, I think, is as a service (or services, there’s no reason this has to be a centralizing force) that lets anyone point a subdomain at their host.

Sounds like a small service that could potentially be a separate project under the Kitsune org

---

I'm gonna need to make some notes on how Takahē implements sign-ups and whether domains can be updated after the sign-up (probably not, I'd assume).

[aumetra]

Oh, they have an 1:N mapping from users (registered local users) to accounts (ActivityPub identities; that's actually a really interesting naming, might adopt that). Very interesting

[Nemo157]

I'm not sure if this falls under the same umbrella, but I would like to have separate domains for accounts and the web ui. Mastodon has this by separating the LOCAL_DOMAIN—the domain accounts are registered to—from the WEB_DOMAIN—where the ui is hosted. I presume federation also functions over the WEB_DOMAIN since the only proxied resource for LOCAL_DOMAIN is webfinger, but if it is possible to also separate that I think it makes sense to allow decoupling it from the UI.

[erlend-sh]

Does that mean I could have a custom website on mysocial.com whilst also letting users sign up as @user@mysocial.com?

[Nemo157]

That is my understanding of it, the username used would be @user@mysocial.com but links to it would go to e.g. mastodon.mysocial.com/users/user.

I tried spinning up a test instance of mastodon to see how it behaved exactly (since from my meager knowledge reading about this, I don't know how preferredUsername allows a different domain), but it OOM'd my test server.

[Nemo157]

I've done some more investigation of the mastodon docs (mostly https://docs.joinmastodon.org/spec/webfinger/#mastodons-requirements-for-webfinger). I believe it is possible to have multiple domains delegate their accounts to one domain via webfinger forwarding, two examples of foo.example.org and bar.example.org delegating to kitsune.example.org:

• resolving @foo@foo.example.org
  • queries https://foo.example.org/.well-known/webfinger?resource=acct:foo@foo.example.org
  • redirects to https://kitsune.example.org/.well-known/webfinger?resource=acct:foo@foo.example.org
  • serves up a subject: "acct:foo@foo.example.org" with a self link to https://kitsune.example.org/users/c31edafd-a132-45bd-af62-f2f99caa0504
  • requesting https://kitsune.example.org/users/c31edafd-a132-45bd-af62-f2f99caa0504 serves up a preferredUsername: "foo"
  • requesting https://kitsune.example.org/.well-known/webfinger?resource=acct:foo@kitsune.example.org serves up a subject: "acct:foo@foo.example.org"
• resolving @bar@bar.example.org
  • queries https://bar.example.org/.well-known/webfinger?resource=acct:bar@bar.example.org
  • redirects to https://kitsune.example.org/.well-known/webfinger?resource=acct:bar@bar.example.org
  • serves up a subject: "acct:bar@bar.example.org" with a self link to https://kitsune.example.org/users/b5b30952-6518-43c4-a6b7-613d3ff77a9e
  • requesting https://kitsune.example.org/users/b5b30952-6518-43c4-a6b7-613d3ff77a9e serves up a preferredUsername: "bar"
  • requesting https://kitsune.example.org/.well-known/webfinger?resource=acct:bar@kitsune.example.org serves up a subject: "acct:bar@bar.example.org"

The "re-check" step is a bit annoying, it means that the preferredUsername must be unique on the primary domain.

---

More limiting is the mastodon client API. AFAICT it only supports a one-to-one "account domain" to "web domain" mapping, the client gets the "account domain" from /api/v1/instance's .uri or /api/v2/instance's .domain properties.

[julianfoad]

FYI, I'm sure most of you here "get it" already but anyway I've written some articles about own-domain emphasising why multi domain support is essential for the ecosystem to support ordinary individuals (as opposed to being seen as an "enterprise" feature): https://wrily.foad.me.uk/tag:owndomain

TL;DR: I want each of us who have our little home on the small web (such as an own-domain fedi account) to be able to offer the same to or friends and family: "friend, have an account on my server, at your own domain", easily.

[julianfoad]

See also: https://codeberg.org/Vocata/vocata "vocabulary-agnostic transport agent" ActivityPub server.

[erlend-sh]

https://mastodon.social/@dansup/112592035650286064

Pixelfed is working on custom domain support so you can bring your own domain to any Pixelfed instance, allowing you even more control, and a fallback in the event you need to migrate and preserve your handle/identity! 👀