Hey Blockstackers! There have been a few questions about how Blockstack, names, zone files, profiles, and profile data are all related. I’ll try to answer that here.
Background: What’s in an Identity?
Without getting into the philosophy of identity, we’ll just say that as far as Blockstack is concerned, your identity is the set of all the data that you actively generate. Cryptography is only important insofar as helping you prove to others whether or not a piece of data is part of your identity.
From a software engineering perspective, the “core” of your identity is a set of keypairs: your current keypair, and all your previous ones. Once you have a keypair that only you control, then you can proceed to generate and sign data so anyone who has your public key can prove that the data came from you. If you ever change your keypair, all the data you signed with the previous keypair up until the point you changed it is still yours as long as you still claim ownership the previous key.
As many of you know, getting other people to find your current public key (and not an imposter’s key) is a very, very hard chicken-and-egg problem. Even if you solve this problem, you still have to solve the related problem of helping other users find your signed data.
Blockstack: Naming, Storage, Accounts
To solve these problems, Blockstack does three things (Figure 1). First, it lets you use a blockchain to associate a globally-unique but human-meaningful names to your current public key. Names are the discovery points for your identity’s keys: if I know one of your names, then I can always get your current public key and use it to verify that some piece of data belongs to you.
The second thing Blockstack does is it lets you automatically upload and download your identity data (including public keys) to whichever storage providers you want, while ensuring that others can find and download it later. To do so, Blockstack lets you associate a zone file with your name. The zone file contains your current identity public key as a TXT record. Supposing I have both your name and a signed piece of data, I would use Blockstack to look up your public key and use it to verify the signature.
Figure 1: Names are used to discover your current key (black), previous keys (grey), and all the data you claim as part of your identity. Your identity’s data is stored into commodity storage providers, and is logically partitioned into a set of “accounts.” Each account’s key is derived from the current public key, and as a designated set of storage drivers.
The third thing Blockstack does is it helps you group and organize your identity into accounts. Just like in the legacy Web, your identity likely contains lots of data for different purposes that ought to be visible to different people. To help manage your data, Blockstack lets you create accounts that sign data for a particular purpose.
Accounts serve a similar purpose to normal app accounts on the legacy Web. Accounts are disposable–you can create and delete them (and their data) at will. Accounts are linkable–you can show that an account (and its signed data) belongs to your identity. Accounts support selective disclosure–you can control who gets to show that an account belongs to your identity. Accounts are configurable–each one can use a designated set of storage drivers, so you can control exactly how your data will be kept.
Onename: A Blockstack Application
Onename is the first Blockstack application, and has two purposes: helping users get identities and names, and displaying user-given “about-me” profile pages with social proofs. When you sign up for Onename, what’s really happening is you’re creating an identity, giving it a name on Bitcoin, creating a Onename account keypair, and then storing some profile data into Onename.
At first, Onename owns your identity’s current keypair, but you can create a new keypair and retire the old one by installing the Blockstack CLI and transferring the name out (Figure 2). Once you do so, your and only you own your identity’s keypair, and you can proceed to do things like create a new account key and generate new profile.json files.
Figure 2: Transferring a name out of Onename and creating a separate account to store the profile data.
The data you store with your Onename account is specific to Onename’s needs, as you might expect. When you view a profile on Onename, what’s really happening is you’re giving Onename a name to look up, and Onename is using Blockstack to fetch and authenticate a specific profile.json record that the user has stored for this purpose.
Onename makes special use of a name’s zone file to find the profile.json record. It requires the user to have inserted URI records into a name’s zone file that contain URLs to signed profile.json copies. This is an application-specific zone file use-case (*): you can put whatever you want in your zone files, but if you want to use Onename, you have to follow this convention.
In a similar vein, the profile.json file itself is specially formatted for Onename’s use-case. It follows the Person schema on schema.org and it points to “external” data like your avatar picture and background image. Onename’s job is to take your authenticated profile, look through your social verification proofs, and turn them all into an “about.me” page. If you put arbitrary gunk into a profile.json file, Onenane simply refuses to render it.
(*) Note: the blockstack lookup command also follows this convention. However, this is a legacy hold-over. A separate “Blockstack identity” tool will be written to use Blockstack to fetch a name’s zone file, interpret it, and fetch and render a profile.json record.
Future Applications
Onename is just the first of many Blockstack applications, and will evolve into a “Blockstack identity” application that runs almost entirely client-side. Future Blockstack applications will follow this design pattern (Figure 3). The application will have its own identity and its own names, and it will host its app data and configuration on the developer’s designated storage providers. Users will interact with applications by loading Javascript, CSS, and HTML from the developer’s storage providers and running them in their Web browser.
The new Blockstack identity application is illustrative of the ways that users will interact with their data in the Blockstack-powered Internet. If Alice wants to store a new profile via this new Blockstack identity application, she first accesses the application by (1) looking up the zone file for onename.app, (2) parsing the zone file to find the specially-crafted app.cfg file, and then (3) parses and uses the app.cfg file to find the rest of the application’s static assets. The app.cfg file format is still being specified; it’s purpose is to give Alice’s client enough information to find, download, and verify the application’s index.html file and other (possibly cross-origin) assets. Once Alice loads the index.html file via her browser, she proceeds to interact with the application as she would with a normal Web app.
Figure 3: relationships between Alice, Bob, and the new Onename application. Alice writes her data into a Dropbox folder meant specifically for her Onename application account data. Bob loads her profile by loading the HTML, CSS, and Javascript for onename.app via the onename.app owners’ designated storage provider (Azure) and then loading Alice’s profile from her Dropbox folder. The app.cfg file helps Alice and Bob discover the application assets.
The application interacts with user account information via a RESTful API implemented by a local Blockstack Core node (see Blockstack Core Architecture Diagram). Alice can POST and PUT data to her storage providers and GET data from the Onename owner’s storage providers. Bob can GET Alice’s public key, zone file, and profile, and then run client-side Javascript obtained from the storage servers to render the profile.
Legacy Compatibility
The beauty of this design is that in most cases, applications do not need dedicated servers. Developers should be able to simply push their application config and assets to their desired storage providers and add pointers to them in their application’s name’s zone file. Users store their app-specific data in their desired storage servers via creating app-specific accounts (which we help automate with a signup js library). If the application wants to serve assets from the legacy Web, it can do so per usual via CORS (the list of allowed origins is given via the app.cfg file).
Most client-side frameworks and JS libraries should continue to work as usual. We highly recommend that developers explicitly sign and upload all their application files or use sub-resource integrity attributes instead of just fetching data via the legacy Web, since Blockstack will ensure that they all were signed by the application’s identity keypair.