Running a Namespace Versus Acting as a Subdomain Registrar

[jehunter5811]

I’m curious to get a rundown of the specific benefits to running a namespace (which I understand can then still allow you to run as a subdomain registrar) versus just running a subdomain registrar. Let’s leave the potential for accepting ID registration payments yourself rather than having those just be burned out of it because that’s an obvious one and one that I’m less interested in in the grand scheme of things.

[aaron]

This is inspired by pbj's breakdown on our Slack:

Subdomain Registrar

• Source of centralization: registrations can only be made by the domain owner (a.foo.id can only be made by the owner of foo.id) — so user registrations must be sponsored by the registrar
• Flexible pricing if the registrar wishes to require a (off-chain) payment before registering a name
• Names never expire, and updates to names can be broadcast by any domain
• Many registrations (> 100) can be batched together, making the on-chain unit-cost (paid by the registrar) of names very low
• Requires registrar infrastructure

Namespace

• Names can be registered by anyone, two-step registration prevents front-running of a name registration
• Price of names is fixed once a namespace has been created
• Registration fees are only paid to the creator during the first year of the namespace
• Each name registration requires 2 blockchain transactions, meaning the unit-cost of names is higher
• Name updates can be announced directly on the chain (they do not need to be broadcast by a domain owner)

[jude]

Price of names is fixed once a namespace has been created

Just want to elaborate on this. The application can implement a flexible name price after-the-fact by only acknowledging the existence of names that have paid enough money (e.g. the app code can deny sign-ins from users who haven’t paid enough). The on-chain name price curve is primarily meant to stop squatters, and to help developers quickly get a revenue stream early in their application’s lifetime.

[jehunter5811]

Registration fees are only paid to the creator during the first year of the namespace

Can you provide some clarification on this point @aaron or @jude. I know I said I wanted to leave the accepting registration payments topic out of the conversation, but this is news to me if I’m understanding this bullet point right.

Does this mean any new registrations to that namespace that come more than 12 months since the namespace was created end up in burned BTC? Or do those payments go somewhere else?

[jehunter5811]

Not to clutter my on forum post, but I’m also curious if there is a UI around this for the end-user yet. If I’m running a namespace, what does that actually look like when someone signs up for Graphite?

[aaron]

Does this mean any new registrations to that namespace that come more than 12 months since the namespace was created end up in burned BTC? Or do those payments go somewhere else?

Yep, after 52595 blocks, registration fees go to the burn address rather than the namespace creator.

If I’m running a namespace, what does that actually look like when someone signs up for Graphite?

Currently, there’s not support in our UI for this process-- when a user tries to register a name in the browser, they can only register within the .id namespace.

[jehunter5811]

Been talking with @patrick about running a subdomain registrar or a namespace to help the user onboarding experience, and we both thought it would be good to post my thoughts here so that any misunderstandings or incorrect assumptions could be addressed.

I don’t think I’ll be running either for the following reasons:

I don’t necessarily want IDs to be specific to Graphite. I want anyone with a Blockstack ID to be able to use the app. And yes, that’s possible while running a namespace or a subdomain registrar, but it requires two things:

1. Me to build out an interface for the registration process/auth process if someone is using a BNS id
2. It doesn’t actually have the benefit of quicker onboarding anymore than someone just registering a subdomain on the .personal.id space.

The subdomains issued of personal.id have that onboarding benefit and are universal to Blockstack and not controlled in anyway by me. They are basically the faster equivalent to a regular .id username.

I don’t plan to collect registration fees for ID purchases, and I already have a solution for enterprise feature control that utilizes existing IDs. Which is big for me. I don’t want an enterprise user who may have previously been using any Blockstack app to have to create a whole new ID just to be able to access those features. I get this conceptually, but I don’t think it’s necessary.

Would love feedback on my thoughts here…especially if I’m wrong about anything or missing hidden benefits.

[blockpac]

Many registrations (> 100) can be batched together, making the on-chain unit-cost (paid by the registrar) of names very low
Requires registrar infrastructure

@aaron @jude how can the subdomain registrar broadcast multiple ‘sponsored names’ in one batch? And how can an existing user’s Blockstack ID be linked to this (new) subdomain while still remaining active on its own?

Will functionality for these use cases become available through the CLI or the Blockstack Browser, or both?

@luckshas FYI.

[jude]

@aaron @jude how can the subdomain registrar broadcast multiple ‘sponsored names’ in one batch?

It can send up to 120 sponsored names per transaction. See the documentation here: https://github.com/blockstack/subdomain-registrar

And how can an existing user’s Blockstack ID be linked to this (new) subdomain while still remaining active on its own?

One way to do this is to have the user use their existing Blockstack ID to sign an attestation that says “this sponsored name is owned by the same person that owns this other name” and make it available to the application. @aaron, @larry, or @yukan would have good ideas about how to do this in the Browser.

[cryptocracy]

Names never expire, and updates to names can be broadcast by any domain

What happens if the primary name that the subdomains are registered under doesn’t get renewed?

[jude]

What happens if the primary name that the subdomains are registered under doesn’t get renewed?

The subdomains still resolve, and can still send update transactions (but not transfer transactions) via a zone file update from any existing on-chain name. However, to process a transfer or to create a new subdomain with the same suffix, the on-chain name will need to be reregistered.

(I’m trying not to call off-chain names “subdomains” because they have very different semantics from DNS subdomains. These off-chain names are more like email addresses that keep working as app user accounts even when the mail server goes offline).

[cryptocracy]

…These off-chain names are more like email addresses that keep working as app user accounts even when the mail server goes offline

[jehunter5811]

I’ve come full circle on this and wanted to share with the community. I am now running both a graphite namespace and a subdomain registrar. The reason turned out to be pretty simple—it’s sort of necessary to control permissions with enterprise users.

By having a .graphite namespace, each enterprise client will get their own root company id on this namespace (i.e. nytimes.graphite or wapo.graphite). Their users will be registered as subdomain ids of that root id (i.e. alice.nytime.graphite).

The root id domain (nytimes or wapo) mapping to the specific Graphite enterprise client makes loading that specific client’s permissions file simple. Those permissions then trickle down to each user as the client has specified.

Just wanted to come back to this post in case anyone was confused or on the fence about either namespaces or subdomain registrars.

[jude]

This is a really powerful use-case, and does a great job showing how to make the most of subdomains and namespaces. Many kudos to @jehunter5811 for writing this up!

[mabdou.id]

Hello all

I am asking if there is any technical documentation on how to start your .companyname subdomain and act as a subdomain registrar ?

[jude]

I would recommend looking at Blockusign for inspiration.

Technical overview: https://medium.com/blockstack-blog/blockusigns-pragmatic-approach-to-smart-contracts-anchoring-data-on-blockchain-using-blockstack-fb9bd974a306

Blockusign code: https://github.com/ntheile/blockusign

Subdomain registrar documentation: https://github.com/blockstack/subdomain-registrar

[nicktee]

I’m pretty much running a vanila subdomain registrar like here: https://github.com/blockstack/subdomain-registrar ,

I did not even purchase my own top level namespace. I simply purchased blockusign1.id and put all my subdomains under that, like name1.blockusign1.id

Really the “hardest” part is generating a public private key pair and sending bitcoin to it to fund the subdomain registrar.

[mabdou.id]

Really the “hardest” part is generating a public private key pair and sending bitcoin to it to fund the subdomain registrar.

Can I ask for more technical details about it and how you passed this difficulty ?

Thanks

[nicktee]

aaron explains how to generate a separate keypair here:

Obtaining Identity Keys from the Browser

The “trick” I use to get the identity key out of the browser is to open the javascript console and enter the following: var ix = 0 var reduxState = JSON.parse(localStorage.redux) var state = reduxState.committedState[reduxState.currentStateIndex] // get the 0th identity address state.state.account.identityAccount.keypairs[ix].address // get the 0th identity key state.state.account.identityAccount.keypairs[ix].key + '01' That gives you the ownerKey of the 0th-index account in the browser. To ge…

Obtaining Identity Keys from the Browser

To get a payment key, I always just generate a new one for a subdomain registrar. There’s many different ways to generate a private key and bitcoin address, but I usually just use node and bitcoinjs-lib . So, from a directory with bitcoinjs installed (just create a new directory and run npm install bitcoinjs-lib ), run node and then these commands will make a bitcoin address and private key string:

var btc = require('bitcoinjs-lib')
var paymentPair = btc.ECPair.makeRandom()
var paymentAddress = paymentPair.getAddress()
var paymentKey = paymentPair.d.toHex() + '01'

To fund that paymentKey, you can just send bitcoin to the paymentAddress.