NRS Pre-Registration and Sale

Thanks for your detailed reply … honestly I didn’t expect that much of a detailed definition!

I’m not sure we’ll really ever agree on these things, but I’m just an amateur armchair theoretician, not the peeps in the coding hot-seat doing all the hard yards - so thanks for your efforts in any case, if not for people like you, we’d have nothing to argue about in the first place :wink:



Ok, so I still know no one who uses any other name resolution service. I suspect there is a reason for this and it isn’t a technical issue.

A plugin which blocks names can exist with NRS (either to block NRS or XOR names), as can a host file resolver (just as it does with DNS).

However, host files are used to keep ‘pet names’ and also isn’t popular outside of technical circles. I also suspect the reason for that isn’t technical either, as it is trivial to use too.

I remain unconvinced that alternative name resolution services are in demand by users. Integrating support for other resolvers could be a nice feature in the future though.


That is an interesting point. If you haven’t been given the name, how do you know it is the one you are looking for?

I’d say this is an additional problem to the two that @JimCollinson has pointed out already. At least, it is a nuances form of findability.

Jim covered this partly already though (and someone else?), with the concept of your social group (friends, colleagues, etc) influencing search results. That is, you can seek a recommendation of which is the real Google, by seeing if anyone else you know trusts that name.

Definitely an interesting area to drill into, but aside from communicability though, imo.


Some other direction of thinking to avoid squatting (just thinking, no proposal, relax).

Why should only the first Joe Plumber have the right to claim safe://JoePlumber?
Everybody should be able to claim what he wants.
This network will live for decades at least, some Joe Plumber born in 2168 should be able to get his safe://JoePlumber domain. So let’s do that!

How? We can do this by generating a random extension :slight_smile: It doesn’t matter then if you are the first or last one who claims the domain. With 3 characters you will have 17.5k possibilities (popular ones like com excluded)

Up to the person or business to share and promote his version. Dead legacy domains will be kept (@JimCollinson happy). New up-to-date domain versions will arise (me happy).
So you will get:

The good thing at least is the easy implementation and the url look quite familiar to existing clearnet urls.

(@neo not so happy)
Downside of course are the phishing domains.
But maybe we can try to think about how to deal with this. Like some ‘official’ lookup site to check if a company NRS-url is the one that belongs to that company.
Or do we have any info about the NRS-url GET requests (and can we exclude requests from scripts)?
If so, we could use that to determine the most popular one and link that NRS-url to the NRS version without the extension (this version should not be used for linking, only address bar).
This might work very well for existing clearnet websites, because they can add their NRS-url on their existing clearnet website and that one has the biggest chance then to become the most popular one.
I don’t know, just some wild thinking.

Other ideas?? Or is it really bad and should we stop thinking in this direction?

It is worth exploring this and other ideas but many have been discussed before. I think David suggested something along these lines a long time ago (I think using random characters including numbers). We’ve been discussing this for a long time here!


I’d like to see a table with all the ideas summarised alongside the pros and cons of each, not just from this thread but also the great fresh-safecoin debate from June which actually covered much of the same ground (I was wondering about those strange sensations of deja vu). I’ll have a go when I have a moment but I’m under the cosh right now.


If NRS were to block registering names less than 4 characters AND if NRS were to ignore the first ‘.’ in any name, then it seems any existing company could have,,, etc, etc. They could also have any “.xyz” domain ending thus giving the appearance of a TLD. This solution also doesn’t block users from just having a single word domain name.
EDIT: The ‘.’ in the fourth position would have to also be considered part of the name by NRS.

What are the drawbacks here?

I guess subdomains on single word domains would have to have two ‘.’ to represent subdomain - or we could just use ‘/’ for subdomains?. EDIT, actually, if NRS ignores the first ‘.’ only if it is the fourth character from the right and not otherwise, then all subdomains could work as normal - because you wouldn’t be able to register anything three characters or less.

So the only drawback I see is that three letter/number domains would not be allowed under this system - although you could still have

other problems?

Also there will be a lot of people who put up educational sites that only need to be set up once.

To expect them to renew the “name” every period will remove the simplicity that SAFE currently provides.

As you say many of these great educational sites will over time be taken over by malware/scammer/etc because these site rank well in the search.

I might put up a site with plenty of tables for ASCII, code tables, and other common tables for electronics etc. Then in 10 years I am not in a position to keep renewing the NRS Name and then next period my great reference site is taken over.

No. One of safe’s fundamentals is perpetual internet, not here one day scammed the next.

So @JimCollinson I agree that the long term solution is worse than the short term problem it attempts to partly solve.

Yes the argument does not add up.

@JimCollinson Is there a possibility of changing the Name registration to also write a reverse lookup for the AD so that browsers can show the “Name” when mousing over a link that is an XOR address

And another question can the cost for registering the Name be increased as the length reduces.

EG 1 char cost 10000 units
2 char costs 2500 units
3 char costs 1000 units
4 char costs 250 units
5 char costs 100 units
6 char costs 25 units
7 char costs 10 units
8 char costs 3 units
9+ char costs 1 unit

If the tag type of the AD for registrations is a reserved one then the core code could implement this in my opinion

Someone mentioned it above and I think it would be a great solution to the issue of squatting on short NRS Names


I don’t see how you can conclude all of those things by having tiered pricing based on name length.

  1. It is not simpler. The most simple solution is having a flat cost for any public name reservation. This cost should be at some ratio to the current PUT cost. Ideally this ratio would be 1:1 so that the cost to register a name is equal to the number of PUTs required.
  2. Tiered pricing based on name length does not fix perpetual domain squatting.
  3. There is no need for auctions for any of the methods listed. “The Great MaidSafe Auction” could just have well been named “The Great MaidSafe PreSale” with all the domains having a fixed price.
  4. The network will receive the most coins for option 4, “The Perpetual Public Reserve”. It has the side effect of serving as a constant source of PUT income for the network. This is due to the competition that will be involved for many people all around the world using PUTs to modify/update the site in a fight for dominance of the name. Versioned data allows the entire history of this game to be reviewed in perpetuity. Every individual who made a modification can set their version as their default preference, or look at the latest version, etc.

Last, having a tiered pricing scheme like you propose violates SAFE principles, since Everyone’s access is not the same.

Agreed. The question comes down to how much structure do you want to enforce. IMO there are two fundamental differences between some of the proposed approaches.:

  1. A one to one correspondence between an NRS name and a XOR address. (Do Nothing, Public Reserve, MaidSafe Auction)

  2. A one NRS name to many XOR address correspondence. (Pet Names, Safe Search, NRS Composting)

This is exactly what the alpha 2 NRS did (doesn’t the current one do the same thing?). The difference is that the alpha 2 extension could be anything you want. This comment makes me wonder if everyone is on the same page about how the NRS is structured… myself included.

My understanding of the NRS structure, unless it’s been changed.


The ‘service’ can be anything. The publicname is what we are talking about reserving or worried about squatting on.

is equivalent to

Question : Is the ‘.’ character currently allowed in a public name? For example, what happens if I register ‘’ as a public name and then add a ‘www’ service to yield ‘safe://’?


No, it might look the same, but it isn’t. The big difference is, like you said, you have no control about the extension. Which levels the playing field.
And on Alpha you would own all the .xyz extensions. Now you only own safe:// and someone else might own safe://

What you suggest is the same thing as using a ‘.’ in the public name on alpha 2.

I don’t know if I follow you with all the dots :wink: But in this case I would suggest to use ‘/’ for paths and subdomains whatever. And you are ony allowed to register single words, no dots or other characters

I’m suggesting that this could be changed so that you could register “” - with the dot.

Re-read what I wrote … from what I understand of existing NRS, websites won’t be able to use consumer expected tld-type endings. What I am proposing is a solid workaround that will allow the appearance of ANY three-letter tld on SAFE.

That’s all fine, but not at all the point of the idea.

Why do you want to keep .com extensions in the public name? It is clearnet legacy and confusing. Just start over again with a blank sheet.

The NRS you really want to have as company is the NRS without extension like safe://google
How to do this in a fair way? Should I own it? Should google the company own it?
Should duckduckgo own it? Let us users decide…
How? Well I explained it in the original post. You can’t claim extensionless NRS-urls, you must earn them!
Let’s everyone claim safe://google
I get safe://google.rgh
google gets safe://google.sbv
Google has the advantage of the existing site. It can create links there to safe://google.sbv (The transition form clearnet to SAFE will be slowly, so existing clearnet sites have the advantage of promoting their SAFE site)
Some SAFE Network algorithm decides which page got most unique visitors, and the network will then create/update the safe://google NRS and redirects that one to safe://google.sbv
So the most active/popular website gets the best NRS-url.

You can go even further with this. Instead of an immediate redirect you can show result when you go to safe://google or safe://news like
safe://news.fge (56%)
safe://news.awe (12%)
and you have some kind of search engine based on popularity

Going further again. Maybe we can add a redirect function on NRS level, so CNN can redirect safe://news.rtg to safe://cnn.oiu Bloomberg redirects safe://news.nvc to safe://bloomberg.ryw

I type safe://news
safe://news.rtg → safe://cnn.oiu (34%)
safe://news.nvc → safe://bloomberg.ryw (12%)

Tadaa a reliable search engine based on keywords/tags chosen by the owner.

Try to start thinking in new possibilities with this new system instead of old legacy crap and problems.

1 Like

Seriously! All this discussion about different lengths of names… How would the network know the length of the registered name?

The mechanism is hash(name) so the network cannot (!) charge on name length or just forbid too short names… (or only one dot or…)

Ps: and if the original name is Google and user photos are linked as safe://google/userphotos/riddim an attacker can always go with safe://google.userphotos.riddim/

You try so hard to prevent one(!) variant of getting fooled…

The API can include the Name and check it all adds up before writing the AD which would have to a reserved tag type


The Python lib won’t

It would require a change

1 Like

Single words are limited, word combinations are not. Word combinations without a separator character like ‘.’ or ‘-’ or ‘_’ are ugly. You just proposed the use of ‘.’ in a public name to improve everyone’s chance of getting a name that they like (ex. JoePlumber.123) and now you are saying the opposite. Which way is it?

You could, but should you? The major point of using a ‘.’ character in a hostname or filename is to have some sort of logical hierarchy or to embed a small descriptor directly in the name itself for organizational purposes. In Alpha 2 that was ‘service.pubname’ so that a single public name could manage multiple services and more than one public name could reference the same service.

Having a pubname with as many ‘.’ dots as you want, such as ‘safe://’ causes you to sacrifice the organizational utility that is normally provided by the just ‘.’ dot chars.

This is exactly what the The Perpetual Public Reserve and Private Squat option does.

This is exactly what was described before (minus the popularity %) for a previous version the Public Reserve idea. From a top down perspective, SAFE is a world computer with different services, and each pubname is a localization of that service. When typing in “safe://cats”, you get a directory listing of every pubname with a registered “cats” service and a description. In order to facilitate this, all common dictionary words needed to be reserved, since any conceivable word in the dictionary was considered to be a potential service. No one else seemed to like the concept at the time, which is why the latest pitch just described the root id as a versioned free for all.

Ooooh you mean the vaults writing the ad should be shared the content and names are like safecoin a reserves type - now I understand :face_with_monocle:

Hmhmm… So all public names get published somewhere at some point (‘no data leaves your computer unencrypted’)