I was thinking about fep-612d actors via dns, and how to tie it into the actor object.
So acct is a valid uri scheme, so I would like to adapt my actor object to include
"alsoKnownAs": ["acct:helge@mymath.rocks", "acct:mymath.rocks"],
This would demystify a lot of the webfinger etc stuff, as the link actor → account is made explicit. Is there any issue that might arise from this?
that seems reasonable, and the only concern i have is the ambiguity of alsoKnownAs as expressed in another thread.
The acct: URI scheme was reinvented by webfinger. It’s a fairly terrible anti pattern, that was completely unnecessary. As the saying goes, “when developers get desperate they mint a new URI scheme”
It was born of a failure to realize that user@host is a unique literal string.
alsoKnownAs I dont like at all either, as it seems strongly tied to DID and a lot of very dodgy “crypto” schemes (often illegal unregistered securities). Some rail roading going on there, imho.
There has been sameAs in OWL and schema.org since forever. More recently I’m thinking about the term “alias”: “something that simply said two URIs refer to the same thing”
see also:
https://lists.w3.org/Archives/Public/semantic-web/2016May/0088.html
What’s would be quite valuable is canonical identity, imho
i thought it was born of the need to have something be a URI? and also to disambiguate from mailto: or xmpp: URIs.
i was thinking along similar lines. XRD/JRD subject vs aliases is a good pattern imo. there’s also rel=canonical which goes in one direction but i don’t think there’s a rel=alias, is there? it would be nice if there was… closest i could find was rel=duplicate which implies a byte-for-byte equivalence for static resources only.
The usage of acct: is tied into the current usage of webfinger, which is quite different from what I was asking about, i.e. a property of the actor object. So if you guys feel the need to discuss the usage of acct: and possible replacements, please split off the topic.
alsoKnownAs is now used by many Fediverse platforms to denote different actors controlled by the same person (in the context of “move followers” feature). I would prefer to use a different term, but at this point the change seems unlikely to happen.
If I understand correctly, in your example both URIs denote a single entity, so a different term may be more appropriate.
A thread which I assume @trwnh was referring to:
Another option would be to use something like
{
"@context": { ... },
"type": "Person",
"id": "https://example.tld/actor",
"identities": {
"type": "OrderedCollection",
"orderedItems": [
"acct:me.example.tld",
"acct:name@example.tld",
"did:key:cowsareawesome"
]
},
...
}
identities is an OrderedCollection listing possible identities in order of preference to be displayed. So this says, I prefer to be displayed as “me.example.tld” followed by the current style “name@example.tld”, followed by a decentralized identity, finally the id of the object.
This would nicely solve the issue of allowing users to specify how they want to be seen. One would need to formalize all this properly as a FEP though, where one addresses issues such as
Maybe, one should even use “publicIdentities” as a name, as these are intended in my mind to be shown to the public. 
this sounds similar to preferredUsername which is unfortunately expected to be a AZaz09-_ case-insensitive string of up to 30 characters by Mastodon.
orderedItems / OrderedCollection won’t work here though, since Collections are specifically Objects and not literal values. you’d want to define your extension property as @container: @list and not as @type: @id.
as to what to call that extension property… i’m not sure what would be best. i’m not sure what the semantic purpose of the property is, either – it seems like there’s some conceptual overlap with id, preferredUsername, and name.
No, not at all. In fact the whole idea of webfinger in the first place was to be tied to email.
You have an email type address, which you log in to a site with, user@host.
Now you want to get some machine readable data from it.
IF you want to add a URI scheme to user@host login strings, the one to reuse is mailto:. But there’s no reason to mint a URI scheme in this case, you just do a lookup.
So there was general confusion along the way and then acct: was suggested out of desperation.
Some things need URIs, others do not. A login string can perfectly well be used as a UUID for lookup.
Same with facebook using Firstname_Lastname.
But we’re stuck with acct: now. It’s technical debt that wont go away soon. Just remember the principle of looking up a string of type user@host, no URI scheme is required, that only confuses things more.
Sorry just read this. Was just replying to the comment. Will stay on-topic in this thread 
The “identities” property would hopefully replace “preferredUsername”, once worked out. It would allow for other uses such as:
{
"@context": {
"identities": {
"@id": "http://w3id.org/fep/example/identities",
"@container": "@list"
}
},
"identities": [
"acct:a@trwnh.com",
"acct:trwhn@mastodon.social"
]
}
if you add the appropriate reply to https://trwnh.com/.well-known/webfinger?resource=acct:a@trwnh.com. Then the client can display your posts with the heading:
infinite love ⴳ
@a@trwnh.com
I’m still looking for a good property name to use for this.
So is the intent to use this exclusively with WebFinger? it sounds like the use of this property is “take a value from the list and plug it into the host’s webfinger as resource” – is that correct?
No. See other examples, for example: acct:mymath.rocks for use combined with FEP-612d or did:key:cowsaregood for use with a decentralized identifier. Also putting “https://mymath.rocks” in the identities list should be acceptable. The address can be resolved to my account through the link element in the html.
So formally: identities MUST be a list of URIs that resolve only to the actor. Servers MUST check that they can resolve the URI to the actor before passing them to clients.
Resolve how, and via which authority?
At least with id it’s generally accepted that, since we’re all using HTTPS for the most part, the way to resolve an LD node is to do an HTTP GET. But for other schemes, you need to specify a resolver (both resolution method and resolution authority). Particularly for the acct: URI as defined in RFC 7565, there is no specified resolution method.
To me, it seems like if the hope is to replace preferredUsername, and/or to “demystify a lot of the webfinger etc stuff”, then it would be worth explicitly specifying a WebFinger property. Otherwise, the use-case and application needs to be unambiguously defined.
That’s not the problem being solved here. Here a list of possible identities is provided.
I like the strategy of braking problems down into small steps, that are actually solvable.
The “aliases” array is an array of zero or more URI strings that
identify the same entity …
Though it would be confusing to have alsoKnownAs and aliases at the same time.
Another idea: preferredHandle.
Right, but what is the problem being solved? Are these “possible identities” considered “aliases” in the WebFinger sense of the term, or are they something else? If you say “can resolve”, then it stands to reason that there should be some specified resolution method and authority; otherwise, you can’t resolve.
Right now, I see several broadly similar and slightly overlapping concerns, mainly around identifying a resource (via JSON-LD id, XRD/JRD subject, XRD/JRD aliases). You also mention “allowing users to specify how they want to be seen”, which… isn’t that just name? The only reason preferredUsername exists is because Mastodon plugs it into WebFinger against the server’s hostname (and then handles a redirection layer).
The only thing really missing from any of these properties is support for an ordered list of multiple values. Imagine if, for example, I could declare preferredUsername: ["a", "trwnh"], and then I joined an IRC-like room. If a is taken, then my username becomes trwnh.
Are you sure this limitation still exists? I searched through Mastodon code and found this validator: mastodon/account.rb at 4b9e4f6398760cc04f9fde2c659f30ffea216e12 · mastodon/mastodon · GitHub. The comment says it is only used for local accounts.
There’s a remote username validator right above it, which I think is pretty much the same just without the 30-character limit.
alsoKnownAs has its existing use; it’s basically “These accounts are or were also me”. Perhaps the name is not ideal for the purpose, but that’s how it’s used
If I were to suggest a way of signalling “Alternative identities of the same account”, I would go for
{
"@context": [
"https://www.w3.org/ns/activitystreams",
{
"xrd": "http://docs.oasis-open.org/ns/xri/xrd-1.0#",
"aliases": {
"@id": "xrd:Alias",
"@type": "@id",
"@container": "@list"
},
}
],
}
Which references the XRD definition of Alias, which is what Webfinger uses, so there’s already precedent for use in the fediverse-as-deployed.
For the use in ActivityPub, we can additionally specify that
With regards to non-user@domain IDs, we’re getting a little off topic, but I always liked the OpenID Connect normalization rules which state that “foo.net” should be normalised to “https://foo.net/” for discovery purposes.