Standardize namespaces

Post Reply
davispuh
Posts: 15
Joined: Tue Jun 11, 2013 11:54 pm
os: windows

Standardize namespaces

Post by davispuh »

Namespaces (such as "d", "id" and others) are not owned by anyone and not even enforced what they represent as all those "specifications" are just guidance and they aren't really validated. For example anyone can register a domain with {"ip":"fake"}. In reality this isn't a big issue, but it means all applications must always validate it. But because domains are used (read) many times more than they are changed it makes sense to validate them when they are being registered. So my proposition is that firstly Namecoin API for commands such as "name_show" would return empty "value" field if that value isn't valid for that specific namespace. This would avoid from incorrect and invalid client implementations which for example would handle this values differently or maybe even for different purposes. Secondly, after some time (so implementations can be fixed and be ready for new behavior) miners/nodes should reject transactions and blocks which contain invalid values so that all new values will be valid. All previously created blocks with invalid values will be kept, but querying those names will return empty value field and will require that owner updates it to be used so eventually there shouldn't be any domains with invalid values.

My next proposition is that namespaces without specification are disabled until specification is created and standardized. It means that new transactions and blocks containing registrations for undefined namespaces (eg. "u") will be rejected and Namecoin API will return empty values for those if they're already created. Once specification is created that namespace will be enabled and values will be validated against it. Some might think that there's no problems if some random namespace is used by some app, but actually there's a problem. Because there's no purpose for that namespace it can happen that 2 independent parties independently create 2 different uses for that specific namespace and they won't be compatible. Same namespace, same field could mean 2 different things in different apps. It can be really harmful for users as basically it means they can use only one of application. This is also exactly reason why there's IANA and why it's useful for .bit to be defined so there won't be some different .bit TLD created.

And another proposition is for application specific namespace "a" (or "app"). It would be meant for application specific data and what that data represents is based only on application itself. So for example anyone can register their app such as I would register "a/myapp" for my application, so it proves that I'm application creator, I define data specification for it and others would have to use different name for their application. Everything after "a/myapp/" (eg. "a/myapp/something") and data itself would be application specific. For example some applications might use it as usernames such that I would register "a/myapp/davispuh", but for others it might mean something else. To summarize, if anyone would want to create their own different implementation of "id" they would just register "a/someapp" and then people would register their names under it. Preferably data format should be binary and wouldn't be validated in any way.

biolizard89
Posts: 2001
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Re: Standardize namespaces

Post by biolizard89 »

davispuh wrote:Namespaces (such as "d", "id" and others) are not owned by anyone and not even enforced what they represent as all those "specifications" are just guidance and they aren't really validated. For example anyone can register a domain with {"ip":"fake"}. In reality this isn't a big issue, but it means all applications must always validate it. But because domains are used (read) many times more than they are changed it makes sense to validate them when they are being registered. So my proposition is that firstly Namecoin API for commands such as "name_show" would return empty "value" field if that value isn't valid for that specific namespace. This would avoid from incorrect and invalid client implementations which for example would handle this values differently or maybe even for different purposes. Secondly, after some time (so implementations can be fixed and be ready for new behavior) miners/nodes should reject transactions and blocks which contain invalid values so that all new values will be valid. All previously created blocks with invalid values will be kept, but querying those names will return empty value field and will require that owner updates it to be used so eventually there shouldn't be any domains with invalid values.

My next proposition is that namespaces without specification are disabled until specification is created and standardized. It means that new transactions and blocks containing registrations for undefined namespaces (eg. "u") will be rejected and Namecoin API will return empty values for those if they're already created. Once specification is created that namespace will be enabled and values will be validated against it. Some might think that there's no problems if some random namespace is used by some app, but actually there's a problem. Because there's no purpose for that namespace it can happen that 2 independent parties independently create 2 different uses for that specific namespace and they won't be compatible. Same namespace, same field could mean 2 different things in different apps. It can be really harmful for users as basically it means they can use only one of application. This is also exactly reason why there's IANA and why it's useful for .bit to be defined so there won't be some different .bit TLD created.

And another proposition is for application specific namespace "a" (or "app"). It would be meant for application specific data and what that data represents is based only on application itself. So for example anyone can register their app such as I would register "a/myapp" for my application, so it proves that I'm application creator, I define data specification for it and others would have to use different name for their application. Everything after "a/myapp/" (eg. "a/myapp/something") and data itself would be application specific. For example some applications might use it as usernames such that I would register "a/myapp/davispuh", but for others it might mean something else. To summarize, if anyone would want to create their own different implementation of "id" they would just register "a/someapp" and then people would register their names under it. Preferably data format should be binary and wouldn't be validated in any way.
You clearly don't understand how Namecoin is designed. Namespace validation is supposed to be done at the nmcontrol level, not the namecoind level. It's not the Namecoin developers' role to tell people what data formats they can and can't store in the blockchain.
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

davispuh
Posts: 15
Joined: Tue Jun 11, 2013 11:54 pm
os: windows

Re: Standardize namespaces

Post by davispuh »

biolizard89 wrote:
You clearly don't understand how Namecoin is designed. Namespace validation is supposed to be done at the nmcontrol level, not the namecoind level. It's not the Namecoin developers' role to tell people what data formats they can and can't store in the blockchain.
I understand it in different way, this described way is how it should be implemented IMO. It's not just Namecoin developers responsibility, but also miner and user. With standardized namespaces they can decide which namecoin fork/implementation to use, like if they don't like some decisions, eg. new namespace's usage, they could not adopt it and stick to old one. But currently it's not possible and you've no control what does get stored in blockchain in your HDD, anyone can store whatever and it can have bad effects like I already mentioned, Firstly interoperability and secondly current design allows to grab namesapces, use insider knowledge and much more. Like for example someone have great idea about new namespace which will be implemented, it will be epic, groundbreaking but currently it's not yet fully implemented so anyway those develops or others who know about it can register those names in that namespace before others even could have heard about it. It's not even implemented in ALPHA, but people can already grab all good names, because there's no validation. There need to be enable switch so that everyone have equal opportunity, that is on release day and not earlier. There really are a lot of issues with current design, but I think I've already written enough, you need to start think wider.

biolizard89
Posts: 2001
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Re: Standardize namespaces

Post by biolizard89 »

davispuh wrote:
biolizard89 wrote:
You clearly don't understand how Namecoin is designed. Namespace validation is supposed to be done at the nmcontrol level, not the namecoind level. It's not the Namecoin developers' role to tell people what data formats they can and can't store in the blockchain.
I understand it in different way, this described way is how it should be implemented IMO. It's not just Namecoin developers responsibility, but also miner and user. With standardized namespaces they can decide which namecoin fork/implementation to use, like if they don't like some decisions, eg. new namespace's usage, they could not adopt it and stick to old one. But currently it's not possible and you've no control what does get stored in blockchain in your HDD, anyone can store whatever and it can have bad effects like I already mentioned, Firstly interoperability and secondly current design allows to grab namesapces, use insider knowledge and much more. Like for example someone have great idea about new namespace which will be implemented, it will be epic, groundbreaking but currently it's not yet fully implemented so anyway those develops or others who know about it can register those names in that namespace before others even could have heard about it. It's not even implemented in ALPHA, but people can already grab all good names, because there's no validation. There need to be enable switch so that everyone have equal opportunity, that is on release day and not earlier. There really are a lot of issues with current design, but I think I've already written enough, you need to start think wider.
I don't think you understand how dangerous blockchain forks and consensus failures are to blockchain-based currencies. Requiring a hardfork every time a namespace spec is updated is completely unworkable. It also makes it impossible to experiment with new features in a real-world setting.

I believe I speak for all core Namecoin developers when I say that your proposal as stated has zero chance of being implemented. I'm sorry if this sounds harsh, but you simply don't undertstand what you're talking about.
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

domob
Posts: 1127
Joined: Mon Jun 24, 2013 11:27 am
Contact:

Re: Standardize namespaces

Post by domob »

biolizard89 wrote:I believe I speak for all core Namecoin developers when I say that your proposal as stated has zero chance of being implemented. I'm sorry if this sounds harsh, but you simply don't undertstand what you're talking about.
I agree here. I see no chance to implement any validation of the data in the blockchain. For me, it is neither practically possible nor useful to do that.
BTC: 1domobKsPZ5cWk2kXssD8p8ES1qffGUCm | NMC: NCdomobcmcmVdxC5yxMitojQ4tvAtv99pY
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS
Use your Namecoin identity as OpenID: https://nameid.org/

midnightmagic
Posts: 18
Joined: Tue Sep 13, 2011 6:50 am

Re: Standardize namespaces

Post by midnightmagic »

biolizard89 wrote:
davispuh wrote:
biolizard89 wrote: I don't think you understand how dangerous blockchain forks and consensus failures are to blockchain-based currencies. Requiring a hardfork every time a namespace spec is updated is completely unworkable. It also makes it impossible to experiment with new features in a real-world setting.

I believe I speak for all core Namecoin developers when I say that your proposal as stated has zero chance of being implemented. I'm sorry if this sounds harsh, but you simply don't undertstand what you're talking about.
This is incorrect.

It can be done in such a way that the names as known can be blacklisted; that the core software will refuse to deal with the badly-formatted data; and that the core software will refuse to relay or even include such transactions in its mining mempool. The idea is a good one; it is merely suffering from a lack of knowledge. Ignorance does not imply the entire idea is wrong or incorrect.

tosh0
Posts: 43
Joined: Sat Mar 22, 2014 6:48 pm

Re: Standardize namespaces

Post by tosh0 »

i think the core software should treat the data as plain txt (or compressed in the future).
It is the task of the side-software (nmcontrol, others) to read this data and filter it.

The -qt gui is a mix of both, and it should enforce the data when entering domain data,
but the actual namecoind miner, or Namecoin API as davispush says when talking about the command-line,
should not check what kind of data is on the fields.

unless he means nmcontrol or others, then i agree, it should return only valid data for domain and names.

however blockchain explorers should be able to browse any raw text the user put in there,
and for that to get the info from namecoind is the only way...
NMC: more stable than BTC!

biolizard89
Posts: 2001
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Re: Standardize namespaces

Post by biolizard89 »

tosh0 wrote:i think the core software should treat the data as plain txt (or compressed in the future).
It is the task of the side-software (nmcontrol, others) to read this data and filter it.

The -qt gui is a mix of both, and it should enforce the data when entering domain data,
but the actual namecoind miner, or Namecoin API as davispush says when talking about the command-line,
should not check what kind of data is on the fields.

unless he means nmcontrol or others, then i agree, it should return only valid data for domain and names.

however blockchain explorers should be able to browse any raw text the user put in there,
and for that to get the info from namecoind is the only way...
I agree 100%. Part of Namecoin's awesomeness is its versatility. If you have a cool idea for a new field (or even namespace), you can test it in the wild. And while we'd strongly prefer that such fields/namespaces get standardized, allowing nonstandard data is an important check on our power. It's also useful if a company or group of people want to internally use a namespace without releasing it to the public.

Yes, midnightmagic is technically correct that you can add data checks to the IsStandard() function without affecting block validation. But I see no reason to do so.
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

Post Reply