Defining alsoKnownAs

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

1 Like

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)
https://www.iana.org/assignments/link-relations/link-relations.xhtml

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]

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

@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:

https://infra.spec.whatwg.org/#sets

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?

2 Likes

We discussed this in the SocialCG meeting today, minutes available here: https://www.w3.org/2020/11/07-social-minutes.html

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!


alsoKnownAs

URL: https://www.w3.org/ns/activitystreams#alsoKnownAs

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.

Domain: Actor
Range: Actor
Functional: false

Example

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "type": "Person",
  "id": "https://example.org/cat",
  "name": "Catrina on dot-org"
  "alsoKnownAs": "https://example.com/cat",
}

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "type": "Person",
  "id": "https://example.com/cat",
  "name": "Catrina on dot-com"
  "alsoKnownAs": "https://example.org/cat",
}

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": "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.

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.

2 Likes

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