NRS Pre-Registration and Sale

I can see how you might feel that is an issue, but as I say, it is a heavy heavy price to pay, to hamper the usability of the network thorough only resolving NRS urls via the address bar.

E.g. authoring a page, or pasting addresses into messages just got horrible. Plus a lot of the easy, usable and exciting beauty of things like SafeIDs just gets trashed, because we are worried about brands not being able to own the exact Name they desire. And it’s especially a shame when we have other options available to mitigate squatting over time, and make it pretty much irrelevant.

But you’ve just made that problem worse, by allowing people to ‘snipe’ and existing site you have already established on SAFE, or identity you already have in use, and putting nasty content on it, or using it for nefarious means. Or grabbing it after you die and vandalising it, trashing your digital legacy.

2 Likes

I think we’ve done as much as we can here.

It seems to me that we will launch with a simple groundbreaking (secure! decentralised!! human readable!!! versioned!!! ! perpetual!!! !!) NRS which will initially allow the network to function along with some flaws.

At most we can expect some anti squatting-spam measure (cost of work?), but with limited effect. I think that is what would be best explored because it might not take much work, and might have some benefits with negligible downsides.

Later NRS can be replaced or improved by alternatives (you just need to change the relevant code in any client, or create a plugin). Different schemes can come and go, it just needs someone to write the code and update the clients.

So far I’m not convinced any of these ideas are an improvement because they seem to have their own flaws, but maybe one day something obviously better will be devised, or maybe they problem will go away as we change how we interact with the web altogether. I think that’s the most likely, with the flawed old NRS still there, working forever for those tech archeologists and tech geeks to marvel at, write PhD’s and make history programs about.

Mean time, how about thinking about ways to limit squatting with a cost of work (though on another topic)?

1 Like

Not worse, less worse. Because sniping an existing site and keeping will be much more expensive than registering a new site which you own forever as it is now.

No, I’m talking reputational risk of allowing NRS names to expire and therefore be taken over (which is one of the wretched things about domain names on the clearnet: constantly having to protect them, with the ongoing admin burden, cost, and stress of that).

For example, I spend years building a reputation, my site is popular, my address and SafeID widely distributed both as inbound links from other sites all over the network, and in hardcopy IRL. It’s on billboards, business cards, newspaper articles, and CVs I’ve sent out.

Now someone who doesn’t like me nabs that name because I didn’t realise it was expiring, or I forgot to do the admin to keep up with it, or I die… and they distort my views, or post offensive content.

I don’t see how that would be BTW… as data is paid for once and stored forever, so cost of either option would likely be the same: the cost of a small mutation of an NRS record.

2 Likes

Because of the auctionS…

I’d say NRS is trustless, but it doesn’t have a suitable way of distributing the names. And having a suitable way of distributing the names with NRS seems to require trust (as per OP).
If focus is on launching an MVP (and an MVP doesn’t require NRS in my opinion), I’d say shelf the idea for now, provide a plug-in interface for name resolution, and let the community work it out. NRS could be a plugin, sure, but tieing SAFE too much to a flawed system like this is asking for trouble.

1 Like

I do not currently use any. I have used the namecoin service in the past and there is also one on ethereum. I believe there are others.

An additional later NRS plugin could ‘patch’ scammer domains on the defacto NRS as well as be used by parents to block sites for their kids - to name but a couple use-cases. On the clear net we can use our computers host file to block websites we don’t like … and of course scammer sites can be removed as well - but not on SAFE. So definitely good use cases for pluggable NRS.

Need? OR Want Jim? I don’t think the network is broken without NRS at all. You have some 'splaining to do if you are sure that it is.

Please define this more clearly. It seems to me that if my website is “xyz services” and I use that in a title that is ranked in the search, then all I have to do is communicate yes, please go to my website xyz services - look for my logo (logo can also be pulled up with a search system. Of course it needs to be a unique name - but that is absolutely true with NRS as well - so what does NRS really add here - just a way to block out someone else who wants to use the same name … that’s monopolization my friend - not communicability. You are just justifying bad human behavior IMO.

I use them now on my ads at market - people use their phone, snap it up and go to the website. Could certainly be used in a xor-url system. If not, then please explain.

I can’t disagree there, but the web overall and I expect on SAFE too, is difficult for such persons and NRS isn’t going to spare them much pain.

There are no popular names but more or less recognizable names.

Let’s imagine that google has its site in Safe. And we can find

.-google
.-Google
.-GOOGLE
.-google.com
.-GoogleInc
.-googleinc
.-googleusa
.-GoogleUsa
and hundreds of other similar variants.

Which one do we choose?

In the end we need two completely different things:

1.-A name system that transforms XOR addresses into a more human format.
2.-An identity management that allows the disambiguation of similar names.

For the first we have the NRS. For the second we need a solution and have in our favor the possibility of using linked data.

Some previous works:

https://hal.inria.fr/hal-01276602/document
https://hal.archives-ouvertes.fr/tel-02073961/document

1 Like

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.