Defining alsoKnownAs

[trwnh]

@nightpool

Confusing the concept of (different representations for this actor) with the concept of (different actors for the same logical person) seems like a mistake to me.

@nightpool

in Mastodon right now, we use alsoKnownAs for two different actors to identify that the same person controls both.

@rhiaro

Mastodon use it for authorising profile migration

@rhiaro

In the interest of not duplicating work and to help make Mastodon’s use of the term ‘legit’ we were hoping to agree on a formal definition

@nightpool

when we implemented a similar feature for Mastodon, we didn’t go that route—instead, we parse the free-form bio fields to find “verifiable links” (links with rel=me), and then created a simple rule for validation on the other side (the HTML page or HTTP response at the target contains a rel=me link that points back to the actor’s URL). To some extent this is duplicating work that alsoKnownAs is already covering, and it adds more out-of-band complexity, but we decided that this method was much easier to integrate with other non-AP systems, and had better existing wide-spread adoption.

@msporny

Our registry and JSON-LD Context will define alsoKnownAs to use as:alsoKnownAs.

i can’t help but feel we’ve not really solved the issue while going ahead and formalizing it. the problem as i see it is that mastodon et al’s usage of alsoKnownAs follows nightpool’s “concept 2” (different actors for the same logical person), whereas the DID usage follows “concept 1” (different representations for this actor)

if the intent is indeed “concept 2”, then a rel-me approach would have been better. we might mark up an attachment Link on the actor like so:

attachment:
  - type: Link
    href: <the other actor>
    rel: ["me"]

and then check for bidirectionality. or in mastodon’s Move handler’s case, check that the target (migrating to) links rel-me back to the object (migrating from).

indeed, the DID notion of “also known as” seems to differ from the existing activitypub usage of it. it may instead be thought of not as a “rel-me” (concept 2, i control both actors) but more like the XRD/JRD aliases property (concept 1, both identifiers represent the same subject). in fact, is this not literally what the definition ended up being?

This relationship is a statement that the subject of this identifier is also identified by one or more other identifiers.

in the interest of opening the way / paving the path toward DID and nomadic identity and other cool and interesting things, it seems like this might be worth revisiting. given that as:alsoKnownAs got imported into the DID core with the above definition, we probably need to decide whether we are going to defer to this definition, or if we are going to defer to mastodon’s existing usage of the term.

i see a few possible approaches:

1. defer alsoKnownAs to mastodon’s usage (concept 2, controlling the listed actor). define a new term aliases (pending name) to represent concept 1, different identifiers for the same subject. we might also define subject or some similar term to identify a “canonical” identifier?

2. defer alsoKnownAs to the DID core definition (concept 1, different identifiers for the same subject). implement a transitional period in which mastodon and other projects switch to a different mechanism more along the lines of rel-me. eventually deprecate the use of alsoKnownAs for determining rel-me.

---

EDIT: some possibly related “prior art”?

owl:sameAs is described as identifying two individuals as the same (not to be confused with owl:equivalentClass, which declares two classes to represent the same concept) OWL Web Ontology Language Reference