Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Explicitly describe the format of the alsoKnownAs property #37

Open
edent opened this issue Nov 5, 2024 · 2 comments
Open

Explicitly describe the format of the alsoKnownAs property #37

edent opened this issue Nov 5, 2024 · 2 comments

Comments

@edent
Copy link

edent commented Nov 5, 2024

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:user@example.com or @user@example.com 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
Copy link
Contributor

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
Copy link
Collaborator

lisad commented Nov 6, 2024 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants