Defining alsoKnownAs

This is what I mean, to specify its own relation at IANA, for example like we have it in the indieweb for micropub –
Aaron did register it (see above link), this one is then used like in

Hey @nightpool, my name is Manu Sporny, I’m one of the Editors of the DID Core specification… our goal here is to create something that is backwards-compatible with ActivityPub/Mastodon while achieving the use cases we need to solve in the official W3C DID Working Group. We’re using the property for the same purpose as Mastodon, AFAICT (and ActivityPub folks like @rhiaro seem to agree).

@nightpool wrote:

I don’t have any particular attachment to using JSON-LD or INFRA concepts specifically, i’d just rather maintain consistency within the AP/AS2 ecosystem on property definitions.

The W3C DID WG has to use INFRA in our spec to describe core data model primitives (this is the direction that a lot of specs w/ abstract data models are taking), which should be compatible with JSON-LD and ActivityPub.

The goal here is to make sure that we don’t do anything that prevents ActivityPub use cases, but defines things in a way that is compatible with the DID Core specification.

the ordered/unordered thing is an important distinction that I think we should hammer out

Yes, this is a common misconception with INFRA. INFRA only has the concept of an ordered set… see the note here:

NOTE: Almost all cases on the web platform require an *ordered* set, instead of an unordered one, since interoperability requires that any developer-exposed enumeration of the set’s contents be consistent between browsers. In those cases where order is not important, we still use ordered sets; implementations can optimize based on the fact that the order is not observable.

So, the order doesn’t matter in this case – we just want to ensure that no item appears more than once in the set.

Does this address your concerns @nightpool? To put it another way, what Mastodon use cases do you think are not covered with the current definition? Is there data that might be corrupted as a result?


We discussed this in the SocialCG meeting today, minutes available here:

Just to give a perspective about where the Fediverse community is here, I’d like to give an example of what I think the spec text for this might look like if it was written in a activitystreams-specific or activitypub-specific way. I’m thinking of this as kind of a “starting point” from the other side, so we can figure out what the generic definition might look like by unifying these two ideas. Please let me know if you have any feedback!



The alsoKnownAs relationship indicates that two Actor objects are shared by the same underlying user. However, care should be taken when consuming a document to make sure that the relationship is authorized by all actors involved. For example, if has "alsoKnownAs": "", then processing systems should also make sure that has "alsoKnownAs": "" before treating the relationship as valid. If the relationship is reciprocated, then the two actors may be treated as the same person for certain security-sensitive operations.

Domain: Actor
Range: Actor
Functional: false


  "@context": "",
  "type": "Person",
  "id": "",
  "name": "Catrina on dot-org"
  "alsoKnownAs": "",

  "@context": "",
  "type": "Person",
  "id": "",
  "name": "Catrina on dot-com"
  "alsoKnownAs": "",

Updated my definition with some clarifications and stronger language about how to verify the relationship. To give some context: currently, Mastodon processes and records the alsoKnownAs relationships indicated by each actor, but it only uses “1 way” relationships to make it easier for the user on the other end to “confirm” these relationships. 2-way relationships are currently only used for account migrations—before performing an account migration, each server receiving the Move activity checks to make sure that the 2-way relationship is in place.

This shouldn’t affect anybody else, but we’re currently looking into using this construct for nomadic content (not just for actors). It would be advantageous if any official property documentation didn’t insist that it only apply to actors; as there are a number of reasons why content might have more than one fetchable id. Sure, we could go back to talking about arrays of ‘url’ but then we’re back to the original problem of a general lack of support in the fedi for arrays of ‘url’ (or ‘id’) and a lack of motivation to fix it unless it directly impacts users of the top name brands.

[Edit: Cancel this request. There are some different directions I can take which should achieve the desired results and won’t involve or require any support from ActivityPub. Apologies. ]

This sounds like the alsoKnownAs field always has to point to an ActivityPub actor. However, we are thinking of using it to federate the user’s Matrix account ID. Would that violate the spec?

When I proposed alsoKnownAs, it was intended to point to AP objects only.

The definition says the value must be a URI, so there’s nothing to constrain it to an ActivityPub actor and it can be used to link identifiers in different systems this way.

Edit: there’s nothing to stop anyone from more tightly defining it in a different namespace though

Yeah it looks to me like did:alsoKnownAs has good semantics, but the as:alsoKnownAs term really is supposed to point to an AP object. That’s how it was implemented in AP servers, anyway.

In the end I came to the same conclusion as you, and went with a new field matrixUserId instead.

Just some questions from my - still limited, so pls bear with me - understanding of the subject matter. From the SocialCG meeting minutes:

RESOLUTION: we accept the alsoKnownAs definition in the DID Core spec ("This relationship is a statement that the subject of this identifier is also identified by one or more other identifiers. ") as a starting point that can be iterated on with the participation of both the DID and SocialCG communities.

This with the following understanding:

  • AS definition is the most generic, and DID a specialization (e.g. added restriction to be a set)
    • @rhiaro: “Yes, exactly – identifier and subject are meant to be general…
      … The subject could be an Activity Pub profile URl – supposed to be general/generic language… relationship is alsoKnownAs – ANY identifiers, HTTP URLs, DIDs, etc.”
    • @nightpool, @kaniini: The Domain and Range of alsoKnownAs is Actor, i.e. an URI to an actor profile ID.

Aren’t the two sub-bullets in conflict with each other? Wouldn’t it imply a did:alsoKnownAs to refer to an actor, if there’s compatibility?

Currently in AS Vocab the DID specialization is referred to. So with the above Resolution this is temporary - so as not to block @msporny with DID spec progress - and the intention is to iterate on a generalization of this? That would mean that eventually we’d have an as:alsoKnownAs, am I right? Probably defined in a FEP.

Will this interpretation give problems in having a universal understanding of the semantics of as:alsoKnownAs? Btw, in the context of a Move it is not necessarily the same Person that controls both (e.g. the move is from a personal account to one representing an organization actor).

Wouldn’t it be great to have some consensus on how all this works? This concept of Moving applies to ALL activitypub application types, and - if not well-defined - the situation on Fediverse will become messier and messier. Here @macgirvin with nomadic identity and movedTo / copiedTo may have great input.

Shouldn’t we consider this? Maybe the Domain and Range of as:alsoKnownAs should be Object? Consider e.g. an Event that has a Mobilizon url, a Gathio url, and an Organization website page (with SEO in it).

I see that in the Lemmy code the JSON-LD context is defined as:

    "sc": "",
    "sensitive": "as:sensitive",
    "stickied": "as:stickied",
    "pt": "",
    "comments_enabled": {
      "type": "sc:Boolean",
      "id": "pt:commentsEnabled"
    "moderators": "as:moderators",
    "matrixUserId": {
      "type": "sc:Text",
      "id": "as:alsoKnownAs"

I need to read up on the JSON-LD spec, so can’t say if this is correct. But I wonder about the mechanism in general. Matrix is just one of the many, many web locations that can represent an alsoKnownAs relationship. (For instance Keyoxide is an app to represent a code-generated verified profile with an ever-growing list of such relationships).

Shouldn’t there be a machine-readable way to figure out the type of link, without having to define unique property names for each of them? I don’t know what’s the best way, or if it is even desired. In (see data model notes) you have sameAs and identifier where the latter can be a PropertyValue with a Text + URL:

     "@context": "",
     "@type": "Book",
     "name": "Library linked data in the cloud : OCLC's experiments with new models of resource description",
     "author": "Carol Jean Godby",
     "isbn": "9781627052191"
     "identifier": {
         "@type": "PropertyValue",
         "propertyID": "OCoLC",
         "value":  "889647468"
     "sameAs": ""

PS. Note that AFAIK there’s no as:stickied (In Mastodon there’s featured, toot:featured and toot:featuredTag). Nor are there as:moderators.

So with the above Resolution this is temporary - so as not to block @msporny with DID spec progress - and the intention is to iterate on a generalization of this? That would mean that eventually we’d have an as:alsoKnownAs , am I right?

Yes, that is correct.

I haven’t had a chance to read the rest of your post, apologies – rushed this morning. I have also logged this issue given your query: alsoKnownAs missing from DID Spec Registries · Issue #275 · w3c/did-spec-registries · GitHub

We’re trying to do the right thing here wrt. the DID Specification… re-use alsoKnownAs, as defined in the ActivityPub community using the AS vocabulary. Our registry and JSON-LD Context will define alsoKnownAs to use as:alsoKnownAs.

1 Like

Just to be clear (and reiterate what @msporny is saying): there is no such thing as did:alsoKnownAs. The DID spec defines the as:alsoKnownAs property as it relates to DID. Since AP implementations are generally don’t implement the DID spec, this doesn’t really affect them—if they do wish to implement the DID spec in the future, then our goal is that they can do it in a way where both specs can be satisfied.


There is no accepted spec text in this area—I wrote this just as a draft of what I understood the current implementation of alsoKnownAs on the fediverse to be as a starting point for discussion.

I don’t have any strong philosophical objections to using alsoKnownAs to point to an object outside of the AS system—we’ve defined it on the as2 namespace, and to some extent we should expect it to be useful to any ActivityStreams implementor, even ones that have no interest in AP.

However, that said, 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.

EDIT: However, in either situation you need to make sure that the claim is bidirectional. If you can somehow make the Matrix profile page serve an as:alsoKnownAs property (maybe using itemprop?), then that would be an acceptable route. However, if you can’t get that second half of the bidirectional loop, then alsoKnownAs is inappropriate.

Thanks @nightpool … my confusion came from ActivityStreams 2.0 Terms where in Section 3 it says “terms are defined in as namespace” and in Section 4 this is not mentioned and says in 4.2 “The terms in this section are described in the [DID-CORE] specification.”

hm… maybe the use of “This namespace” (“This namespace may be used by extensions […]”) in Section 4 is a little vague? We can probably change it to “The as namespace may be used by extensions” to match the language in section 3

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:

  - 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

1 Like

Thanks for bringing this up! I was thinking about this as well, and settled on using the term “alias” for concept 2. My implementation of nomadic identity based on FEP-c390 therefore can be explained as “cryptographically verified aliases”.

However, FEP-c390 currently uses property names id and alsoKnownAs, who are starting to look inappropriate. It would be better to use subject and aliasOf instead.

On a closer look, however, DID spec and Fediverse seem to be aligned. In the DID spec, alsoKnownAs links different identifiers related to the same subject (a person, organization, etc). In Fediverse, it links different actors. It is more accurate to think of entity (person, organization) represented by actor as the subject. The controller of actor is, in fact, the server.

Consequently, the usage of alsoKnownAs in FEP-c390 also makes the most sense.


I think FEP-c390 can use “concept 1” as formalized by DID, but I don’t think Mastodon’s “concept 2” usage is aligned. The subject in question is not the person, but the actor/account. The controller is not exactly the server, but rather, the server is acting as an authority. My current thinking is that a rel-me Link in actor metadata (a la FEP-fb2a) would be most appropriate for “concept 2”, since if this were plain HTML that’s literally what you would use.