Value Data Format

Post Reply
teddziuba
Posts: 1
Joined: Tue Apr 08, 2014 3:54 am
os: mac

Value Data Format

Post by teddziuba »

I'm just getting into Namecoin now, and I think it's a great project.


One thing that I think could be improved is the choice of data format for the values. Right now, it looks like we standardize on JSON by convention, and I think this will hold Namecoin back as it grows, because JSON is not an extensible format.


By extensible, I mean extensible to new types. For example, how do you encode a date in JSON? Usually something like this:

Code: Select all

{"createdAt": "2014-04-10T17:49:36Z"}
Or, you could use a timestamp:

Code: Select all

{"createdAt": 1397152067}

Both of these will work, but the problem is that any consumers of this data must learn how to process these out-of-band. You go look up somewhere in the documentation, on the wiki, that the "createdAt" key is actually a UNIX timestamp, or an ISO-8601 formatted date string.

In the small, that is fine, but in the large, it falls apart, because you can't have useful generic processors. I think that when building a foundational platform like Namecoin, the ability to generically process data is key to success.

Right now, Namecoin encodes IP addresses as strings, for example, the keys being more or less agreed upon out-of-band. But a string is a string, and an IP address is an IP address. If you write a piece of code that scans over names in the blockchain, how does it know it's looking at an IP address? Look at the key? A regex? Out-of-band specification of data types doesn't scale as an application platform.

I propose looking at an extensible data format, EDN for example. You could specify a DNS record like this:

Code: Select all

{ :ip #info.namecoin/ip {:version 4 :addr "192.168.0.1"}
  :ip6 #info.namecoin/ip {:version 6 :addr "2001:4860:0:1001::68"}
  :email #info.namecoin/email "user@example.com"
}
The point being that

Code: Select all

info.namecoin/ip
is a namespaced type, and any reader that understands the rules of the EDN format will be able to read it. It may not understand the full semantics of the type, but it can generically process the structure, and know when two different entities are of the same type. Same type + same value = same thing.


A namespaced, extensible format like EDN makes Namecoin a much more scalable platform. By scalable I don't mean "able to handle a lot of users", I mean that the platform can scale easily to new application participants. New participants can create new types, and can work with existing types generically.


I really believe in Namecoin. I think it's a fantastic system. It's the platform for blockchain-based functionality.


Ted

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

Re: Value Data Format

Post by biolizard89 »

I don't claim to be an expert in this particular topic, but how exactly would the tagging of e.g. IP addresses be helpful in practice? If an implementation knows about a particular namespace, then it should be able to handle it regardeless. If an implementation doesn't know about a namespace, then why would it need to process it at all? I don't see much practical benefit.

But, I could easily be wrong. Can you provide info on how I might be overlooking something?
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

Post Reply