Defining alsoKnownAs

[rhiaro]

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

[kaniini]

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.

[nutomic]

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

[aschrijver]

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.

---

@nightpool

in Mastodon right now, we use alsoKnownAs for two different actors to identify that the same person controls both. 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.

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.

---

@macgirvin

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.

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

---

@nutomic

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

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

  {
    "sc": "http://schema.org#",
    "sensitive": "as:sensitive",
    "stickied": "as:stickied",
    "pt": "https://join.lemmy.ml#",
    "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 schema.org (see data model notes) you have sameAs and identifier where the latter can be a PropertyValue with a Text + URL:

    {
     "@context": "https://schema.org/",
     "@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": "http://www.worldcat.org/oclc/889647468"
    }

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

[msporny]

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.

[nightpool]

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.

[nightpool]

@nutomic

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?

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.

[aschrijver]

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

[nightpool]

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

[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

[silverpill]

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.

[silverpill]

@trwnh

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)

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.

[trwnh]

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.