Azimuth is a self-sovereign identity platform on Ethereum: a blockchain PKI. Azimuth is designed to work well with Arvo, but Azimuth does not depend on Arvo.
Each Azimuth identity ("point" or "address") is six things: a
memorable name, a cryptographic identity, a web login flow, a
network endpoint, a graphic sigil, and an HTTPS-signed DNS domain
(point.urbit.org).
Ecliptic is Azimuth's self-governing constitution.
Azimuth (azimuth.eth) is a virtual land registry. Ecliptic
(ecliptic.eth) is a self-amending constitution, which owns
azimuth.eth.
When Ecliptic amends itself, it rebinds ecliptic.eth, and also
grants the new contract ownership of Azimuth. But azimuth.eth
is never updated; it is always the original data contract.
Anyone on the Internet who wants to make sure they are talking to
the real Azimuth/Ecliptic can: (a) find an Ethereum node they
trust, or run one; (b) double-check that azimuth.eth is bound
to the fixed hash of the true registry contract (X); (c) check
that ecliptic.eth is the owner of this contract.
We, Urbit, the developers of the Azimuth and Ecliptic contracts,
retain ownership of Ecliptic. But ownership gives us only one
trivial power: managing the DNS domain (initially urbit.org)
that maps Azimuth space into DNS space.
"Urbit" is the our project to create the Azimuth/Arvo/Casbah stack. Urbit is not a codebase -- Urbit is an organization.
Abstractly, Urbit is to Casbah as the yolk is to the chicken: a temporary energy pool, temporally restricted to Casbah's early growth, atrophying over life. Concretely, Urbit is a Delaware corporation (Tlon) organized as a typical SV startup.
To connect with a centralized authority, we need a centralized
authority -- which will hopefully have little work to do.
Azimuth does not absolutely need this DNS mapping. But it's
a very nice feature. The initial point.suffix, since Urbit
maintains the mapping, is urbit.org.
Azimuth contains no interesting technology. Given its approach, its details are fairly obvious. Its motivation is not obvious.
Most people think digital identity is a hard problem. These people are mostly right. Most of them are solving a genuinely hard problem: adapting existing, real-world identities to the digital world.
Adapting one natural identity system into a cryptographic PKI is hard. Adapting two is hard squared. Now you're writing glue. Generalizing over all human identity systems is infinitely hard.
The world of cryptographic identity is an alien world. That world was not made by us. It was made by math. Math is perfect; humans are imperfect. Math is inflexible; humans adjust.
Maybe we humans should be quiet, and listen to the math? We might find ourselves solving an easy problem, not a hard one.
In the history of virtual spaces, we constantly see human beings demonstrating their human capacity to adapt to the affordances of the space in which they exist. The tools will never adapt. The humans came to immigrate and assimilate. If they'd rather be elsewhere, they'd already be there. They are here to adapt.
A digital identity platform is still a human interface. We can hardly ignore human factors. But our north star must remain uncompromising technical simplicity. If the code is simple, we believe, we humans can find a way to make it easy to use.
To make something simple, start from nothing. One way to start from nothing is to question the idea of "identity" itself. Who needs an identity layer at all? On the blockchain? A blockchain is itself an identity layer.
Why isn't an Ethereum address an adequate digital identity? Isn't that what an Ethereum address is already -- an identity?
No: a 20-byte Ethereum address is not a good digital identity. But why not? What are the problems?
That's a great way to explain Azimuth. We'll explain Azimuth as an improvement on Ethereum, by listing the problems with Ethereum itself as a digital identity -- and fixing them.
Cryptographic identity transfer has an nice duality. Passing a cryptographic identity to another owner, and changing the key that secures that identity, are the same operation. The math does not know or care which bag of meat holds the secrets.
Clean transfer is impossible with a naked Ethereum address. Since the address is a function of the key, it makes no sense to change the key. The owner can hand over the secret, but has to promise that no copies were kept.
Solution: add a level of indirection. Ethereum addresses are not identities; they own identities.
These identities are digital titles, like the paper title to a house or car. We call a title an Azimuth point -- as in, a point in space. You can also say address
The unique name of the house or car is still a 20-byte string. But this 20-byte string is a unique piece of digital property. To be exact, it's an ERC721 non-fungible token.
Azimuth is simply a land registry that maps points to their owners, which are Ethereum addresses. This is an extremely conventional, straightforward use of Ethereum.
Spam is always and everywhere a Sybil attack. When there are infinite disposable identities, the marginal cost of an identity is zero. Which means a blocked identity costs the attacker nothing. Which means that a server has no way to defend itself, because damaging the reputation of any identity does no damage.
The normal way to build identities with meaningful names is a name registry. Experience shows that any such registry will be heavily squatted and have trademark problems -- navigable issues for a company, but not a great human experience.
A registry also does not solve the scarcity problem. Good names become scarce; lousy names are infinite; no computer can tell the difference.
Solution: reduce point width to 32 bits
What parts of a 160-bit address space are the most valuable? The lowest parts -- because these are the lowest numbers. The lowest numbers are the shortest and easiest to remember. They are the most useful, so they should be worth the most. The bottom of the address space is the part to capture.
Azimuth calls points under 2^32 planets. Positions under 2^16 are stars. Positions under 2^8 are cities. So there are roughly 4 billion planets, 65,280 stars, and 256 cities.
2^32 digitally independent identities is about the right number. It's the same as the number of IPv4 addresses. It's about the present number of Internet users. It's about a billion times the present number of Internet social "networks," ie, servers.
Azimuth points are not fungible. Each point is a different number. But unlike ENS domains, these numbers are almost fungible. Like identical houses in the same real-estate development, unused bases are uniformly useful and should be easy to trade. It's simple to write an ERC20 market for Azimuth planets, for instance.
By making points scarce, we've made them easier to use. We can't make points meaningful -- but we can make them memorable.
We've already started by making them short. Four bytes is already much easier to handle than 20. But an IPv4 address, at the same four bytes, is still a terrible name -- a mouthful to say and a handful to remember.
Solution: phonemic base-256 cryptonym
We go from the IPv4 notation, 177.56.99.12, to the Azimuth
notation, ~labpyx-taswed.
Each byte becomes a three-letter syllable. We've made a list of decimals into a slick, sci-fi cryptonym. What is the use of a name which is easy to say and remember, but means nothing?
Plenty. A cryptonym is an impersonal, euphonious cryptographic pseudonym. Unlike meaningful handles, which are often tasteless and always require a registry, and real names, which are the worst, a nice cryptonym is secure, tasteful, professional and opaque. And anyone who has ever read a sci-fi novel can bond with their own four-syllable, 32-bit Azimuth planet.
Towns are shorter: ~balser. Cities are one syllable: ~reg.
How do we distribute a desirable namespace without a central process or registry?
Solution: hierarchical creation
The stable state of any property system is a market -- or, on Ethereum, a token. Azimuth is a tradable ERC721 token, so the market works. But how is the market booted? How are the initial tokens distributed?
We can distribute 4 billion points easily. Each 32-bit planet is created by its 16-bit star prefix. Each star is created by its 8-bit galaxy prefix. The prefix is the (numeric) parent. (The actual cryptonym is scrambled to disguise this relationship.)
So we only need to distribute 256 cities. That might be socially hard, but it's not technically hard.
Since Azimuth planets are scarce, the cost of an initial reputation is nonzero. Great, but how does reputation actually work? How can any point tell that any other point is cool?
Reputation is only one example of the basic need for governance. To be governed is to have a durable relationship with some entity who (a) you have basic responsibilities toward, (b) has basic responsibilities toward, and (c) has this same relationship with many of your peers.
Solution: hierarchical sponsorship
We can reuse the prefix hierarchy, not just at creation time, but at runtime. Your parent will become your sponsor.
The relationship between sponsor and client: the sponsor agrees to provide neutral technical services to the client, probably for a small fee; the client agrees to not abuse these services.
We know an Azimuth planet is okay, because its star sponsors it. We know an Azimuth star is okay, because its galaxy sponsors it.
No one sponsors an Azimuth galaxy. But we expect it to be okay. First, a galaxy is a serious Internet business. So its owners are probably serious people. Second, if a galaxy drifts into bad hands, it's easy to manage a short list of mishandled cities.
And we know an Azimuth galaxy is okay, because (a) a galaxy should be pretty valuable, meaning its owners are probably serious people; (b) it's easy to make short lists of not-so-okay cities.
What does "abuse" mean? What is "bad"? The sponsorship hierarchy is meant to control technical abuse, not social abuse. Any network built on Azimuth should be a common carrier -- a packet network that routes bits, rather than judging them, and is technically and ethically neutral.
But if social governance at the top layer fails, the problem will fall back onto the network topology. Routing and judgment should not mix, but it's still always good to have a plan B. The Azimuth hierarchy is not pretty, but it is serviceable.
Governance is good. Tyranny is bad. The sponsorship design, so far described, is bad.
The problem is that a star has monopoly power over its planets. Its services should be priced and provided at commodity rates. Sponsorship (possibly bundled with hosting) should be like your relationship with your ISP.
But if a planet needs to be sponsored by a star, and only one sponsor (the planet's parent prefix) is available, the star will extract monopoly profits -- and possibly do other weird stuff. Ick!
Solution: assisted escape
A planet still needs to be sponsored by a star. Its parent is still its initial sponsor. But it can escape to any other star -- so long as its new sponsor accepts it. Similarly, a star can escape to any other galaxy.
If a planet cannot find one of 65,280 sponsors, or a star one of 256, this point is probably unsalvageable. It is very hard to organize this number of providers into an effective monopoly. ISP service gets pretty good once you have four or five choices.
Azimuth does not have a single human owner. The Azimuth contract
proper (azimuth.eth) is just a data contract. The binding of
azimuth.eth will never change.
The owner of the Azimuth contract, which also contains the logic
to manipulate Azimuth data, is the Ecliptic contract
(ecliptic.eth). Ecliptic also owns its own ENS registration.
It seems unlikely that we would need to change this logic. But suppose we did?
Solution: a senate
The galaxy owners are the senate of Azimuth, and govern it. They
can pass two kinds of resolutions: formal constitution upgrades,
which specify a replacement for ecliptic.eth, and textual
decisions, which must be interpreted in English.
Textual decisions are needed not because the senate needs to express its opinion on the great questions of the day, but because some decisions -- like a decision to migrate Azimuth to a different blockchain, which is certainly not out of the question -- cannot be expressed as a new constitution contract.
Human beings like to be represented by both names and symbols. The European coat of arms, the Japanese family crest (kamon), and the Gravatar test pattern all bear witness to this desire.
It seems natural that we should have a function from Azimuth point to vector image. But what should it look like?
Solution: functional sigils
We wanted Azimuth sigils to be (a) visually beautiful; (b) recognizable (don't all blend together as "Gravatar noise"), and (c) readable (once you've seen a lot of them, your eyes start being able to map backward from sigil to name).
[INCLUDE SOME SIGIL EXAMPLES]
Azimuth is on Ethereum. Cryptographic property
Solution: 64-bit phonemic brainwallet
Can you remember a four-syllable Azimuth planet, then an
eight-syllable Azimuth ticket? Like: santug-nortem and
lomnum-bitdet-habrep-magfer?
Then you can keep your Azimuth point in your head. If not, at least it doesn't take a lot of paper. A (paper) sticky note in your (leather) wallet always works well.
Ethereum wallets are hard to handle. We add a deterministic wallet generation step above the standard BIP39 wallet path. Our wallet generation step uses the Argon2 KDF against the 96-bit concatenation of planet and ticket. The ticket is then encoded with the standard Azimuth phonemes.
Systems built around Azimuth should try to securely prompt the owner to repeatedly produce this ticket -- for example, by using it as a password (pls only send hash). Using your identity can become a spaced-repetition exercise.
Since the Internet still matters, it sure would be nice to be able to use your Azimuth identity as a DNS domain name.
Solution: point.suffix
Azimuth contains an updatable list of DNS suffixes. The Senate will make these domains work, or find new ones.
"Work" means: help anyone who has an Azimuth point to use some
public HTTPS certificate service on the point.suffix domain;
and proxy HTTPS connections so that https://point.suffix works,
with full end-to-end security.
This is also the one power remaining to the Ecliptic contract creator -- DNS obstacles do need to be handled by a single responsive agent.
Azimuth points seem pretty useful at this point. If these are serious identities, they should be able to talk to each other, in an encrypted and authenticated secure off-chain channel.
But how? You could sign messages with the private key of the Ethereum address that owns your point. But that seems weird. Also, this is a signature key, not an encryption key.
Solution: register Curve/Ed25519 public keys
The solution: owners of Azimuth points can register and update public keys for both encryption (Curve25519) and authentication (Ed25519).
Now Azimuth is not just a land registry. It's also a public-key infrastructure (PKI) which can create secure network channels.
Of course, a keypair is not a network. How do two Azimuth points actually talk to each other? What do they say? On what port?
Solution: Arvo
It turns out that a protocol and an OS are the same thing. Or rather: we have a practical choice between an old protocol with an old OS, or a new protocol with a new OS.
Metaphorically: when we ask how to talk to a computer, we are asking what language the computer speaks. In a sane world, the language it speaks over the network, and the language it thinks for itself in, are probably in some sense the same thing.
So, having designed a simple and beautiful identity... we just need to keep going up the stack and design a simple, beautiful computer. Let's step forward to Arvo.