More robust handling of cases where username is reused or keys change https://github.com/tootsuite/mastodon/issues/12148
1: Establish root trust by signing profiles/keys with the instance actor
2: Establish a web-of-trust for instance actors, using Trust On First Use (TOFU)
TLDR:
- Give instance actors their own keys, if they do not have them already.
- Sign profile keys with the instance key.
- Add UI in the admin panel to audit when instance keys change.
anyway case in point how do you know that mastodon.rocks is the same as mastodon.rocks (after the database was lost)
or how do you know that an instance is different if its domain name expires and someone registers the same domain and hosts a fedi instance there again
or what about if the instance stays the same but someone deletes then recreates their account with the same username
all this and more
@trwnh uh, doesn't Mastodon just never free up old usernames?
@noiob the admin of each instance would need to figure out which is the case (depending on whether they trust claims by the new admin as to whether they are the same person as the old admin)
@trwnh yeah, that makes sense
@trwnh what's a https id? part of AP?
@noiob yeah the https://mastodon.social/users/trwnh or https://awoo.space/users/noiob or https://social.example/u/4897320948732094
@noiob everything in activitypub has an id which is just an https url for now
that way you can just GET the id and obtain the object when you're working with other objects that reference it
@trwnh ah
Pleroma accounts can have human-readable URIs too, right?
@noiob on the backend both mastodon and pleroma use /users/username -- pleroma just uses various routing urls for their frontend that end up resolving to the same thing
@trwnh I mean masto has urls with @ in them too
@noiob yeah but those are just urls, the masto code routes /@username to /users/username transparently
@trwnh ah
@noiob mastodon refers to every account via user@domain
pleroma (and others) refer to accounts via the https id
both of those can change (although in practice the latter is more stable)
ultimately what we're *really* doing here is trusting the instance, not the profiles -- the instance is hosting the profiles
so we need a way to identify instances, and relying on keypairs is probably good enough here. if the keys change then it was reinstalled either a) by the owner or b) by someone else