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.
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.
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.
@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 )
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.
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 …
However:
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. 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)
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="https://serviceControlledByMe.org">Antifa</a> would be valid markup [wink smiley]
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 https://www.w3.org/TR/micropub/#endpoint-discovery-p-1
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).
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?
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 https://example.org/cat has "alsoKnownAs": "https://example.org/dog", then processing systems should also make sure that https://example.org/dog has "alsoKnownAs": "https://example.org/cat" 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.
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?
)
Yay. Hooray.