I only will reply to you to make a notice to you that blockchain or safe are projects that moved the way things where (that is stagnated and stall)
with nrs on safe we have the choice to stay old with unique domain names that you need to come up with something that is unique that is first come first serve? or better anyone get any name they want with a hash next to it?
ok my bad can someone sum up what are the different solutions?
I wonder it just got more complicated with the @user. I see no need not to just follow through as domain/user or whatever is preferred by the host.
The problem centres on what the domain and then nrs is?.. so safe://(?)
As far as I’ve followed above there seem two ideas… one stuck on the old safe://domainnamewithwhateversuffix
and safe://flex.domainnamelessliabletoperpetualownershipclashes/usernameorotherindex
The flex. adds utility in the face of perpetual ownership… providing option to more easily find xyz without necessarily a third-party service.
The alt perhaps is safe:/flex/domain which might prove easier transition.
The loss of country suffix is still diff but that’s ok
The version should point to latest as default imo.
The suggestion was not for version but a serial#
eg if fred chose NRS name of fred first then he gets fred:1 and then mary chose fred for her partner then that becomes fred:2 and so on. Its was not version
We need to lose the definition domain as that is an entirely different concept of centralised control. That is why its called NRS - Name Resolution Service and not Domain Resolution Service.
The longer we keep using domain the harder it will become to rid Safe of the centralised concept
For NRS the simplest is safe://name/whatever.
Problems is short names are taken quickly, good names taken quickly
Long term people use 2 or 3 or 4 word sentences for their name, something memorable. Like Jakes-fruit-market or computer-world or google-search or …
The search engine and links will help a lot for reducing typing, but even if typing, its easier to type words then strange combinations of shortenings etc or :nnn or @xyz etc etc
That’s a common interpretation but there will always be the generic sense as
…the set of possible values of the independent variable or variables of a function.
Nothing to do with centralised and everything to do with … is the name.domain available.
… but perhaps this highlights the problem above.
Why would a name resolution service allow only one owner of a word and forever. If it is not to be a centralised domain of one persons interest then it needs to allow use to everyone… the words that follow can represent their domain.
Also, just to note to transition people away from what they are familiar with you need to use language they do relate to. Creating mnemonic and other meaning will be a hurdle. What matters most is does it work… everything else will just follow on from that.
The very definition of domain is anti decentralisation. We’ve discussed this before and the result was removing domain and calling it NRS.
Domain ownership is a delegated “ownership”/rental from the TLD owners. Domains require a higher human authority to grant you that domain with a recurring financial rental payment. Its the definition and concept for general use and on the Internet.
So ridding ourselves of this is important and why DNS was rejected.
A name in Safe is not issued by some human authority. It is simply a name that is registered on the decentralised network perpetual storage, it does not give anyone a ownership of a piece of the internet.
People in general do not think google is a domain they just see it as a name of a site. Now if you reintroduce “domain” into Safe as you explain NRS then its a backward step. There is simply no need to ease people into NRS. Its simpler than domains and will be picked up quicker than calling it domains.
Usernames will be ownable then right? Maybe instead of people buying a domain names (which will now be NRS - non-ownable), they could buy account names. I see this going either way to be honest because combination of the two and limited space of characters will always result in people looking for the shortest and most attractive labels together.
safe://media.username or safe://media@username
A username like “go”, “corporate”, “cat”, “cooking” in combination with the non-ownable domains e.g.:
safe://asia@cooking or safe://europe@cooking etc will always be in higher demand than for example future names safe://asia@cooking127da519 or safe://europe@cooking1248a8gf.
I hope you see what I mean that there is no infinite free space available for catchy combinations, and one of them needs to be unique and ownable to tie this NRS space to indivual website with it’s own private unique content.
On Safe a name is just that rather than like a domain or account name, it is just a string which you own and can set up for different uses (a way to address files or a website, or a wallet etc.)
It is a human readable address. To be useful as an address it needs to be reliable, which means ownership by an individual rather than (as Rob points out rented from an authority, and corruptible via expiry, DNS attacks, domain transfer etc.).
I think it is fine to build alternative addressing schemes in an app layer, but the network needs something more user friendly than the network addresses, hence we have the Name Resolution Scheme which defines how one is translated in to the other, and how the container it addresses is structured for particular uses. This dictates how essential apps use the NRS, such as file access, Safe Browser and wallet.
Apps could use a number… point is more what is user friendly for humans.
You and many others are missing the point that the public reserve concept is trying to establish. Single dictionary words are what people squat and fight over. So 99.9% of the squatting nuisance is eliminated by making those public /non-ownable. In that case “safe://asia.cooking” would not exist as a possible “more valuable” option.
Your example of :
Is a case of picking a lame name. Nothing limits you to a gross alphanumeric or salted name like that, you could instead pick a decent two or three word combination. ex.
safe://asia.cooking-safely/
The single word uniqueness issue is further obfuscated if a ‘.’ is allowed in the safeid, so:
safe://asia.cooking.safely
or
safe://and.cooking.safely
becomes feasible for the ‘cooking.safely’ name.
The sum total number of unique words in the world is in the 10’s of millions, and the number of potential users in the billions. That combined with single word popularity is at the heart of the domain name scarcity. Placing single words off limits to private ownership while encouraging multi-word combinations solves most if not all squatting concerns and offers near limitless unique combinations (at least 1e15 for two words and 1e30 for four words, smaller for only most common or super popular words but could be augmented considering future/past tense and participles/genders and funny mispellings/colloquialisms). One can think of it like a two to four word mnemonic where the dictionary is “everything”. Adding numerics in good taste compounds this by other orders of magnitude.
The public name reserve concept in its most simplest incarnation meets all objectives. It also sets the stage for distributed indexing of public content through the reserved single word name locations that could be publicly mutable. Once this foundation is in place, it becomes easy for webcrawlers to emerge and offer more sophisticated search and safesite navigation capabilities.
@SmoothOperatorGR I expect we can create an addon/plugin NRS to do what you suggest – userid:x and domain:x
Really, there is room for everyone’s ideas here as there will be NRS’s added for the network over time if it is successful.
In the end there can be only one for an immortal network 
. Everything else is just a bookmark, plugin or a supplemental overlay.
Methinks you contradict yourself.
Edit: the inbuilt NRS could be a multi-NRS as well … a more decentralized system in that regards, e.g.: safe1:// safe2://
So as new NRS are voted in/approved by the global SN development team, then a new SafeX:// could be added to Safe:// as the original.
I’ve mentioned this before, but the Gentoo linux package management system is an excellent example/prototype of how this can work well. In Gentoo, there is a main repository index that is the most vetted and supported by the core devs. This is analogous to the core NRS. On top of that anyone is free to create or publish an overlay index with special additions / customization (analogous to your “safe-#://”). Users rely on the main index as a base and can choose which overlay additions they want access to in a seamless manner such that it is treated as one big index by the package manager. Rare name conflicts are typically managed through versioning, but the overlay name can be explicitly referenced if desired. Example (safe-overlayname://myservice.multi-word-safeid). The reason why it all stays manageable is because packages in the overlay are named in a consistent manner with regard to the main index. Typically the overlay is used to offer un-official versions or new packages that don’t exist in the main index tree. No one would think it a good idea to rename or redirect package names in an overlay to be non-unique (Example, package ‘apples’ in overlay points to ‘oranges’ in main). It would be a big hot mess.
This re-creates link rot, elimination of which is one of the very important things which Safe Network achieves. The reason is that if people can arbitrarily create URL schemes, links using a new scheme are not supported by any pre-existing software or client. That’s a no-go IMO.
Hence the “big hot mess” remark I made above. My admiration for gentoo overlays may have made me sound too positive about the safe-1, safe-2 concept. Or at least I wanted some of the pro-petnames people to do their homework about what that looks like in practice. Fundamentally, I am pro Global Unique Namespace… ie. “in the end there can be only one.”
Nice, I like that idea.
In the end there won’t be only one … so I think it makes sense to plan for the best way to manage what will come such that it doesn’t end up a big mess.
Are you sure? Depends on one’s perspective. For the client there is only one “safe://” . Everything else is just a “safe-overlay://” …
I’m sure that plugin’s will be developed and while that won’t be the prettiest way to go about it, they will be made as there will be a variety of reasons to do so and the cost of developing such a plugin won’t be very high.
Also, once someone does develop it, then it’ll just be copy and paste more or less to make additional ones.
I guess there’s some sense to that… safe-health-data://justonetopic and limits apps wanting limited data types.
I wonder the key here is to not make it matter… the problem with dns, is the focus on the name being pivotal. The less clashes of interest, the better?