What is a Blockstack Namespace, and Why Does it Matter?
Graphite just launched the .graphite namespace. But what does that actually mean?
Authentication is a solved problem in the centralized world. oAuth from any number of centralized systems—Google, Facebook, Twitter, etc—makes logging into an application extremely easy and extremely insecure. By logging in using one of these options, you are very often giving permission to the underlying software (not always just the app you’re logging into) to view information about your activity and profile. And, beyond that, you simply do not own the identity you are using to log in.
Decentralized identifiers (DID)solves this. Self-sovereign identity is the idea that each individual should own all aspects of their identity. This includes official records, proof of existence, login options, etc. Self-sovereign identity is made possible thanks to blockchain technology and decentralized identifiers. Blockstack authentication is a WC3 compliant DID, meaning that while Blockstack creates a simple interface for creating an identity, they do not own that identity. The apps built on Blockstack, like Graphite, also do not own that identity. The fact is, any person in the world can register an identity using the protocol developed by Blockstack (even without Blockstack’s intervention), and they will own that identity. It becomes a verifiable, immutable record that anyone can find.
For example, take a look at this bitcoin blockchain transaction:
https://blockexplorer.com/tx/cfaeb5c3e6de524ea99de64e826d2d3ec6a7a552d52217c9e73b7630625dee1a
Every name registered includes a public transaction ID that can be used to query the blockchain ledger. While that transaction confirmation may not look like much, it matches the transaction ID found here:
And because of this, anyone looking to verify an identity, can conclude that the information being passed to them is valid and associated with the name and ID or record.
How does this relate to Graphite and running a namespace on Blockstack? First, it’s important to understand what a namespace is. For users first coming to Blockstack, they are able to create a temporary ID. Users are able to also create ID with usernames of their choosing attached. These names are written to the blockchain ledger and become publicly verifiable. They also enable additional functionality within apps because they are publicly written to the blockchain, but that is for another discussion. The default namespace for Blockstack is .id. Think of this as the traditional web’s top-level domain system. You register a website at yourname.com or yourname.org, etc.
With Blockstack, users can register a name in any namespace that’s been created. And anyone can create a namespace. So, Graphite created the .graphite namespace and made that namespace public yesterday. This means, anyone who wants to own a name in that namespace can do so. But more importantly, this namespace enables decentralized permissioning in Graphite’s enterprise plans.
In the centralized world, permissions are simple. Crack open the database, look at user records, apply permissions as necessary. In a decentralized application, user data is not accessible. Therefore, conditions must be written before a user ever visits the app—before the user even exists. Addressing feature controls and policy settings for individual customers that trickle down to the employees and associates of that customer is difficult in a zero-knowledge application. But the .graphite namespace makes this much easier.
It will be possible now for the application to query a permissions file that is inextricably tied to root user account the customer creates. Then, any users added by the root user account will automatically have the permissions file applied.
Let me give you an example. Let’s say Buzzfeed wanted to move its newsroom operation to Graphite (and hey, Buzzfeed, you should do that!), they might register a buzzfeed.graphite identity on the .graphite namespace. They might then add users like shawn.buzzfeed.graphite and erica.buzzfeed.graphite. And they might set permissions that need to apply individually to these users or in bulk to a group of users. That all is beyond Graphite’s control because Graphite cannot access any of Buzzfeed’s data. This is where the namespace and pre-written logic can help out.
Because the buzzfeed.graphite root username exists, it’s possible to apply permissions set by that “super administrator” to all users added to the Buzzfeed account. When erica.buzzfeed.graphite logs in, her username alone is enough to identify the correct encrypted permission file, decrypt that file, and apply proper features and permissions.
This is something never done before in enterprise software—100% decentralization without limiting a customer’s ability to control their newsroom’s or business’s administrative settings.
This is now available for any enterprise account. Graphite will be publicly launching the first full enterprise feature-set—Graphite for Journalism—next week at the Oslo Freedom Forum, but if you’re a business, a newsroom, and NGO, or anyone interested in data security and user privacy, let’s chat.
