RFC - Decentralised Naming System

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)

By God I am! Similar to what you said one post above :slight_smile:

1 Like

@chrisfostertv a couple questions if I may:

  1. Is there a PUT fee to register a name onto the network?
  2. How is the data represented?

To clarify question #2 a bit further, is the data put into some sort of database? Or perhaps is the structured data storage analogous to a separate file on the network? I’m not sure I understand exactly how it exists on the network. The question I’m leading up to is: could a single registered name be referenced individually (either by public key or by long_name) or would a lookup have to be performed on some type of database that contains all of these name-key associations (e.g. one massive array)?

EDIT @Krishna_Kumar and @ustulation I also wanted to tag you two as you are the maintainers of the safe_dns crate on github.

1 Like

To interpret that RFC in terms of this use case for SD; the data will be represented as one blob(terminology?) of data per entry, and that the whole system will be one directory full of these data blobs. That would of course then require payment to the network to store that publicly. Is that correct?

An SD (maximum 100K) will be charged like 1Mb not structured data.

Not a directory but a type of structured data stored in the XOR space.

3 Likes

In regards to the RFC, I don’t see any specifications about a “configuration file” but I see that it has it’s own file in the dns_operations module. Would someone care to explain the motivation behind the configuration file, and what it is designed to accomplish?

I couldn’t find an answer to this in the thread. For example, could anyone register the name google.safe and prevent others from registering the same name (name squatting)? If so, then that seems like a drawback to me.

It should imo be possible to register multiple google.safe and they will be given a unique extension such as google.safe[DKR], google.safe[HFE] and so on. A bit ugly ha ha, but something like that.

Oh my poor, poor @Anders, that was a hotly debated topic with no real resolution. See DNS Continuous Auction thread for your answer. That was split from this thread when it became it’s own preposal. Post there with any questions

1 Like

Ok, yes a ranking would be good. I was thinking about that but was unsure if it would be possible to make it work good enough in practice. Will check out the other thread.

Someone could do that, but then someone else could create a different DNS system app with a different browser plugin so that someone else can also have safe:google.whateverfile at the same time and both work concurrently

…is my understanding, from having made the SAFElinx DNS page on the potential apps site

Not really…no.