I’d disagree it’s basic to the laymen. NRS/nice human readable addresses are what are attractive and understandable to the everyday person. I think going strictly xorurl would be a missed opportunity and a step backwards.
11 Likes
The NRS is one of the greatest potentialities of the network. Not implementing it from the beginning would be, in my opinion, a huge mistake that would even put the whole project at risk.
Without NRS the network becomes a mere game of techies.
6 Likes
Interesting idea @mav. Our concerns here have been about people controlling portions of it by squatting, but I think starting without an NRS is more prone to this.
We might imagine there will be competition, multiple NRS type solutions and there may be for a while, but I think it would be inevitable that one would come to dominate - because once there is such a leader, it’s popularity gives it an edge and it will grow until it’s the only one worth using.
The problem with that scenario is that the main NRS is not just global, but owned, centralised and the point of Safe for many of us will be lost.
Imagine if Google or Facebook owned the web DNS. People have tried to do this in the old web, but failed because they couldn’t win people over from the existing, flawed, centralised DNS which is still open to everyone with a few dollars per year.
So I’m very much for establishing an open NRS that nobody owns, that everyone can use by default from day one, and letting others compete with that.
3 Likes
I skimmed so not sure if this has been brought up … default NRS isn’t going to be the ONLY NRS. Someone is going to build an NRS plugin for browsers … and it will be forked, and forked, and forked.
If Maidsafe wants to make some $$ off of existing NRS, IMO why not. It will never be the end-all be-all of the network anyway.
6 Likes
some things it’s worth remembering:
-
NRS as it stands is application logic. It does not exist in the network. (It cannot be hard coded to limit characters eg). It is just a deterministic way of generating xorNames.
-
NRS is ‘sha3(publicName)’ but it could be anything. (‘ sha3(publicName + bacon)’
-
It only exists as long as applications choose to resolve it. Making a change to this is trivial. There is already talk of competing namespaces.
-
Only XorUrls exist on the network.
14 Likes
Fair enough, but it has been deemed essential via inclusion in MVE and all of the user facing applications that will be provided by Maidsafe. So there is definitely a tight coupling of NRS and the SAFE network at this point / at MVE launch. From a user’s perspective it will be part of the network.
5 Likes
Yes, and as such will be considered a default mechanism for a reasonable amount of time if not forever. So while other systems will be developed and installed this NRS will be around for a while and as a default, so if we can help new users in the early stages of the network then doing it has its merits.
2 Likes
Indeed. Not trying to say otherwise. It feels to me there’s a lot of focus on NRS, and NRS alone. Just stating a few things that maybe help focus that part of the discussion (maybe not…let’s see).
A lot of what I see @JimCollinson focusing on for example, is that NRS is one part of the ecosystem (I’m not sure how much else is in scope for MVE, but if something is needed, it could be added I guess?). So let’s not lose sight of that. Nor that there may be competing implementations for this feature set.
2 Likes
I think these are the wrong questions to be asking, because they frame the problem the wrong way around.
We should be asking:
- How does a user find / get to the information they are looking for?
- How do they verify that they are accessing the information they were requesting?
- How do they communicate the location of specific information to other people? (and how is it made accessible?)
If we focus on the answer to these questions, and look for some creative solutions with the capabilities that the Safe Network gives us, then issues like squatting and impersonation, could be all but eliminated.
Notice that clearnet DNS only provides an answer to one of these questions, so thinking about the NRS only, and we’ll come off with a narrow solution which largely replicates what we’ve got on the web, creates other issues in the UX, or throws the baby out with the bathwater altogether.
10 Likes
Just taking this line of thinking a little further, and to paint a wee bit of a picture of sort of thing we should be conceptualising.
Here are the elements that could comprise each site, and allow each of those questions above to be answered in a way that could make squatting and impersonation, well, ab almost irrelevant niche sport. Picture this…
Public Name
The main bit we’ve been discussing of course, but in this overall mix, it’s only part of the identity of the site. It’s necessary though, as a unique human readable alternative to the incomprehensible XOR Address. And not only that, it’s digestible by screen readers and the like.
I think it should be permanent, and not temporary though… bearing in mind it will also be used for Safecoin payments, so you could consider it like a bank account number, not something you want to change hands without your consent.
But anyway, this is just one part of the site’s identity, and how you differentiate it from others, it just happens to be unique.
Site Title
This is what the owner of the site wants to call it. I doesn’t need to be unique though, but paired with the Public Name, and combined with the Pet Name builds the identity of the site.
Pet Name
It’s been discussed a bit before alongside NRS, but often as an either/or rather than complementary. But this really could work.
If you imagined the Site Title as what how the site owner want it to be identified—a suggestion—the Pet Name is how I or my friends, or the wider community, choose to think of this site, what it’s actually known as. In fact, it could be that the Site Name becomes editable within the browser itself, blurring the lines between the two, and becoming a single field, and what predominant value that you type in the browser address bar.
The Pet Names given to sites could also be aggregated among groups of friends, or communities, or lists I subscribe too.
Pet Names are powerful because they also allow for language and naming to change and evolve over time, which is exactly what language should do.
These three elements, Public Name, Site Name, and Pet Name`, are the elements that would allow a site to be Findable, and communicable.
Publisher SafeID:
When it comes to a user verifying that the site is what they are after, either before or during their visit, then the SafeID becomes a great tool. First of, it will allow me to see a profile to provide additional context, and an overall smell test. Does this person, or entity, have a history? What other sites have they published to? etc.
Flags
We could provide a system of flags too, to work in a decentralised, community/group driven basis. Is this site trusted by my other friends? Has it been marked as offensive, misleading, or a scam?
Associated clearnet sites
Taking inspiration from @drehb’s comment, we could create a tool for validating publisher’s site assets on the clearnet. A code snippet which gets added to a cleanet site, with keys that validate the owner of both sites, and vice versa.
This could form part of profile of a site, or extra metadata accessible from the address bar, that says the owner of safe://google123 also runs http://google.com.
Site/page History
When you are on the site, and browsing the content, then of course perpetual data allows you to roll back through the history of the page, which can be useful verifying its provenance
XOR Address
And then of we have the raw address of the data. Which perhaps is the least useful part, but of course it is unique, and the user could potentially see the history of its association with a Public Name and how this might have changed over time.
You could think of the identity of a site overall in the same way you would users on say Facebook, or people IRL.
There might be dozens of Jim Collinsons out there, but you can find the right me pretty quickly through number of other factors, such as my popularity (or not 
), my face, my history, location, stuff i’ve said elsewhere, whether friends say I’m a criminal etc.
How exactly all this plays out in the UI is up for grabs of course. It sounds like it might be cumbersome, but it needn’t be. Most of it could be done through a fuzzy search in the address bar, with additional prompts with varying levels of interruption depending on the nature of the metadata, and the user’s preferences.
I’d argue we should be thinking in terms of the full picture like this, rather than how we can hack at a single parameter, to get the Safe Network to fit within the existing web model, or expectations.
18 Likes
Everything you just said is brilliant. Enthusiastic thumbs up! 
6 Likes
The history of namespaces this is sorta interesting to me. I believe we can make a system that’s better for people than DNS. I’m still on the fence with NRS, probably slightly leaning toward supporting it, but am going to present some cons because that might lead us to a better solution in the end (whether it be NRS or something else). I’m just brainstorming in this post.
The way phone numbers are becoming IDs for apps like whatsapp and signal is pretty fascinating. Phone numbers are not terribly user friendly, but it’s also not extremely long the way an xorurl is. So the idea of having some one-time-exposure unique-id (like a phone number) which is linked to a simpler non-unique identifier (like your name) could be something to explore.
I feel that NRS introduces real risk with link rot.
One thing to help with reducing link rot is if publishing and editing tools have a linter that can detect potential future-rot in the content being produced and warn the users. Maybe even automatically suggest a replacement non-rot link (eg including the version number for mutable data).
Another thing will be having the ‘copy’ action in the browser address bar copy the version being viewed, or the immutable data xor, rather than the displayed friendly and tidy nrs url, so it’s more work for the person to have future-rot links (they’d have to manually type it to expose themself to rot).
How serious could this problem be? I dunno. Current stats show 1 in 200 links die every week and 50% of links die within 10 years (source). For something to be called the ‘permanent web’ it must do more than just store bits, it must have them accessible.
If a link become ambiguous because it doesn’t include the version does it count as rot?
Starting with ‘the one true NRS’ from the start implies those links are the one true links, when they are not. Starting with the assumption of competition of NRS style systems would allow users to understand from the start the importance of not relying too heavily on that system for permanence.
I think there’s lots that can be done to largely alleviate this in UI. And competing NRS doesn’t solve the problem, only helps reduce it. So I’ll just leave this as an open consideration.
BIP70 in bitcoin (payment protocol) tried to make addresses more friendly by letting users pay to a normal web url. It had a bunch of x509 verification built in and refund fields were added and this and that and whatever. It was a well thought out protocol but ultimately didn’t catch on and was disliked by many (including myself). Read more about the failings in BIP70 on bitcoin ops.
People want simplicity. In the case of bitcoin, an address was simpler than the BIP70 friendly system. I think NRS can deliver on simplicity. Just wanted to highlight a failure of simplicity or friendliness in BIP70 so we don’t repeat it.
Ethereum name service was halted due to a bug. I don’t think this will be a problem for NRS, but the consequence is worth noting: “Malicious users reportedly used this vulnerability to issue themselves the names defi.eth, wallet.eth, apple.eth and others … names that have been awarded to attackers in finalized auctions cannot be revoked and returned to the correct bidder”
The finality of NRS could become problematic.
Lastly, my feeling is that people like the simplicity of DNS more than they dislike it, but many normal people really dislike DNS without explicity stating it that way. Starting up with a new business? Better make sure there’s a domain available for it. Joining gmail? Good luck getting a nice email address. Slow to join github, woops lost your usual handle. Don’t like the name you picked so you drop it and move to a new one, what happens when someone else picks it up three years after you moved on from it?
These sorts of issues I feel are greatly improved by a competitive NRS space rather than a single one. It’s not about the technical ability to compete, it’s about the mentality and perspective and understanding. Maybe a competitive naming system ends up creating more friction than benefits for people, and having a single NRS with foibles ends up being overall much better, like DNS with all the pains is still overall much better than using IP addresses.
8 Likes
On the flip side, I could also envision these competing systems creating the sort of siloed ecosystems that are trying to be avoided. Could you get locked into a particular browser for example if the competing naming systems involve forked browsers that have different default resolvers? Would you then mostly stay within the subset of the network linked by that naming system?
1 Like
There’s an assumption that follows from DNS that public names are unique.
If there were multiple instances of the same Public Name that would help resolve clashes of interest on the normal human interest of brand and identity. So, perhaps only a few would resolve this?.. take some element of the xor that is truely random 3 characters and prefix the Public Name for example… safe[abc]://google is not the same as safe[xyz]://google
1 Like
This is why I proposed that we NOT use a single global namespace and instead have hundreds or thousands of short-ish TLDs with more that become available over time. Then many parties with same meatspace name can happily co-exist.
The regular web has moved in this direction for a reason.
Instead of alphabetic TLDs, you could also use the year number. So each year you can make a new set available. Numbers are more equal than alphabetic characters which might create words or abbreviations. By using year it immediately says something about its history, how old the domain is which is nice
1 Like
As you say, there are app level solutions to this. We cannot control data uploaded. but we can choose what we show/process in apps. The browser already has features to not load data from non-versioned links (NRS or Xor).
Any uploader could (should) upload with a version attached to it (if not straight conversion to xorurl… but then you lose some data in the original URL…). you cannot upload to NRS maps (via CLI… it’s app layer), without versions for all things therein. The resolver should error on non-valid NRS maps.
Just to touch on that. It has been previously considered that the namespace is just specified by the protocol. So perhaps safe: uses nrs but pa: uses perpetual auction. I imagine an @ namespace for WebIds eg.
3 Likes
This is kinda a parallel to what I’m suggesting with the pairing of PublicName + Title: the mix of unique human readable value + simple non-unique identifier making up an identity.
However, I don’t think a phone number is the right comparison for NRS here. The reason apps such as WhatsApp are using them is not for their human readable feature, but for their global uniqueness.
While phone numbers are of course technically human readable, they are just not very recallable, difficult to quickly differentiate when compared to word forms, therefore not usable as a username.
It’s their association with a what is effectively a PetName via contact lists on mobile phones that makes them work well in this way.
The thing with PublicNames is that (conceptually, or at the UX layer at least) they will drive not only site addresses, but also SafeIDs which are network wide. So you want them to be unique, but you also want them to be human readable, and quickly discernible, typeable, recallable etc, because they are going to be used in the flow of text regularly, with strangers, as well as with existing contacts, businesses etc.
So unique word forms for PublicNames I think are important, then combining that with a non-unique Title and/or effectively a PetName, I think could be a goer.
That doesn’t mean there aren’t still decisions and debates to be had around the form of the NRS, but just wanted to clarify some of the usecase.
I think I’d need to be convinced of this. I mean, we can’t stop someone creating an alternative NRS, but is it desirable? Or perhaps is that possibility a distraction from the effort of working it out at a first pass?
I mean, to come back to the phone number analogy (not a perfect fit IK), what if phone numbers were unique only to individual carriers? It would probably be a bit of a trainwreck.
5 Likes
I don’t know why this debate keeps coming up months go by and here it is again.
While other NRS’s can and IMO will be created down the track, one created by Maidsafe will probably be dominant and as it’s built-in it will grant a monopoly over some letters … which is akin to copyright … which is in a way a form of blocking free speech … which is hypocritical of Maidsafe IMO.
As I’ve argued in the past, we should leave the past behind. We don’t need ANY NRS.
We can use aliases linked to XOR URL’s in combination with searchable tags … IMO if Maidsafe should be developing anything beyond the MVP/MVE … it should be SEARCH!! not NRS.
Simple I2P list system is more than sufficient for domains and I don’t understand why Maidsafe peeps are so keen for a core built-in NRS system mimicking the monopolistic flaw of our current Internet.
3 Likes
The reason it keeps on coming up is because it’s not settled. And the opportunity here is there for it to be shaped, proved, and improved.
So let’s look at the pros and cons, let’s describe how the network would function with, and without and NRS—or in combination with other elements as I’m postulating—and how we could do a better job than the web.
BTW, it’s not an either or. Both of those things perform related but different functions, and solutions to both of the problems they address are required.
4 Likes