Defining alsoKnownAs

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