Fediverse

I have little of substance to offer. But specifically regarding the permanence of usernames I'd assume part of it is to prevent impersonation. "Hey guys, 'sup, it's me, ya boi, I know I deleted but I'm back! Now, I have a big favour to ask my dear followers because, you see, my grandmother's budgie has turbo cancer of the tailfeather [etc]..."

That's a very important question we need to address !

It makes sense for platforms to block reuse of identifiers: they identify something, if the thing changes it should get a new identity.

Identities are fundamentally that: how to recognize that something is not something else. Note that it really is something: the same person can have multiple identities, and an identity can be shared by multiple persons.

The main issue is that we have been immersed inside a State-based system for so long we forget it exists. The first thing that comes to mind when we talk about identities is our state-delivered identity: name, surname, address, driving license number, etc... there's a central all-powerful authority deciding what identity is given to whom, and they are unique and active as long as the State decides. In practice this has made identities a public-facing concern because the State is in charge of everything.

Centralized platforms, of course, reproduce the model. Both the State and capitalist platforms (or capitalist anything) act under the paradigm of total domination, there's no surprise here: the platform owns your identity, your data, your you. When we reproduce the same thinking in open/decentralized platforms we inherit the mentality although everything points to not actually wanting it: we don't want a platform to have control over our identity/identities unless we have control over the platform, yet in practice we do. We link an identity with a name, so of course names must be unique

We need to go back to the roots: what is an identity ? A way to differentiate two things to someone. Who can guarantee the identities we have ? Our connections. "Mom" is an identity in my contacts app; this identity is obvously not the same identity as "Mom" in your contacts app, although the name is the same. That's because this identity is not the same to me that it is to you. The entity "using" the identity is fundamental. That's something we forget when using centralized platforms: the entity "using" my identity isn't my contacts, it's the platform. To the platform, everyone must be unique, so must have a different name in their "contacts app". That is not a model that cares about us but about itself.

What model cares about us ? A model that puts the focus back not on the individuals being represented, but on the relationship. An identity can never be defined by biometrics or hardware keys or whatever technic that technosolutionnist rave about. Technosolutionnists by definition do not care about sociology, so they shouldn't be listened to for sociology issues. An identity will always be defined by who recognizes you as such.

What does it mean in practice ? Basically, we need to build communities of people taking care of each other. My access to the group chat shouldn't be defined by a technical solution to access the app; if I lose access to the technical solution, the community still knows my identity as the same, so it must be able to re-integrate me without a hurdle, whatever the technical means.

What this means is that identities shouldn't be public-facing. They should be something inside a community only, defined by it with the means it decides.

At its heart, identity is about uniqueness. Being able to tell that things are distinguishable from each other. The real question to answer here is, how is uniqueness determined? What can anything or anyone use to be certain that they are recording against something unique? Most systems implement a UUID internally which they can guarantee is unique per entity in their system because they are the issuer of the identity. However, giving these unique identifiers out to other systems is problematic for exactly the reasons you mention. If lost, forgotten, or stolen, the original entity can no longer get them back.

For digital systems and man made things, uniqueness is relatively straightforward. Unique ID identifies the thing is who they claim, but for people this quickly gets difficult.

How does a person assert with authority they are a specific someone? What can be reliably used? The likeliest pathway is biological factors, such as DNA, but identical twins share DNA, as do cloned things. Fingerprints are unique, assuming you have them, and if you don’t, also not reliable. Biometric data is often used but not 100% reliable. Failing that the next best identifiers are things issued by other authorities that your system is willing to trust. You might want to use a government issued document, from a reputable government, that can be verified, and is hard to forge. Not foolproof, but good enough. We rely on the government not to issue that same ID to two different individuals, and we rely on the individual retaining their government ID over long periods of time. Unfortunately, government IDs are not commonly used due to the high-risk nature of the data on them, and the low frequency of users having them handy. America tries to issue an ID to all users for this type of reason, the Social Security Number, but these have become extremely flawed over years due to data breaches and the fact they are passed around so freely that anyone could know yours.

Failing that, systems look for something else they can use that is globally unique, and stays with the user. Phone numbers aren’t adequate as they are often recycled and change frequently. The closest thing available, as you’ve already pointed out, is the email address. By necessity, emails are globally unique. We rely on them not being recycled too often, and they are most commonly (although not always) associated with an individual. Systems rely on the issuing authority to not break the system by issuing one to more than one person, and it serves a dual purpose of being able to be used to contact the owner.

No matter what system is put in place, there is a reliance on some authority maintaining and managing the integrity of the identifiers. Decentralised identity still relies on a person having access to the ID, and if that person loses it, then it’s between them and the identity provider to work out how they get it back, for the consuming applications, the same practical issues exist. A lost or changed ID results in a new entity on the application and the old one becoming unusable.

Most applications have workarounds for people losing or changing their identifiers (such as email address) but often this relies on the user changing it whilst still in passion of the old one, or relies on another method of verifying the person is who they claim, such as government identifiers, assuming they have at some point captured that information in the first place.

If I'm reading you correctly, this is what Decentralized ID (https://en.wikipedia.org/wiki/Decentralized_identifier) aims to resolve, not just for social accounts. I wrote the initial DID implementation for my previous employer, but FIs, especially credit unions (our primary customers) were still a ways off from implementing it.

My familiarity with ATProto (https://en.wikipedia.org/wiki/AT_Protocol) is extremely shallow, but as I understand it, ATProto can use DID. Hopefully someone else will come along and provide more info or correct my error.