The problem of resolving names to up IP addresses of different physical machines on the network. On SAFENetwork, names just resolve directly to data which exists somewhere on the network, which is likely the root for more data.
We don’t need to point to a cluster, which points to a bunch of host nodes or mail servers or whatever. We aren’t going to run out of resource on one box or another. It is a different problem altogether.
Consider this - if any data can be a pointer to any other data, why would you need anything other than the root data? Clearly, you can traverse child nodes by just specifying further path elements.
There is no point in having 2 hierarchies (URI subdomains and URI paths), when they both serve the same purpose. SAFENetwork essentially just has a simpler mechanism to resolve names to data.
I think there is a point and that is the UX. I think this takes on familiarity though, which is pretty niche. Fewer and fewer people are familiar with clearnet web addresses, so we have an opportunity to develop a better UX.
At the moment we are a bit stuck with keeping to scheme which developers and others already understand, and beginning to think about how we can improve it.
For now I think familiarity should be the priority, but we can still give consideration to future evolution.
You said that "Fewer and fewer people are familiar with clearnet web addresses, " and then said keep to what is familiar.
But SAFE does not have a hierarchical naming system and to try and have one will bastardise SAFE and take us back to the clearnet in workings and thinking concerning the web.
Whereas in fact the name/dir/dir/dir is becoming the norm because it just makes sense. There is less and less subdomain usage for websites and only the DNS is forcing the domain.TLD structure. And the registrars make way too much money to allow change
I think the priority for now is familiarity because the priority early on is to make adoption easier, particularly for devs and early adopters - who will have expectations about what appears in the browser address bar and what it means. If that is too different, it creates friction we can do without in the early stages.
This is true regardless of the proportion of people who use the web and understand the structure of web addresses and what appears in the address bar of their browser. Later we can be inventive because the masses might prefer a different system and find it has less friction.
But … with a browser plugin doing pseudo-dns the plugin could link “google.com” to any account name - no “.com” account needed. If the Safe Network is very successful, it will probably only be a matter of time before someone creates such a plugin and tries to cash in on it. Am I wrong?
I think we have to be careful with this though. Browser based security also relates to sub domain hierarchies, for example. The idea that if you own the parent domain, the sub domains are safe is false on a flat naming system.
We have to be careful that bugs to exploit this are prevented and we must educate devs/users to understand that subdomains are not safe. On balance, removing full stops from names may be a blessing in the long term.
People nowadays rarely seem to understand the difference between an address bar and a search box. Many, many can’t tell the difference between a browser and Google’s search engine. But I don’t think this kind of ignorance should be encouraged on SAFE. Making things easy to use doesn’t have to mean dumbing them down or making them look like earlier inferior models.
As you all can tell, I’m very much a regular user (well, maybe a “power user”) myself, so I feel like a bit of an authority when it comes to that kind of UX. I try to help out by testing some tools, usually GUI, and reporting bugs. I’ve reported a couple of small ones. In this case I was testing the WebID Profile Manager and came across the requirement for a “subdomain”. So I ask myself: What is this, and why is it needed? And on top of all, why does it have to be visually stated to the left of my “domain”? I just want to put up a page named “sascha” that says “Hello world! I’m Sascha.”, and maybe link to another simple HTML page that I try to have pass validation while practicing the use of CSS. This is the reality of a “regular user” who wants to learn about SAFE and at the same time practice some mark-up language.
I’ve been hanging around this forum for a while and I’ve got the feeling subdomains aren’t really needed on SAFE, just like Top level domains aren’t. If I’m right, the Manager shouldn’t be asking me for a subdomain. If I’m wrong, I’d still like the address to my page to look as pretty as possible and maybe read from left to right. I also need to understand what this subdomain in the address in its human readable form will be denoting on my site.
In any case, my little question seems to have inspired some good discussion, which obviously makes me happy.
And I say that Maidsafe foundation should take all the current TLD names and lock them up, they can keep the keys since they are regulated by strict UK laws and any inappropriate action would be serious.
That is exactly what SAFE would allow with NRS, so that is why the above is so important and maybe all 3 or 4 or 5 letter names too
absolutely not. I don’t want their to be ANY possibility that a government or any hacker could get their hands on them. Burn them, but do not hold them.
I wouldn’t do that … give warnings for sure when installing a plugin, but we can’t protect people from themselves. Plus plugins can add a functionality, they aren’t always a negative. Let’s not take away choice. So long as the default functionality is solid then that’s good enough. If we take away options, then others will just open them up again and become the new standard.
People scamming each other certainly is one of the big problems of this world. But I don’t believe it’s Maidsafe’s or the network’s responsibility to try to solve it. The same goes for hate speech, plotting terrorists or general disinformation that certainly will flourish on an uncensorable network. The network shouldn’t try to protect people from themselves. We can’t really ban addresses like safe://send-your-money-here-and-you-will-get-double-the-amount-back. People will have to learn. It might be a good idea to have the Safe browser include a note warning people that this is NOT the clear net, but that’s about all SAFE can do. SAFE has the chance to not only facilitate freedom of information, but it can also break with old habits like referring to subdomains and whatnot. This chance should not be blown.
If .com mean that all xxx.com own one ID, than MaidSafe can before lunch book all national ones and sell to someone. Or sell before start network to cover monthly expenses.
I always hated com org etc, I would type e.g. safenetwork.com and I would get to a website that says for sale instead of the service I am looking for aka safenetwork.tech
I also like the linux filosophy that a package has unique name so you dont need .com .org that points to different services but rather just have google or yahoo or safenetwork and safenetwork/forum or if the forum is controlled by other persons that have different access system then safenetwork and safenetworkforum
what I want to give to this disscusion is please! give us the ability to use spaces!!! so I could go to safe://safe network forum instead of the previous I wrote safe://safenetworkforum or safe://safe%20network%20forum!!!
I think we advanced in technology and we can cope with spaces in our urls!!!
maybe make mandatory a url to start and end with double // so if you see safe://safe network forum// all of this becomes a link
I kind of like the idea of spaces, but should it then be so that double spaces are not possible, because those might be difficult to tell apart from single spaces?
What about like email address names (the part before the @) where any dots, are removed
So then for NRS names the spaces are removed when looking up the name. That way you can have as many spaces as you wish and there can be no confusion if multiple consecutive spaces are used or not.
So “abc def ghi” has spaces removed by the NRS system before the lookup and then “abcdefghi” is looked up. And if someone tries to trick people by using double spaces then it makes no difference since it always comes back to “abcdefghi”
Thus your name “safe://safe network forum” is stored in the NRS system as “safenetworkforum”
About these ‘%20’ for spaces: I’ve had troubles with a while back when using snprintf → such a space character in the 3rd argument was followed with s or something like that (‘…%20s…’) so snprintf expected an extra argument → error.
But that had more to do with my bad coding probably.
hmm, yes you’re right, we really should disallow dots in ids. To decrease the risk to ppl who know how the current domain names work and assume that SN names work the same way.
or just add a blacklist on the client side, that can be removed in the future, when the SN gets more adoption and everyone knows how it’s working and how it’s different to DNS.
yeap, i thought that’s the way SN will be. No censorship on the network layer, but custom filtering on the client side. So plugins can be quite handy for that “custom client side” filtering.
Then i rewrite the client code to allow it, it runs on my computer. This is not an option. Any blacklist would need to be on server side. But then I just make my own AD with a blacklisted name and there you go I have that name