Protocol://Domain.Subdomain/Path

[chrisfostertv]

@neo

What I don’t understand why are people are trying to go back to a hierarchical system that has a lot of issues and replicate those in SAFE???

Confusion abounds, I think periods, slashes etc are merely delimiters within the Safe: protocol?

A delimiter is a sequence of one or more characters for specifying the boundary between separate, independent regions in plain text or other data streams

NRS (Name Resolution System)

Every piece of data on the SAFE Network has a unique location. Such location is determined by the XoR name given to it in the Network’s XoR address space, as well as some other information which depends on the native date type, like in the case of MutableData data type which also has a type tag associated to it apart from its XoR address.

While XOR-URLs are simply a way to encode SAFE Network data unique location into a URL, there are some incentives for having more human friendly URLs that can be easily remembered and recognizable when trying to share them with other people, or use them with tools and applications like the SAFE CLI or the SAFE Browser.

This is why the SAFE Network also supports having such human friendly URLs through what it’s called the Name Resolution System (NRS) . The NRS allows users to create friendly names that are resolvable to a unique location on the Network. These friendly names can be used in the form of a URL (NRS-URL) to share with other people the location of websites, web applications, files and folders, safecoin wallets for receiving transfers, SAFE IDs, etc.

Sub Names
Much like the old internet, the NRS system provides increased flexibility for those wanting to have a variety of resources available under one public name, via using Sub Names. This is done by creating a Public name and using a . (dot) character to separate it into various, individually controllable parts.

For example, you may wish to have safe://mywebsite to be about you in general, whereas safe://blog.mywebsite point to a different site which is your blog.

To create a public name with subnames, you need only to pass the full string with . separators, just like any traditional URL, to the CLI:

[Traktion]

But can anyone else create safe://wiki.mywebsite later? I am not in front of my PC to test is, but @tfa suggested it was not possible.

This suggests a hierarchy and of I had created safe://wiki, then only I can create safe://this.wiki and safe://that.wiki, which has implications beyond simple delimitation.

Edit: avoiding dots altogether is fine though. These can be created by different accounts, afaik: safe://wiki@mywebsite vs safe:///blog@mywebsite, or safe://wiki-website vs safe://blog-website So dot is special, if I understand correctly.

[chrisfostertv]

I do think Maidsafe need to minimize squatting by ‘creating then burning certain profile names’

…along the lines of:

1/ Create then Burn or lose credentials:

Original top-level domains
ICANN-era generic top-level domains
Infrastructure top-level domain
Special-Use Domains
Proposed top-level domain
etc

2/ Create and Sell at an administrative cost:

Country code top-level domains
Internationalized country code top-level domains
Geographic top-level domains

3/ Create and Sell. Invest proceeds to offset a reduction in CoreDev rewards as a % of total Safecoin issuance

Brand top-level domains
Internationalized brand top-level domains

[jlpell]

You forgot option 4.

4. Perform a dictionary attack for all single word public ids for all online languages. Publish the private keys at their respective pubId/xor address. The community/general public then fights or cooperates on how to update the immutable appendable data at that pubid in a similar manner to a wiki page. This struggle generates a continuous stream of PUT revenue for the network and serves as great entertainment or good marketing material. The result is that a single person or organization can own safe://awesome.chrisfostertv, but no single entity can own the safe://awesome pubId. If you think about it, it’s kind of childish to claim that you only you ‘own’ a single common word. (New, made up words are fine though… like “chrisfostertv”)

[chrisfostertv]

@jlpell

You forgot option 4.

In all seriousness, how would you propose to mitigate so called domain squatting if indeed you consider it an issue?

[jlpell]

@chrisfostertv

In all seriousness, how would you propose to mitigate so called domain squatting if indeed you consider it an issue?

Yes it is an issue. Number 4 above is my serious proposal unless a better alternative comes along. I haven’t seen one yet. It is better than “burning” because you don’t need to somehow prove that the private key was burned. In a way, Option 4 is a public burning.

[chrisfostertv]

@jlpell

Perform a dictionary attack for all single word public ids for all online languages

So given ‘creating profiles /losing passphrases’ is a process pre-launch. What are the public ids that you are referring to?

[tfa]

@Traktion

But can anyone else create safe://wiki.mywebsite later? I am not in front of my PC to test is, but @tfa suggested it was not possible.

Strangely I could. I suppose that @chrisfostertv created safe://mywebsite and safe://blog.mywebsite in his local vault.

But now that I have created safe://wiki.mywebsite in the shared vault, no one else should be able to create a name ending with “.mywebsite”.

[Traktion]

$ safe nrs add lazydog.mywebsite -l safe://hbyyyyn4bc68b38udgqyanbyezqqgaz96pxtks8bpzgwaim6u4edo6ahf5
[2019-09-01T09:01:50Z ERROR safe] safe_cli error: [Error] NetDataError - Failed to UPDATE Sequenced Append Only Data: CoreError(Access denied - CoreError::DataError -> AccessDenied)

$ safe nrs create lazydog.mywebsite -l safe://hbyyyyn4bc68b38udgqyanbyezqqgaz96pxtks8bpzgwaim6u4edo6ahf5
[2019-09-01T09:02:00Z ERROR safe] safe_cli error: [Error] ContentError - NRS name already exists. Please use 'nrs add' command to add sub names to it

Yup, it looks like you are right! Only you can create *.mywebsite now.

[chrisfostertv]

@tfa

I suppose that @chrisfostertv created safe://mywebsite and safe://blog.mywebsite in his local vault.

Not me, that’s a text paste from https://github.com/maidsafe/safe-cli/blob/master/README.md

[JimCollinson]

@Traktion

Logically, going from broadest to narrowest would seem ideal.

@neo

Yes NAME.Sub is best if we are to have “.” at all a separator.

@happybeing

Currently we have an extra bit that’s not needed - the TLD - without that I think the revised ordering makes even more sense.

@draw

And from the following interview with Tim Berners-Lee:

Also I would have put the domain name in the reverse order - in order of size so….

Are we starting to converge on some sort of agreement here?

[Traktion]

Perhaps! Ha! I’d still caution against making the change due to it being the inverse of what is expected for clear net users. Tbh, having a name without subdomains at all is probably the least confusing.

[JimCollinson]

@Traktion

Perhaps! Ha! I’d still caution against making the change due to it being the inverse of what is expected for clear net users.

It’s funny, I’d argue the opposite. I’d contend that most people will want the more relevant broader name first. The TLD is just sort of an incidental thing, and rarely will they think of it having anything to do with servers or anything. Pushing subdomains more into more regular common use, and having nothing at the other end will likely be more confusing, and like you say, be like calling someone with their names flipped. And worst still, lead to more ambiguity over ownership/authorship.

Over the weekend I was thinking that we could do a card sorting exercise with users to determine if these assumptions are correct or not. Take a bunch of names and subnames in the proposed formats, and ask a participant to sort them into stacks based how they would categorise/understand how they relate, and ask then to explain why.

Might be worth putting a little time into doing something like that if we’d like to assess it before diving into a change.

[neo]

@JimCollinson

Over the weekend I was thinking that we could do a card sorting exercise with users to determine if these assumptions are correct or not.

You would have to do a number of examples first so that people know what you are talking of and to allow them to clear their thinking from the backward way of thinking they have endured since the money speaks system was introduced. I can remember in the 80/90’s explaining DNS system and the very words were “You have to think of it in reverse, yes I know its unnatural, but that is the way they did it”

[JimCollinson]

We’d have to construct the test with care, sure. Important to screen people first, but also not to lead them… They’ll be coming to the SAFE network primed with their existing knowledge of the web, they will always see it through the lens of what exists now and will built up expectations and assumptions over decades.

The idea of an exercise like this isn’t to test or validate a specific solution though, but more to test our assumptions of how people perceive, categorise and organise information; which would then help us design a solution armed with that knowledge.

[Traktion]

@JimCollinson

@Traktion

Perhaps! Ha! I’d still caution against making the change due to it being the inverse of what is expected for clear net users.

It’s funny, I’d argue the opposite. I’d contend that most people will want the more relevant broader name first. The TLD is just sort of an incidental thing, and rarely will they think of it having anything to do with servers or anything. Pushing subdomains more into more regular common use, and having nothing at the other end will likely be more confusing, and like you say, be like calling someone with their names flipped. And worst still, lead to more ambiguity over ownership/authorship.

Over the weekend I was thinking that we could do a card sorting exercise with users to determine if these assumptions are correct or not. Take a bunch of names and subnames in the proposed formats, and ask a participant to sort them into stacks based how they would categorise/understand how they relate, and ask then to explain why.

Might be worth putting a little time into doing something like that if we’d like to assess it before diving into a change.

Yes, doing some user questionnaires/interviews would probably be useful for such a fundamental change. There would need to be a good cross section of technical abilities too, as I suspect it will vary heavily depending on this too.

I suspect many people just put .com on the end without any understanding, much like people do the same with www. prefixes.

I also think people rarely go to subdomains directly, instead relying on search, navigation and/or bookmarking. The number of people who type maps.google.com in the location bar are probably a small group. In fact, the location bar is used as a search bar now, really.

Definitely a nuanced issue, I’d say!

[JimCollinson]

So, as a quick example of how a card-sort exercise might be constructed in this case…

You’d sit down a participant and spread out a shuffled deck of cards on a table, and ask them to put the cards in piles based on how they would think best to catagorise them, and then you ask them why they made these decisions. And you can also gently prompt them to vocalise their thinking as they work.

Our deck could perhaps be:

http://email.google
http://jones.baker
http://email.bbc
http://baker.anderson
http://blog.jones
http://jones.blog
http://google.com
http://bbc.com
http://baker.anderson
http://google.blog
http://blog.google
http://jones.anderson
http://anderson.baker
http://baker.jones
http://anderson.jones

Notes:

• I’d include the protocol in there on each, so folk can contextualise it, “ah, so these are websites”.
• Include some familiar names, and structures that they already find on the web
• Also include a few sets that are subtly ambiguous, i.e. they don’t have with a service like descriptor, and each could be interpreted as a surname, so it’s not too leading.

That’s just a quick thought about how a test might be constructed.