Defining alsoKnownAs

Hi everyone,

Over in the Decentralized Identifiers (DID) W3C Working Group, we noticed that Mastondon uses the property alsoKnownAs (docs) for account migration. It’s implemented as though it’s part of the ActivityStreams 2.0 vocabulary although it isn’t actually in there. We also want a property like this for DIDs. 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 of alsoKnownAs (which we can publish in the DID Core specification which is on track to become a W3C REC this year) and then add it properly as an ActivityStreams 2.0 extension (via a SocialCG resolution).

So we’re drafting a definition that we hope is agreeable to both the DID and ActivityPub communities:

The value of alsoKnownAs MUST be a list (per [[INFRA]]) where each item in the list is a URI conforming to [[RFC3986]].

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

(Note that the [[INFRA]] spec is a set of abstract definitions of foundational concepts - like lists - so that they can be used in specs regardless of the actual concrete syntax used.)

I’d love feedback from anyone who implements or uses or otherwise has an opinion on this.


1 Like

What makes it different from “streams” in the Actor object?
The spec. says
“A list of supplementary Collections which may be of interest.”

About “Social CG resolution”.
Would love that, attended recent meetings but there is this

My understanding is streams is explicitly about Collections (feeds, lists of posts), whereas alsoKnownAs refers to another identifier for entity itself, whether that is a person(a) or something else. Mastodon use it for authorising profile migration (when the relationship exists in both directions).

We use it for nomadic identity in Zot projects and have no problem with that definition. What we do is only slightly different than Mastodon, where it is used in conjunction with a ‘movedTo’ property as a verification mechanism. We use the same constructions but with a ‘copiedTo’ property to indicate that the original actor shouldn’t be removed when processing this particular kind of identity operation. Multiple identities are equivalent and different instances are treated as a single entity on the inbound side, and messages distributed to all participating instances on the outbound side.

I see. But i don’t fully understand why we need an extra property in AP vocab.
E.g. if you say

refers to another identifier for entity itself

In ActivityPub there is url
Identifies one or more links to representations of the object

The difference is that it MAY be a list …

url is a more specific kind of thing than we’re trying to capture, and isn’t necessarily an identifier for the person/org/thing whose profile it is on.

The point really is that Mastodon and Zot are already using alsoKnownAs even though it wasn’t in the vocab - could they have used streams or url for their profile portability use case? I suspect not, the meanings of these things are all different, less precise than alsoKnownAs.

1 Like

@rhiaro, maybe you could directly ping ppl in the Zap and Mastodon teams (see Groups in the menu). I don’t know how often they check the forum (and in how much hurry you are to get feedback :slight_smile: )

It’s complicated. Originally we used url but early on in the activitypub world a number of projects crashed when encountering an array instead of a single URI. In fact Mastodon was at one time the only project besides my own that didn’t crash in this case. Things have probably changed since then, but as long as Mastodon was using alsoKnownAs for their form of migration, I just copied for our completely different form of migration. I haven’t gone back to using an array for ‘url’ because frankly I don’t have time to recheck every platform again and see which ones work and which don’t. Even after filing numerous bugs against a number of projects, most ignored the bug reports for months because Mastodon didn’t send an array and that’s all the compatibility they cared about. Those that didn’t fix their code noticed that we reverted to a single URI instead of an array (so we wouldn’t have to wait for months for them to fix their code) and closed the bug as no longer an issue.

1 Like

I fully agree to @macgirvin because currently redaktor supports an url array as well.
I also have to say that it is pretty frustrating for another AP implementor that Mastodon does not care to become AP “conformant” -

The spec clearly says which things are “Functional” (can’t be an array) which means that other properties like url should be supported.
In terms of url the caption says it explicitly “Identifies one or more links to representations of the object” !
In some implementations it is just an issue of the UI. It could simply map an array or Collection to <ul> and OrderedCollection to <ol> and then add some CSS …

Personally I disagree that it is different from url
I would clearly go with url !

The rel (relation) property in a Link is where we should specify such link relations !
E.g.: For redaktor rel="me" does the trick to lookup other “profiles” (but the protocol isn’t clear at this point)
or How about specifying alsoKnownAs as a link relation ?

please let me add

I don’t have time to recheck every platform again and see which ones work and which don’t

exactly the same. This is why I don’t care anymore while I am building a generic AP conformant server and client/UI …
I will have a look in the end if/how we can satisfy the limits of others (or if maybe not).

Most important : The computer says this is the first time that “rhiaro” posted here.
This is awesome. :partying_face: Yay. Hooray.

I agree with @rhiaro that adapting url for this very specific migration use-case makes little-to-no sense—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.

On the specific spec language:

I haven’t read the DID spec yet, but since AS2 is defined as basically a RDF vocabulary, i think it’s inappropriate to use the WHATWG definition of list here, since it doesn’t mesh with any of the other AP or AS2 specs. For example, alsoKnownAs relationships aren’t ordered in a JSON-LD document. Instead, I would probably recommend just describing it as a (non-Functional) relationship with a domain of Actor and a range of Actor.

(note: 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. When defining algorithms, it may make sense to reference to INFRA, but i think when defining vocabulary we should stick with the existing concepts used by the rest of the vocabulary)

(also, as I mentioned, the ordered/unordered thing is an important distinction that I think we should hammer out)

That is still a “link relation” and we can still use “alsoKnownAs” in url -
I would just like to have it specified as a link relation (if it is different from rel=“me” as described in the quote)

I think this is how the Semantic Web works, it would be much more convenient to me if I have a list of links and my software learns about the links by just reading them.
Instead of /me feeding my software with a bunch of extra specified properties where /me has to say my software what they mean …

Also I can communicate it to my users because <a rel="alsoKnownAs" href="">Antifa</a> would be valid markup
[wink smiley]

It would simply make Software Support easier …

to put it in terms of link relations, the problem is that the url property (as defined in the as2 spec) is more like rel=alternate then rel=me

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