acap @AYE_CAP1 - Twitter Profile

Lots of critics of Urbit ID seem to confuse the distribution of the address space with the structure and design of the address space. The former is clearly a hindrance to the project, but the latter is compelling on its own and I think the real key to an Urbit beyond a science project. So let's talk a little bit about what aspects of the design I find compelling. An Azimuth point is just ultimately just a cryptographically ownable number. That number is represented in the pronounceable fashion of Urbit as a multi-syllabic word like ~zod, ~marlur, ~poldec-tonteg, etc. You can think about that at a basic level as a handle, as equivalent of a handle on Twitter or of a unique user ID. The main distinction between the Twitter handle and the Urbit ID is that there's a finite amount of Urbit IDs. That number is way too big to be useful right now, but there is a finite amount of IDs. Azimuth points also have two key pairs, networking and encryption keys. The networking key pair is used by your ship to sign and decrypt messages. This is currently used by Ames, the Arvo networking protocol, but this could easily be used in a normal stack for e2e encryption. But the there's also an encryption keypair as well. This allows you to share encrypted files with people on the open internet and use Azimuth as the key server. And an underrated aspect Bridge, the application that is used primarily to boot a ship, is that it gives you an easy way to initialize both these key pairs without going through a centralized service. The Azimuth point structure also includes several “proxies” that can have various permissions on the point itself. Every NFT has a way to own the NFT via an Ethereum address, we refer to this as the Master Address. You can think of this as “root” in a unix system, it can do anything. Urbit ID, though, adds the ability to delegate certain permissions to other “proxy” addresses. An important proxy is the management proxy, which is allowed to do essentially everything on the point except for transfer it. This makes it so you can your everyday address can have lesser security, be more available, accessible, while being confident that no one's going to be able to steal your point. And then there’s a third a proxy address that allows you just to transfer the point. This could be used for safe transfers, lockups or escrow contracts. As an example, this delegation of privileges allows for social recovery of the NFT. You can shard the master address, and then distribute that among a few friends, opting to use the management address for day to day use. If you lose access to that address you can get three out of five of your friends to reconstitute the point for you and reset everything. But probably the least understood aspect about the Azimuth point is that it has a series of what are called claims, a list of data triples (key, value, hash) that are associated with the point. This allows you to attach basic metadata or application specific data to the point. Imagine keybase-style attestation: you tweet a signed string from your Twitter, and that would attest that you owned that Urbit ID. That attestation goes on the chain, and can be verified by anybody. You can also get arbitrarily complex with the metadata, because you can also put other endpoints in the claim, if you needed a larger data structure that can be stored on IPFS or similar. But what's interesting about all of these design features is that is that they don’t require the whole cap table, the whole address space to get the benefits. If you wanted to, you could carve off a little piece of the namespace, you can say, okay, under my star, I'm going to do all this cool stuff with the Azimuth points for the planets under my star. But you know, if you're under a different star, you’re out of luck In the coming days, I’m going to be riffing on product more use cases for Azimuth and sharing them on here just to get the old noggins joggin.

1

38

12

7

3K