Multiple domain support about kitsune HOT 9 OPEN

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).

from kitsune.

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.

from kitsune.

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 @[email protected]
  • queries https://foo.example.org/.well-known/webfinger?resource=acct:[email protected]
  • redirects to https://kitsune.example.org/.well-known/webfinger?resource=acct:[email protected]
  • serves up a subject: "acct:[email protected]" 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:[email protected] serves up a subject: "acct:[email protected]"
• resolving @[email protected]
  • queries https://bar.example.org/.well-known/webfinger?resource=acct:[email protected]
  • redirects to https://kitsune.example.org/.well-known/webfinger?resource=acct:[email protected]
  • serves up a subject: "acct:[email protected]" 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:[email protected] serves up a subject: "acct:[email protected]"

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.

from kitsune.

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.

from kitsune.

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.

from kitsune.

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

from kitsune.

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

from kitsune.

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

from kitsune.

That is my understanding of it, the username used would be @[email protected] 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.

from kitsune.