Explicitly describe the format of the alsoKnownAs property

[edent]

As per https://swicg.github.io/activitypub-data-portability/#process-0

2 The user marks the new actor as accepting a move with the alsoKnownAs property.
...
5 Each follower checks the alsoKnownAs property of the new account and movedTo property of the old account.

Firstly, what do they check? That they exist? That they have case insensitive equality? That they resolve to the same location? Something else?

I assume it means that the actor must contain "alsoKnownAs": "https://old.example/users/username" - but that isn't explicitly stated anywhere.

I've seen discussions online where people said the AKA was acct:[email protected] or @[email protected] etc.

From experimentation, it seems that the https:// version works when moving a Mastodon account.

The spec points to a discussion which is also referred to in a different discussion - but I can't find something where it is explicitly stated what the format should be.

May I suggest that the documentation be updated to say something like:

2 The user marks the new actor as accepting a move with the alsoKnownAs property. The alsoKnownAs property should be identical to the URl presented in the old user's movedTo property. These properties should be the full URl of the actor object.

Or similar?

[bumblefudge]

I think we should use the id property of the Actor, NOT a web finger uri or any other URI, and I greatly appreciate the callout to specify "equality". What's the standard language for "URI" equality? we might want to match if, say, one of the URIs has query parameters, and maybe redirects are worth calling out either way (i.e., if u deref a uri and get an actor with a diff uri in its Id prop, which uri is the one you test against the other?)

wait now I've confused myself halp @dmitrizagidulin

[lisad]

That's a good question and there's more, "thanks" to the extensibility of URLs. Do Actor IDs come in only one followable form or is it possible to follow "https://old.example/users/username" or instead " https://old.example/users/username/photos/nature" or " https://old.example/users/username?filter=photos-nature" and get fewer notifications? Is this a thing that exists out there? This has implications for portability of the follow list to a new location also, as well as the handling of the "previously" property on objects. Lisa

…

On Wed, Nov 6, 2024 at 1:35 AM Bumblefudge ***@***.***> wrote: I think we should use the id property of the Actor, NOT a web finger uri or any other URI, and I greatly appreciate the callout to specify "equality". What's the standard language for "URI" equality? we might want to match if, say, one of the URIs has query parameters, and maybe redirects are worth calling out either way (i.e., if u deref a uri and get an actor with a diff uri in its Id prop, which uri is the one you test against the other?) wait now I've confused myself halp @dmitrizagidulin <https://github.com/dmitrizagidulin> — Reply to this email directly, view it on GitHub <#37 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADWH4JDYGHDNPYLD6UNUWDZ7HPFNAVCNFSM6AAAAABRGTHF6GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINJZGEZDGOJQG4> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[bumblefudge]

Do Actor IDs come in only one followable form?

Protocol-wise, I think actor IDs DO come in only one form-- the id property that was in the Actor object at time of following. Anything else would be an extensions, and in most cases, an unspecified one!

One variation that I can imagine some implementers might care enough to make a valid extension, for bridges and interop with more key-based identity systems would be https://server.example/users/alice#ed25519-key (Src), e.g. for a re-posting bot that needs to create a new pipeline/alias/etc each time an AP client (or a hybrid AP++ client, more realistically) rotates its Activity-signing key.

[bumblefudge]

That they resolve to the same location?

That HTTPS GET returns the [bitwise? RDF-wise?] identical resource, i would think?

Or similar?

I'm not sure bitwise OR lexical equivalence is appropriate here, but I DO think it would have to be "URL equivalence" in a literal sense, i.e. either what RFC 1738 considers equivalent (case-insensitive domain apex, port optional, but case-sensitive path) if you want to be pedantic, or "identical results GETting both via HTTPS" if you want to be pragmatic/looser. We're talking Actor objects here, so they should be gettable (modulo content negotiation and authN)

[bumblefudge]

If lisa agrees with my extremely opinionated answers here, feel free to assign me the PR, or push back if i'm being crazy or opaque 😄