Thinking about issues like this suggests to me that we’ll encounter a lot of new problems as we move away from a centralised DNS that while it has faults, has evolved to perform pretty well too.
Just the fact that there will I expect, be multiple name resolution systems (eg through forks or plugins) creates new problems. For example, confusing users by having different services at the same URI, whether by accident or design. Or different capabilities such as spaces or no spaces, different ways of handling names with spaces etc.
These become UX issues, and will be interesting to try and solve, but I suspect that as with apps it will help a lot if user choices can be informed or filtered using ratings, categories, comparisons, trust marks or the like. There are great business opportunities there I suspect.
A solution easily bypassed is not really a solution is it? Especially when there is an easier solution that does not require any code in the core or client and provides a non-bypassable solution and that is the names are taken by Maidsafe (Foundation) and either kept to sell OR keys are destroyed.
I think it will be very hard to stop the creation of code that harms people, whether a DNS, an app, or a website, so I don’t think we can make the underlying network only support a safe [cough] resolution service.
Hence I don’t see network side blacklists, reserving tlds etc as any more effective than @urrtag’s suggestion that the initial NRS be limiting client side, eg with an modifiable blacklist.
We could make the blacklist configurable, updateable, and optional to reduce the incentive to create or move to something less SAFE. I think that might be both more effective and a better UX.
My suggestion is to focus on helping users make the most appropriate choices about what NRS they use, which apps, which filters to enable etc, and do this all client side rather than attempt to bullet proof the network so only safe things can be built on it.
For example reserving the names / tlds and ‘destroying’ the keys (which can never be proven) will be bypassed by the first alternative DNS. So we still need to think of how to help people choose the most appropriate DNS for them, or they’ll easily be persuaded onto the now less safe alternative.
I reported the lack of Unicode support in file names when using the Web Hosting Manager a while back. https://maidsafe.atlassian.net/browse/MAID-2234
Maybe this is relevant here, and possibly not even a bug.
All the standard .com or .net pub ids keys will need to be eliminated/reserved/lost prior to launch or made public in order to not confuse people. Fighting over those ids will just make them useless anyhow.
Making the keys public can be proven, and it essentially makes the Ids useless just like destroying them. This is important in the cases discussed related to oldnet domain names. One side benefit is that it may provide a constant stream of put revenue to the network due to people fighting to upload data to the same pub I’d over and over 24/7. The battle could be waged with appendable data…
There was an advert on lLet’s Talk Bitcoin about purse.io doing some blockchain DNS. I can’t find the link, but they basically said the top 10k domains had been pre registered to prevent squatters. I don’t believe that plan on selling them, as their system complements existing DNS.
I still feel like Maidsafe need to do something similar or it will be chaotic.
Correction: Having been digging into the relevant code I see that the name for ‘service’ is, I now remember ‘subname’, which is used to look up the service in the ‘subnames’ container (previously services MD). Sorry for muddying the waters!
I wish I had a better memory. I’m pretty sure I argued for subName to replace service in the context of a SAFE address because it is different from the service itself. E.g. safe://thing.happybeing could be web, or email, or any other service. How could I forget? Doh!
Or maybe it is more powerful if it stays a “thing” service. This provides a built in language/directory or organizational feature for navigating and talking about the network. Just like Linux and Unix have the FHS, the safe network could have a common structure. It couldn’t be strictly enforced, but recommended as proper etiquette when creating services.
But for this I might be persuaded, but I think hardly anybody would use it like this. So I don’t think it makes sense to say that’s the way it should be used, when I expect it won’t.
I like this idea. It seems more natural to me too, and I think it could be quite useful.
I’ve often thought about this. I even wondered if we should we perhaps eliminate/pre-register all the existing clearnet TLDs to avoid impersonation/squatting/reselling/confusion… but then what happens when new clearnet TLDs are released in future?
@Sascha’s proposal actually solved this problem for us though! If I have the name jim I can be master of my own “TLD” world. I can have jim.com, jim.co.uk, jim.email whatever.
I think this is slightly missing the usecase for subdomains.
The think about crafting nice usable a URL structure is to make it hackable, and mirror the underlying information architecture of a site. So you would have a single site with nav structure that is mirrored usefully in the URL.
But a subdomain is useful when you want to break out from that structure entirely, and have two or more discrete information structures, or apps, that don’t intertwine.
I could seem being pretty useful for WebIDs/SafeIDs in this regard too.
Honestly SAFE is introducing a flat naming system, lets take advantage of that rather than trying to bastardise it and recreate a bastard form of Domains and DNS
Just keep to <service>.name/this/and/that
Its simple and easy to catch on for people. Most people now say google it. They don’t say google.com it They are thinking in flat names now and let us take advantage of it.
So we can say “Jim” it and “mail.jim” to mail jim
Or do you say lets go to davids place or do you say lets go to davids.domain.co.uk place
And claim all the TLDs and country specific ones (like co.uk) before the network goes live and I’d suggest claiming all the 1, 2, 3,4 letter combination ones too
But then again, we have a blank canvas, so let’s discuss the options, tho amirite?
So I’m agreeing with @Sascha in perhaps the important-unique-bit always coming first, and then whatever I want comes after, is more understandable, hackable, and straightforward.
