RFC - Decentralised Naming System

Wouldn’t this namespace also end up a bit chaotic?
The existing DNS is hierarchical making it easier on humans.

I appreciate the need to raise funds. I might even secretely dream of working for the foundation :slight_smile: So I do want it to have money even if that dream (most likely) never comes true. So what I’m trying to do here is to balance the need to raise funds against a design which in my view might deliver the best value to the humanity. Please see above…

[quote=“catbert, post:23, topic:4235”]
There can still be one official high level naming system run by MadeSafe foundation itself. Names in this system can be sold for money. This naming system will come preconfigured on safe browser at installation time which hopefully will make it popular enough for organisations to pay money for registration.[/quote]

This was my best shot so far in trying to satisfy both needs. In this official namaspace the foundation can enforce whatever policy it deems sensible - for example remove names of fraudelent sites, perform dispute resolution between trademark holders etc Might running such a namespace actually end up being a better business mode?

Another angle: imagine a legal dispute about arises.

Under the current proposal: the Foundation sold name ABC to DEF but GHI wants for itself and sues the Foundation. What does the Foundation do? Does it even have the technical means to reverse the grant of name ABC to DEF? Or has it gone into Bitcoin style block chain and can not be undone? Does the Foundation need to pay the penalty to GHI?

Under catbert proposal: firstly there are multiple naming systems, most of them not run by the Foundation - so Foundation has no responsibility for what they do. If however Foundation has granted ABC to DEF in its own official namespace and GHI wins a court battle the foundation can easily give ABC to GHI because under this proposal the naming system is not something built into the core of the network but a simple app like a relational database running on top of it.

Also if the naming service is not something built into the core of the network but an app the foundation can spawn a separate legal entity managing the official namespace. This entity would pump proceeds back into the foundation but in case of a legal case it would shield the founcation bearing all the responsiblity itself.

… and should this extra legal entity collapse of a judicial brutality that won’t do that much harm to SAFE network. Okay the Network will loose its most popular naming service but then it will be very soon replaced. This organism should survive the death of any of its parts!

I don’t think I want the Foundation to take the role of ICANN, that’d be a point of centralization and a thus a vulnerability. The Foundation members can be pressured by government agencies, their keys can be lost or stolen, etc. No SAFE functionality should be dependent on the Foundation, ideally it should only fulfill an advisory role for development and the community.

If I remember correctly the network itself has a reward scheme for developers who release SAFE software updates that actually get adopted. If that works, we don’t need the Foundation for dev funding.

I’m not principally against payment for domain names, but then the SAFE network itself should be paid. Coins used in such payments would then be recycled (destroyed and later re-issued to farmers etc) by the network. This would make SAFE far more robust economically, because right now continued farming rewards rely solely on income from data uploads. Creating more sources of income for the network should be an important goal, and DNS is a good candidate.

4 Likes

This is an important point. The foundation should not control DNS for the same reason it should not control user names and passwords and Safecoin. The more autonomous the network is the better.

1 Like

It wouldn’t.

In my proposal it merely sells fancy aliases (in line with those proposals who want to add aliasing).
All native addresses (alphanumeric SAFE equivalent of biy0wp6edsf.onion) would be usable at all times and continue to work independently of the alias system.

The overlay system is what was proposed by Christopher in RFC - Decentralised Naming System), that is the part that I’d put up for auction if people really need user friendly host names (personally I don’t see a need for it).

A decentralized organization is always a bit chaotic because there is no benevolent dictator who could impose order from above. (Example: the current maximum Bitcoin block chain size debate).

I explained this in another topic (also related to SAFE name resolution): there is no better value for the poor than when the rich subsidize SAFE Network for them (by buying/registering highly desirable name aliases).

I moved 194 posts to a new topic: RFC - Decentralised Naming System II - continuous auction (by Seneca)

Sorry about the tin foil hat rant, but let’s talk in the realm of reality. When the network guess live, I take the week off. I run my node and start registering names. I start with all three letter combinations ie. ABCThis is a classic example of the tragedy of the commons.

Add:

3 letter word = 17,576 possible combinations

After messing around with the DNS example in this week’s update, I figure I can register one name every two seconds. If I take a 15 minute break every hour, that means I could register 1,350 names an hour. If I register names eight hours a day, it would only take me two days to register all names with a three letter combination.

What do you mean with the last sentence? This isn’t TOR, you don’t need to keep a node/server online to have your domain/website to persist.

[quote=“janitor, post:31, topic:4235, full:true”]
In my proposal it merely sells fancy aliases (in line with those proposals who want to add aliasing). All native addresses (alphanumeric SAFE equivalent of biy0wp6edsf.onion) would be usable at all times and continue to work independently of the alias system.

The overlay system is what was proposed by Christopher in RFC - Decentralised Naming System), that is the part that I’d put up for auction if people really need user friendly host names (personally I don’t see a need for it).[/quote]

@janitor, I do understand.

So long as the biy0wp6edsf.onion is supported anything can be built on top. Good.

On the other hand we may need to be very careful. If you decree now that there is a single global namespace then this is what is going to get encoded in SafeBrowser and other software:

  • web pages will link to each other via aliases
  • web services will use aliases for endpiont information
  • aliases will be printed in newspaper ads

There seems to be a lot of debate on how to replace DNS.
First-come-first-served? Auctions? An LTD feeding money back to Foundation?

Wouldn’t it be wise to leave the door for future open? To test alternatives in real life?
We’re software people, we know that nothing can replace testing.

True. I guess my point is you and me could use different resolution systems (chaos) but each of us could see a sensible hierarchical namespace (convenient for human brain).

And I totally agree. Do you think however that this could be achieved by running a nicro-ICANN as a separate LTD sponsoring the Foundation? And having this mincro-ICANN manage the most popular namespace - but not the only namespace in existance? The popularity in my view could come from the following sources:

  • pre-installed in SafeBrowser (like Google search in Firefox)
  • usefullness (the LTD would throw out fraud, resolve disputes)
  • we can ask users to make use of it to support the network

Also what about the legal argument? Wouldn’t it indeed be safter to manage the namespace via a separate organisation?

I mean for those alias names for actual safe addresses - the way Christopher proposed it once you create it, it’s mapped to your safe address, isn’t it?

I don’t know, I am not a distinguished thinker or DNS guru. I just know how much I don’t know and because of that I am a minimalist.

Very few people are concerned about (example) high quality install guides and how-to’s but those are the actual and important things at this moment.
But it’s boring and doesn’t lend itself to stimulating intellectual discussions, so we engage in these complicated discussions about an area none of us are competent about. :slight_smile:

The way I understood Chrisitian:

  • a symbolic address (hardtoremembername12345.safe) is mapped directly to routing info (in the form of a hashmap)

Catbertian proposal was:

  • a binary address derived from public key (biy0wp6edsf.onion) is resolved by SAFE to routing info natively
  • SafeBrowser uses an ordinary application running on top of SAFE to resolve symbolic addresses (wikipedia.official.safe) to binary ones (biy0wp6edsf.onion)
  • each user is free to choose which naming application to use (an application is identified with its .onion address) and to combine them

It’s true that I haven’t even started looking at the codebase. If that disqualifies me from the discussion I’m fine with that. However if not then my point is that deciding that a single global naming service will exists is an important decision which likely will not be possible to undo later. I’d feel much SAFE-r if either

  • a decision was made that two-tier system will be used with multiple naming services
  • decision on naming service was postponed and only biy0wp6edsf.onion were used for the moment
1 Like

Sorry - I didn’t mean to imply you’re not competent in C, but I assumed none of us is really a DNS or name resolution expert.

crux of the matter - a major social and economic decision: if app writers start assuming presence of one global namespace now this may be impossible to reverse later

I moved a post to a new topic: RFC - Decentralised Naming System II - prevent squatting (no reassigning names)

Create a Nickname (domain name) that is uniquely identifiable as well as customizable in such a way as to promote human-meaningfulness, while retaining a many-to-one mapping that discourages domain name transfers/purchases.

That is my thought on how this “Nickname System” (DNS) should work. Now, is it true that Public Personas have already accomplished this? (If you’re stuck, use my previous thread as a reference.)

Next, what can we say about Public Personas? Can they be as effectively anonymous as they contrarily have the ability to be reputable?

Well, how are they calculated?

To clarify what a public key is:

Now here’s the kicker. Since the name itself is not necessarily unique, you need that Identifier. Let’s just stick to the proposed Public Persona example here:

Which leads to:

When I apply for a “Nickname” (DNS site name) The network will look at my Public Nickname (the name that I chose for the site (long_name)) and the first three characters of my hashed Identifier of my Public Persona, thus changing this line of the proposition:

to

Change that to a webpage: safe:smacz.b34. And you have a unique decentralized distributed non-squattable (statistically speaking) domain name that I can prove belongs to me while remaining completely anonymous and is uniquely identifiable as well as human-memorable.

If you create a Public ID specifically to act as the site’s admin, the website is said to be run by an anonymous user. If you create the website with an existing Public ID, the website is said to be run by a reputable user (as ownership can be proven by hashing your Public Persona’s Identifier). All users must create a new Public Nickname for this site. Whatever setup the network has to handle Public Persona resolution would be the same to handle this Nickname System.

This would change:

to

To find this information an application will SHA512(SHA512(Identifier + Nickname) + type_tag) and retrieve this packet.

I can’t be 100% sure that I didn’t misunderstand some aspect of the Public Persona process and how it can map on to a Nickname System. Did I miss something?

EDIT: Known tradeoffs:

  1. Each site must have a Public Persona who created it. Only one Public Persona can be linked to any given site. However, one Public Persona may administer many different sites (with different Nicknames of course).
  2. There is of course an element of randomness in the Nickname: the three letters after the dot ("."). This impacts the meaningfulness/readability/Paper Napkin Problem of the site, but only in slightest degree.
  3. The Identifier is not standardized; a TLD in this case really doesn’t mean squat. It’s just to verify the site as unique.


Keep in mind, by implementing the Petname System, the only time that you will have to enter the Nickname is when you are discovering a new place on the SAFE Network. If you are referred to it by any other digital means over the network, it will transfer to you the 32-bit hex (or whatever) key of the unique name on the network, along with the suggested Nickname that you will be prompted to rename to your Petname.

FROM THIS POINT ON, the only way that this specific data is be referenced, the network will always display it as your Petname. Nothing more, nothing less. This minimizes the importance of Nicknames (domain names), since sharing online will always be relative and unique. The only way they’re really important is when you consider the “Paper Napkin Problem” or the “Moving Bus Problem”, where sharing off-the-net is necessary.



In regards to Nickname (domain name) transfer, if an entity wished to ‘purchase’ a domain name, they would have to cultivate a new Public Persona that shared the same SHA512 of the Identifier as the existing site admin. This is prohibitively hard. It would be much easier to create a new domain with the same name, but use a new public key for the new identifier - now the last three characters will be different: the .abc, .123, etc. Also, if it really was a friendly sale, the website would be able to broadcast a (signed) update notifying all of the Petname Systems of the change to the Verification Code (last three characters). To the end user nothing would look different. Only under the hood would the addresses be different.

Keep in mind this Nickname System works on the two levels of readability as the DNS system today does. On top, it’s the user-chosen string concatenated with the first three characters of the SHA512 of the Identifier. That actual address - the IP address lookup in the DNS system - will be the SHA512 of the Persona’s Identifier concatenated with the Nickname.

This leads to being able to say to another user “Go to my location with this Nickname”, and since they already have your Identifier, they can SHA512 that concatenated with the Nickname you give them and receive the unique name of your site. (as it would appear under-the-hood).

There would be no way to perform a Hostile Takeover of the Nickname, as the same function that prevents similar Persona + Identity combinations from existing will be enforced on the naming of new Nicknames.

2 Likes

Sorry to raise this again but perhaps smb can offer a critique :smile:

  • there is no global DNS
  • search engines scan websites and compute rank pretty much like on WWW
  • people use search engines to find and bookmark websites

Would this work? Are normal search engines - paid for or ads driven - even possible?

You’re talking about google, not DNS. What you’re talking about is an App, not a Name Service.

Decentralization is not nearly as important as accuracy… You can always have 4 or 5 competing systems, be they centralized or decentralized the one that is most accurate is the one the public will use.

As a general rule on SAFE, If I want to be public, I think there ought to be zero doubt that I am who I say I am, and If I choose to be private, nobody ought to be able to figure out who my posts came from. I don’t think those things are too hard to obtain with cryptography…

It is much harder to do in a decentralized brainless manner – Somebody’s gotta be able to decide google is google and amazon is amazon. But brains are accessible via crowdsourcing or smart contract betting etc…

From my point of view, the Petname System will work like magic on the SAFE Network. However, it works differently than DNS and does not solve the Paper Napkin Problem.

On-grid, it can do everything. There’s really no need for DNS. More so there’s need for “Metacquaintances”. @dirvine keeps talking about nature this and nature that. And I’m beginning to realize that nature is all relative.

There’s no one canonical reference to what’s what. It’s humanity’s error that we tried to give an absolute value to everything. It may just be the case that something decentralized cannot have an absolute reference. @dirvine stated that the individual client’s view of the network would be unique among every other client’s view of the same network.

For those reasons it may not in fact be possible to create a “Decentralized Naming System” that both prevents squatters and maintains a human-memorable aspect. There may indeed be room for services that provide index and even contact information services. (for non-1337 H4XX0R$)

Without using them though you may be able to wander the web namelessly, untracebly, and who know how far you can get. Maybe you can turn your own knowledge and contacts into your own net. Word of mouth goes far. These are exciting times.

P.S. If you’ve been following @fergish’s podcasts, in the book that the author he reviewed last week wrote, they spoke of “Crossing Houses”. Kind of like fraternities of the internet. It was an interesting concept. If you’d like you can read more about it here (and the quick reference is here Appendix 3)