Namespace Creation & Stewardship

Community
, , , ,
#1

Hey Everyone,

After reading the release notes for 0.17

It indicates the details about Namespace Creation.

“Namespace creator receives register and renewal fees”

It then goes onto describe the context of how the creator will receive the registration and renewal fees.

“The namespace creator will collect all fees starting from the block height of the NAMESPACE_REVEAL, and ending to 52595 blocks later (about 1 year).” … “After this period of time passes, name registration and renewl fees are sent to the default burn address 1111111111111111111114oLvT2.”

Which honestly did leave me a bit confused about the situation, because in essence this would imply that as a namespace creator you are not the Owner the namespace, but rather you are more of its Steward.

@ryan indicated that the logic in the decision here was to help prevent namespace squatting. Which is fair. After all it would be kind of stupid for someone to register say .facebook and expect to be paid for the registration of all names into infinity (looking at you Zuckerberg lol)

However after thinking about the situation I had two concerns that the average developer like myself would probably also have (hence this post)

  1. If I (dapp dev) only receive registration fees for the first year after namespace creation, won’t this basically mean my dapp will have to go viral if I expect to make a decent living off the time invested in its development?
  2. If I (dapp dev) can no longer depend on long term recurring revenue based on registrations won’t that lead me to seeking a conventional method of monetization such as advertisement (not entirely bad, just not ideal since its riddled with problems in todays landscape and in essence would lead the dapp developer to care more about the advertisors and their concerns rather then the user bases, if FB and YouTube are any example)

@ryan did indicate that if namespace bidding were implemented then this restriction is no longer that important.

I suggested a good compromise would be to build in a calculation that lets the creator of the namespace determine how long they wish to provide Stewardship for the namespace with a max of like X years, and then have that help determine the cost, also obviously have the rarity/length factor be calculated in too.

@ryan seemed to agree that combining that plus the namespace bidding would be a good setup.

This post was created to make sure the community has a dialogue about this, since this may not be completely self evident and deserves to be debated.

3 Likes
Messaging for Developers + Incentives
#2

Thanks for starting this discussion @cryptocracy! I think there are some really interesting incentive mechanisms at play here. The model will likely evolve as we get more community discussions going and as the native Blockstack token gets ready (it has some properties that lets you have more expressive conditions around namespace creations and registrations fees going to creators/stewards).

Looking forward to following this discussion on the forum.

1 Like
#3

@muneeb I look forward to this discussion as well, hopefully details around the Token help put things into greater perspective around how the developer community has viable monetization options, short and long term, that avoids centralized advertising models.

Thanks!

1 Like
#4

How will owned namespaces be effected by changes in purchase rules - say from current algo to auction based?

Also, why not just restrict namespace registration fees to burning only? One time sign up fees for apps is not a great revenue model for developers. It would also remove the complexity of trying to answer cryptocracy’s great questions above. And strategic squatting would become less appealing. Anyway, Nice points @cryptocracy.

#5

Came across this and the concepts piqued my interest but I’m missing the foundation for how namespaces work in the first place. Maybe it’s obvious to those in the loop, but hopefully I don’t sound too ignorant in saying; in what context would a user of a dapp need to register a name under a namespace, thereby supporting it’s creator. Is there an explanation of this relationship in the docs somewhere?

#6

Hey @Teeks,

The thinking behind this namespace design is that application developers can programmatically incentivize or require users to have names in a particular namespace to get at certain application features. For example:

  • Suppose I created a .docusign namespace, and then wrote a docusign-workalike that only worked if you sign in with a .docusign name. In this example, a name serves as a transferable software license key.
  • Suppose I created an image-sharing application and a .images namespace, such that if you signed in with a .images name, you got access to extra in-app features (this is a manifestation of the freemium model).
  • Suppose I created a Cryptokitties clone called Cryptodoggies. As the app developer, I could have names in the .cryptodoggies namespace correspond to cryptodoggies. My app would have a custom resolver that would interpret names and their associated metadata as “genes” so each name would render as a particular dog. I would use registration fees from the .cryptodoggies namespace to pay for keeping the resolver online.

(This sounds like a good thing to add to a developer guide.)

2 Likes
#7

Thanks @jude - That does help a lot and I think it would make a good developer guide.

Still a little hazy on how the names are assigned / sold to users by a dapp owning the namespace. I can see how the concepts work as component parts, but having trouble visualisation the user experience for registering an account and creating a name with the required transactions.

Will the names be shown in their account’s Blockstack Browser e.g. at /profiles?

The name is added to their public Blockstack ID records (yes? - or is it under a specific scope), so would that mean an extra back-end step for the auth process to take, when the response token comes back, to enforce that the user has a name for the required namespace?

Is there a working example or open source app that does this currently?

#8

Will the names be shown in their account’s Blockstack Browser e.g. at /profiles?

Yes. You register names through the Blockstack Browser, and use them to sign into the application. That way, the application code can tell whether or not you have paid for a name, and grant you access to whatever features that name enables.

The name is added to their public Blockstack ID records (yes? - or is it under a specific scope), so would that mean an extra back-end step for the auth process to take, when the response token comes back, to enforce that the user has a name for the required namespace?

Yes—it’s a public name. For example, I could own the name jude.docusign. If I use it to sign into the Docusign-workalike, then the Docusign application loads the features that I paid for by registering jude.docusign. If I used a different name (like judecnelson.id), then the application would tell me that I need a .docusign name to access all of the features.

2 Likes
#9

Great. Thanks for all the explanation. This is a really important concept (and motivator) for developers. I think it would help a lot to have a doc covering the end to end process, as it’s fairly esoteric for devs coming from outside the blockchain community.

#10

Hey @jude,

I’m also new to Blockstack, so this discussion was really helpful to understand how the namespace creation process works.
An additional question: (how) would subscription-based apps work on Blockstack?
If I understand this correctly, the current model works on an ever-growing userbase for each app if that app owns a namespace, right? But owning a namespace requires substantial up-front investment, so unless I’m able to purchase a namespace I’m kinda on my own, if I understand this correctly.
Maybe this question has been answered before somewhere, but I didn’t find this explained anywhere so far, so I’d be super interested in how this works :slight_smile:

2 Likes
#11

Do we have any new information about the mechanics and constraints of namespace creation?

Should we expect more info about this process after the stack token goes live?

Tagging you @jude

#12

Hey @cryptocracy, sorry I missed this.

The way to create a namespace isn’t too different with the Stacks token; all you’d do is set the version to 3 so as to require Stacks to pay for the name instead of BTC. Version 3 namespaces require the user to burn Stacks to create a name.

The pay-Stacks-to-namespace-creator feature is on the roadmap, but it will be added after the Stacks token goes live. Will post a roadmap once I know the dates of a few things with greater certainty than I do now :wink:

1 Like
#13

For example, I could own the name jude.docusign. If I use it to sign into the Docusign-workalike, then the Docusign application loads the features that I paid for by registering jude.docusign. If I used a different name (like judecnelson.id), then the application would tell me that I need a .docusign name to access all of the features.

Not sure if this is implicit in your answer, but it would be great if you could sign in with judecnelson.id and tell an app that you have ID jude. to get those features with your judecnelson.id (kind of like an association token). The notion of signing in will a host of different IDs seems like it might get cumbersome, especially for data sharing between them (though I think about that challenge a lot).

#14

This sounds more like a special case of multi-signin to me :wink:

1 Like