NRS Pre-Registration and Sale

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.

safe://service.publicname/path/subpath

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

safe://www.publicname
is equivalent to
safe://publicname

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

2 Likes

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://JoePlumber.xyz and someone else might own safe://dogs.xyz

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 “google.com” - 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 www.google.com 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
Results:
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

2 Likes

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://this.is.my.awesome.safe.pubname.that.has.too.many.dots’ 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’)

Only during registration process.

It leaves your computer encrypted. Just like when you tell the network your coinBalance address when you transfer coins.

There is always some types of transient data revealed to the connecting node

Huh? You register single words (or public name whatever you call it, which can be anything) like ‘jlpellTheMan’ (no dots allowed!)
Then you get the domain safe://jlpellTheMan.rwg
What’s so difficult about this?

But it’s still different isn’t it?

If I create public names for sharing data ‘on a regular basis’ (for example safe://riddim_share_1337) the vaults seeing this can link riddim (my real life name) to the public key I have… In any case this leaks additional information… In my head this is a bit wrong…

Ps: I admit this is a very limited powerful leak… And not necessarily true either… But it leaks data to people I didn’t want to leak to…

Think about it, a bad actor node could record all the ADs for NRS and go to the site pointed to at a later time. It has who registered the unknown name but now has all it needs the who linked to the site. And look at links to discover the NRS Name

Are they still not encrypted? Oo

NRS is a public system, its meant to be unencrypted

It’s not difficult, just backwards. On Alpha 2 I can register ‘jlpell’ and then have anything else I want such as :

maps.jlpell
email.jlpell
money.jlpell
happy.jlpell
super.jlpell
etc.jlpell
bin.jlpell
proc.jlpell
usr.jlpell
lib.jlpell
sys.jlpell
opt.jlpell
cats.jlpell
dogs.jlpell
home.jlpell

You are then free to have all the same services with a .nevel extension. This is a superior naming scheme compared to what you are describing.

But having them not encrypted imposes a risk to farmers I thought…?

And encrypting would be super easy… Just encrypt the content of name/hash(riddim) with the key ‘riddim’ …

1 Like