NRS Pre-Registration and Sale

It is obvious that it is out of scope of decentralized network to handle such think like database of recognizable names. It will never work. Solution should be simple. I think main simple rules are:

  1. Protect people used to DNS, by removing option to have same domain names in NRS. Example: deny .com domains
  2. Avoid domain squatters. Example: make it expensive to buy many domains cheap, or at least buy short domains cheap.
  3. Do not introduce governance. It should be easy to code, without requirement to create some human picked database
  4. It should be easy to understand for users.

My simple solution of making short domain names expensive and long cheap, with 4 characters minimum length of domain name solves all the problems. No squaters, no domain structure like on internet(4 chars remove options for all top level domain names like .com, .org, etc…), very simple, and everyone can register any amount of cheap long domains.

Okay, I think this will be my last post on this thread. A lovely as it is to discuss these things with all you thoughtful folk, it takes a surprising amount of time away from the task at hand (which is getting this thing ready for launch :rocket:).

But @TylerAbeoJordan, seeing as you’ve asked me some direct questions it would be rude to just let them hang, so briefly, here goes:

I’d say, for a Minimum Viable Experience, yes, we do need NRS. Having a human readable way to address the underlying XOR urls, is vital.

This is different from what you might argue is a traditional definition of an MVP… we don’t need NRS for the network to technically function, in the same way we don’t need any graphical user interfaces for that either, nor a browser etc.

But in order to have a successful network, one that has human utility, and can be adopted and used by a tipping point size base to make it resilient, and do the things we are designing it to do, such as provide secure communications, and free global access to any data, then we need a bit more: it needs to be functional, and it needs to provide tools that are useful and usable by people.

So if we throw out NRS for this Minimum Experience we throw out some basic, and really useful things like SafeIDs. Want to send me a message? Or transfer me some safecoins? You’ll need some way of understanding, handling, and recognising a XOR url, and relating that to a human in some way. We’ve just thrown out a network wide username system, with the beauty of linked data behind it.

I mean we use these things all the time like right now >>> @TylerAbeoJordan <<<. Try replacing that with something like safe://c4cc596d7321a3054d39724ff82fe64f49c3896a07a349d31f29574ac9f56965 and see how it feels.

Which brings me on to communicability…

It’s how easily I can transmit an address or identity to another person, and have it recognised and retained, in various mediums and in channels we know people already communicate such data: verbally, visually in written form, digitally in written form; and then the transcription an address between these forms,

For example, Imagine trying to communicate over the phone, and telling someone your address, or a way they can send you a message. And then imagine receiving such and string, and then typing it in, or finding a way repeating it. What would be actually usable in this situation, @TylerAbeoJordan73 or safe://c4cc596d7321a3054d39724ff82fe64f49c3896a07a349d31f29574ac9f56965?

Note, this is different from findability, or verifiability, which are addressed by search, and metadata which are layers we can apply alongside NRS.

But given that NRS is already a thing (and SafeIDs and RDF etc) and it is unlikely we will have things like search for launch, doesn’t it make sense to roll with it?

Yes, you certainly could use QR codes to enable the use of XOR urls, where it’s appropriate. We’re already designing with them for certain usecases to do with onboarding and in-person payments etc. But they only useful in certain circumstance, and are not a replacement for something like NRS.

They don’t deal with verbal communication for example, and I also have to have a device with a camera, and specific capabilities to hand.

They also don’t help with things like authoring a web page with XOR links, and they are not visually recognisable and distinct: I can scan list of NRS urls and see they are distinct, or relate, or guess where they might lead, but not so with QR codes, or XOR urls.

There are about 1.3 Billion people with some form of visual impairment BTW. That’s a lot of folk. It’s tough using the internet no doubt, but also useful and freeing too I’d imagine. NRS won’t solve all problems, but at least it won’t introduce another one: just try using a screen reader on a page with even a couple of XOR urls on it!

8 Likes

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:

Cheers

4 Likes

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.

2 Likes

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.

2 Likes

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:
safe://JoePlumber.fea
safe://JoePlumber.amc
safe://JoePlumber.etc

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!

2 Likes

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.

4 Likes

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 google.com, facebook.net, twitter.org, 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 xyz.xyz

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

2 Likes

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