Instead of burning an ID permanently, perhaps there could be a time duration. For example, if an ID has not seen any activity for over a year, and a new ID shows up with the same channel address but a different hash. it will consider the new ID a new identity and not a forgery.
But obviously, the GUID/hash is not the single key that defines a channel
GUID=abc123 belonged to me@domain-a.org on server a. It is verified against hash 978sd6f94c.
If a user removes their account using the removeme page is there a period of time that has to go by before they can register again?
One reason you do not pass around a hash is because you do not want to give away the guid
channel@example.tld
channel@example.social
Is it possible for a nomadic guid to store a list of all url and/or public keys that have been associated with the guid? Would other parts of the fediverse be able to verify by being able to read the entire list, until a match is found?
While I have nothing against exchanging keys when I have the old and the new one, I wonder why I would need to to so if I do have the old key: I could just install the hub and import the original channel with the original key.
My priority is more on those who lost the original channel without backup of the key, or never had access to it in the first place (it's not breaking the rules to re-use a domain).
identity@example.social (old)
identity@example.social (recreated 2023-01-14)
identity@example.social (new)
install the hub and import the original channel with the orginal key
Would this be accepted by other fediverse (e.g. activitypub, diaspora) protocol verification process?
I consider Diaspora a lost cause at this point
