One of the foundational aspects of the AT Protocol, and one of its differentiating features compared to other communication protocols, is the dual-identifier system for users within the protocol. Upon signup, users within ATProto are assigned both an immutable Decentralized Identifier (DID), and a mutable handle.
In many respects, these identifiers are interchangeable: knowledge of one identifier can be used to resolve the other. However, the use cases of these identifiers are typically orthogonal, and improper use of either identifier can be seen as "bad practice" within the ATmosphere. To understand why the dual identifier system exists, and how to use these identifiers properly, it's necessary to understand the inherent contradictions between identifer use-cases in large-scale communication protocols.
In any communication protocol, it is a necessity to establish an identifier system for actors within the network. These unique identifiers are used to sign, authenticate, and validate data sent from a particular actor.
Let's use the SMTP email protocol as an example. if you are expecting an email from John, and you know his address is [email protected], you would be able to determine an if email is truly from John by simply checking the email address of the sender. If the email instead came from [email protected] or [email protected], you could determine with certainty that the email was not sent from John's email address.
There is an inherent problem, however, in the use of clean, user-defined identifiers in mass-communication protocols, a problem you're likely familiar with if you've ever signed up for an email address: like all identifiers, email addresses must satisfy a uniqueness constraint. Therefore, within each domain, there can be one, and only one john. Indeed, because of this limitation, it is much more likely that John has an email address that looks something more like [email protected] or some variant therein.
One can imagine that this problem could be easily solved by simply assigning a random assortment of characters to each user who signs up, and preventing users from changing it in the future. Now, instead of John's email address being [email protected], his address would instead be [email protected]. This system would surely prevent any conflict between email addresses. However, this system also presents an obvious problem: How could users be expected to memorize email addresses when they are all simply an assortment of random characters? Such a solution is inelegant and impractical for any mass communication protocol.
Therein lies the contradiction that every communication protocol must somehow resolve: How can a protocol provide human-readable, memorable identifiers that accurately represent the users' preferred identities while simultaneously satisfying the uniqueness constraint for all identifiers?
The effects of this contradiction are lessened in protocols such as SMTP and ActivityPub, as part of the identifier is defined by the domain authority of the server in which your account resides. However, this solution is impractical for a protocol such as ATProto, as one of the key goals of the protocol is to enable users to freely move their accounts to whichever server they wish, without affecting their experience within the network. It would be rather impractical if the account's identifier changed every time this happened!
How can we solve this problem? There are many potential solutions to this contradiction, however, for now, we will hone into one particular solution, analyze its benefits and drawbacks, and iterate to synthesize a solution.
[WIP]