RFC - Decentralised Naming System

RFC - dns

Feature Name: Decentralised Naming System (dns)

Related components: maidsafe_client, maidsafe_vault

Summary

In the current Internet Domains are referenced via a naming system which comprises an indexing mechanism This indexing mechanism is centralised and controlled, with the ability for countries and ISPs to switch it off pollute data with advertising data and much worse. The SAFE network on the other had offers a ‘free (as in beer)’ mechanism to locate data linked to a name. This proposal outlines a mechanism to look up data related to any name.

This data includes, long name (could be real name is users wish), web site id, blog id, micro-blog id and may be extended to include additional information as the network develops.

Motivation

In networks people expect to be able to lookup services related to names. In the SAFE network this includes the ability to retrieve public keys to encrypt data to that id, in cases where privacy is a requirement (.e. in SAFE all messages are encrypted between identities). The opportunity for people to create and link web sites and other services is also a motivation for implementing such a system.

Detailed design

This is a simple use case for Unified Structured Data (see RFC XXXX). In this case we require to set three items

The type_tag shall be type 4

The Identity shall be the Sha512 of the publicly chosen name (user chooses this name)

The data field:

struct dns {
long_name: String
encrytion_key: crypto::encrypt::public_key
// service, location
HashMap<String, Identity>
}

Initially this HashMap will likely contain www, blog and micro-blog. Application developers may add services to enhance users experiences with new applications and functions via this mechanism.This is very likely to extend as the services on the network grows.

To find this information an application will Hash(Hash(public_name) + type_tag)) and retrieve this packet.

Drawbacks

None found at this time.

Alternatives

Alternatives could be clients, passing this information via a series of messages, but this requires both parties being on-line or able to wait for each other to come on line.

Unresolved questions

Should this struct contain the actual public_name (handle) as this may allow some indexing mechanism, which is prevented with this design (on purpose).

This prevents two identities using the same name, is this really the best way to go. This is more like twitter than facebook in approach.

12 Likes

Holy smoke! One of the ramifications of this is that it can provide the distributed DNS service for the WWW that Namecoin and other decentralized DNS efforts have been trying to do. All that’ll be needed is to be running a SAFE Client to interface the system. No weighty blockchain, duplicaton of effort, etc. Brilliant.

Talk about another adoption motivation!

9 Likes

long_name: String

Is that string unrestricted use of UTF-8 or is it to be similarly limited as the unSAFEnet urls? If it’s unrestricted, then that allows flexibility but is that to a point that might allow spoofing of addresses and names?? Those wanting to degrade the SAFE experience for users might attack the user experience through that route?

Obviously, strings that allow normal url characters will be easier for all users to relate to; those normal urls forms will also be easier to communicate; and might be more appealing to those looking to make a switch from the unSAFEnet.

DNS suggests domain names are unique?..
If unique, then is there a risk of name squatting and how can that be managed??.. default cost on names that match existing urls???
If not unique or if UTF-8 unrestricted, how does a normal user know which version of a name’s content they are looking at??

How will SAFE declare itself?. How will users know that they are within the SAFE network? Something like SAFE://some.dom.ain/ might require browser integration?? Are we expecting initially to see https://maidsafe.net/SAFE/abc … and will that hit some limitation on URLs, if only for the %20 encoding that sometimes occurs for non Western characters.

re unresolved questions:

Should this struct contain the actual public_name

I’m tired atm but I think not… while communication of public data by default is useful, is should be weighed against having power and control remain with the data’s owner - if another user takes ownership, they it’s theirs to act on. Another Google we don’t want and perhaps not having the public_name will allow users to submit to indexes or pages they prefer. Those might then become indexed themselves but perhaps that first option on new data, will matter in some way? I don’t know, sometimes when it’s hard to anticipate users, it is best not to and then better to do less rather than well-intentioned more.

Obviously, it is most important that the user has a consistent experience with use of any public name they encounter and that it cannot be spoofed - which again returns a question about UTF-8 character spoofing.

1 Like

Brilliant, isn’t it? Once the hard part of creating the global network address space has been achieved, so much other stuff becomes easy to do on top.

Static files become super easy to download, making HTTP/S, FTP, BitTorrent etc obsolete from pretty much day one. Why bother, when you can just download the data using native addressing?

Moreover, with the new data types combined with the messaging functionality, things start getting very cool - you get actual digital property, stored with a globally unique, immutable, address. In short, a chunk of data can literally only be owned by a single person, for data types where that matters. That is utterly ground breaking and makes the blockchain approaches to do this look crude!

I suspect leveraging the messaging layer, to alert different nodes of changes will lead to truly distributed databases and applications too. Being able to tell shop that your order is saved at a secure location of your choice, allowing them to pull it, puts a whole new spin on distributed storage - why send them the payload, when they can just reference it anyway? This also results in the client doing the processing, allowing massive scalability.

In this new world, the very concept of client/server is challenged - when every node is both a client and a server, it is a different ball game.

Amazing stuff!

5 Likes

Thanks. I’m just beginning to absorb a very tiny part of the potential that I sense is there, and get hints at from David, Ben and others (now you included).

1 Like

There was talk of potential for Namecoin to be used for copyright of text and quotes. I don’t know whether there is an option to make that available too; so, not just the whole file that’s acknowledged but any parts of it too… perhaps that can become part of some markup later.

With the safe network, you could actually put the whole data file on the network. As the data chunks themselves are addressible via the hash of their content, it should be possible to get a date stamp of when file was submitted.

This has the advantage of having the content in the same place as the registry, with both being distributed. Useful for copyright claims, etc.

Maybe there should also be an exclusive name, ideally with a pricetag attach to it (and the funds goes to the Maidsafe Foundation) :stuck_out_tongue: , the same name dissapears when you, imagine what is possible without a exclusive name:







.google

All the names above could be register in this DNS system. But with an exclusive name scheme google becomes the moniker and all the other names above redirect to it or is under google’s control. So your basically making everything between the DOT exclusive. I realize that the exclusive name is also a disaster in some cases, for instance if some one registered crypto, a site like crypto.cat woulden’t be able to take crypto.cat. But they could just use cryptocat, so it woulden’t really hurt much. An exclusive name scheme also seems more attractive compare to what’s happening on the current internet.

How would Coca Cola want it?
coca-cola
cocacola

If we ever want brands and superstars on board, we should get in their train of thought.

1 Like

The way you present this makes it appear that it would only be more attractive for name squatters… and no-one likes them… leeching off other people is not a useful contribution.

Flexibility is more attractive than creating artificial limits to satisfy notions of greed… you present this as for the Maidsafe Foundation but how would it not be all profit to the name squatter that grabs them first? BitShares already suffered a run of that nonsense from some dull namewhale.

Having such exclusive names, as you’ve suggested before, seems like a liability. If there are multiple substantial interests with the same names, why not just allow them all to be happy? If they want to register multiple instances to map onto their nonSAFEnet urls, they can do that… if the SAFE names allow that normal format as suggested above.

If there is to be an exclusive name offered that would need managing, the simplest way I can think of is allowing only those who can prove ™ in a standard domain like (.uk) and that still seems like a headache. The alternate is to make the price across the board so expensive as to make name squatting impractical but that just creates an answer to an anticipated problem, which is always a bad idea.

Perhaps if user can prove ownership of nonSAFEnet url, then they can get the SAFE url for free or set fee… something that strips out the risk of it becoming contentious. That could be done with them adding a http header or file to their site, something like OpenID does.

I know that I’m presenting this like a stoner, well then let’s make it unattractive for name squatters. Let’s price a exclusive name at $100 K, after all that’s the minimum that companies are willing to pay Icann for a gTLD. Problem solved.

I’m not really worried about another man/woman who is a community member’s profit, money is not everything, but if a little profit can make Maidsafe grow (software/hardware/enable education) that’s the only thing that interests me.

Then you like my idea above?:

A set fee … a small one over many urls would potentially generate a lot of money directly to maidsafe and avoid the unsavoury name squatting.

I’m against selling names, the current scheme seems sufficient to me. If people want to get rid of the additional numeric identifiers, DNS-like systems could be build on top of the network, where lists of names (without the numbers) are attributed to the “correct” party. This could be done through a voting system, or by a trusted party. If the list is useful, it will become popular and generate some income (from the network and SafeCoin donations).

5 Likes

I was thinking this the other day too. These names could ultimately just become addressible IDs, much like IP addresses in the long run.

It may be that people will want particularly IDs and will pay dearly for them, but they would become more like vanity addresses with a regular resolver over the top.

That said, this is a subject which care needs to be taken with. Clearly, individuals benefiting from the efforts of the devs and investors doesn’t seem very fair and it would seem more equitable for that profit to be reinvested into safe net.

If big money comes in for registering names, I would like to think that some combination of developers, miners, users should benefit from this. It would help the network to grow and would be less susceptible to accusations of blackmail etc.

1 Like

I think we should set up a service that doesn’t include paying for names. Let the most well-known party under a particular name get that name. If google starts some sort of service on SAFE, they can just register their google-XXXXXXXXX (with X’s being numbers) ID in the core. The service that runs on top of SAFE, would then resolve simply “google” to that particular google-XXXXXXXXX ID.

My point is, for the vast majority of names it is very clear who is the “real”, legit party. Everyone associates “google” with the company that got founded in California in 1998. It doesn’t make sense to require payment to get this generally accepted association working in SAFE. For small companies that have the same name, let it be a popularity contest. The loser can always change or adapt their name, which is generally a good idea if there’s a bigger company with the same name already.

I think if we do have payment for exclusive names, the SafeCoins should be destroyed and recycled. Let the network take care of the re-distribution. This is good for circulation and network growth. Both farmers and app developers will profit from it.

1 Like

I had the same idea a while back, but it would just be wasting time, because if you got multiple domains you have to proof them one by one.
www.google.nl
www.google.eu


www.google.in

With an exclusive name all these names would just be under the google umbrella.

I’m sorry Seneca, but I have to totally disagree that it doesn’t make sense to require payment. When I look at what Icann is asking right now for a gTLD, I wonder why it woulden’t make sense if the Maidsafe project ask to same price so we can further grow the SAFE Network.

If Google would want the gTLD (.google) they would have to pay Icann a minimum of $200 K, they would even pay ANNUAL FEES. Until now I haven’t read something about a renewal fee with the SAFE DNS system. And the thing is, Google is ready to pay Icann this in a heartbeat. Why would we the Maidsafe community NOT WANT this money to come into the SAFE Network economy? People seem to be afraid of big money and have the idea that something is unfair. The reality is not Icann or Google or any of these for profit companies care about the Maidsafe project. Take a good look at Namecoin, big companies laugh about their dot bit domain. Well at least if some one would pay for a SAFE DNS it would have it advantages.

Having a DNS that funds the Maidsafe project, is way better than us having to beg for donations. Just having the SAFE Network software in our hands is not gonna let it take off like a rocket. We’ll need money to promote the SAFE Network, educate people about it and open up new doors.

I’m puzzled at why that, instead of handing this to the Maidsafe Foundation. Maybe if people don’t want all the SAFEcoins to go to the Maidsafe Foundation, maybe it would be an option to donate to SAFE Network projects (kickstarter style). No offence, but if we don’t have a paid DNS system which insure the further growth of the SAFE Network, maybe we’ll have a longer road to travel. Not that I mind the long road, I’m in this Maidsafe thingy for life.

1 Like

I really like the idea of being able to map existing registered domains to a specified share, simply on the basis of ease of adoption by the general public. Current regular internet users could easily be redirected by websites at http://domain.com to safe://domain.com (given adequate browser support) in a seamless way that uses conventions they are already familiar with.

Web developers could also call resources from their safe://domain.com/ stores within pages on their http://domain.com hosted web pages.

The only technical challenge (which is not so challenging) is matching up that requested resource name with the right SAFE share (a lookup), and verifying in the other direction that the share owner has rights to the registered domain name (by already common methods of text file in web root or hash info in html headers.)

There would be no need to create additional registries, just verification on one service of ownership on another service.

I also think such lookup would require UTF-8 as international characters can now be used in registered domain names.

1 Like

The MaidSafe Foundation is a point of centralization, and I think we should keep centralization to a minimum. Destroying the coins would indirectly increase farming rewards, decrease upload costs, and combat inflation at the same time. It’s definitely good for the network.

2 Likes

I thought David made a comment in the past, that at some point the devs would be on different locations. So maybe the Maidsafe Foundation could also be on different locations (yeah I know it would still be a building with people who can be arrested). But every problem can be solved, if we got enough ideas.

What if we could have a new multisig scheme (2 out of 3)? For instance one in which the Maidsafe Foundation would sign for 33 1/3% and the other 66 2/3% would be signed by the SAFE community. What would make this multisig scheme new is that it would randomly pick community members and further break up the pieces of a key.

The first signing key could be known by all the Maidsafe Foundations around the world
The second signing key, could be 10 trusted community members like the mods of this forum. Their signing key could have a (7 out of 10) scheme, that further breaks their signing key into pieces.
The third signing key, would be the real messy key. It would just randomly pick 1000 community members with a (700 out of 1000) scheme, that further breaks their signing key into pieces. This key scheme would be time based, so if you don’t sign in time another community member would be randomly selected. People who would sign the third key could also get a small donation of SAFEcoin for their work. Time based could also mean another thing, that you’ve been using/on the SAFE Network for a certain period of time, like 1 year minimum.

The first and second keys seems like the weakest links in this setup, because these people are known. Maybe the third key should be a maverick and have the special power to release all the funds to all the community members, if the first and second key holders are arrested. Maybe the whole signing of funds should be time based.

2 Likes

I’m simply not a supporter of the concept. It takes the A out of DAO, making it a DO process. The autonomous part of the network is key in my opinion.

As far as SafeCoin is concerned, I see the SAFE network as a (de)Central Bank. It has special powers none else has (issuing SafeCoin) and thus executes a form of monetary policy. Like a Central Bank’s mandate often is long term growth of the national economy, SAFE’s “mandate” is doing the same for it’s own ecosystem, algorithmically. I don’t think we humans should directly interfere with this. It gets messy and unpredictable. So all payment for SAFE’s services, whether it be secure data storage, distributed cloud computing, or exclusive domain names, should get into SAFE’s own coffers, i.e. destroyed to be re-issued later, according to what the network thinks the network needs.

12 Likes

Wow amazing! Thanks for taking the time to explain it.
Because what your saying seems more logic, compare to what I was saying.
Some idea’s really takes getting use too.

5 Likes