Perpetual data and volatile names don’t seem like ideal bedfellows, imo. As a user, I would expect them both to align.
Why should there be a single cost to store data forever, but a regular fee for a name? They feel at odds with one another to me.
4 Likes
I think it would be downright confusing for new users and also the search engines could not detect the legit site and a scam site meant to mimic the legit with only the payment address changed. The search engine might even have both in the search result and the user (new or old) would not know the difference.
Really the only way is for bookmarking, but that is only good if you knew you got the right site and booked mark it. But even older users still go to new sites regularly, some for buying stuff and they can be caught so easy
So telling people to go to safe://xyzsite would pick the latest highest NRS price site, and even giving a list of the others does not help since which one should they pick if there are more than one?
1 Like
The question was for @jlpell when he said “These common PUBLIC dictionary words should be free to use like air”. In this context what happens when I enter for example safe://mushrooms and several people defined mushrooms NRS entry?
Seneca’s answer is that the most expensive entry is selected. @jlpell finds this awful so my question was what is his answer.
In a system implementing first come first served the question is irrelevant because a name has only one content, but then there is the squatting problem which is a different question.
Sometimes you just have to put up with the smell.
1 Like
Yes I agree. Maybe we can simply reduce smell with a formula linking NRS entry price to name length (the longer the cheaper).
I also agree. This would add complexity and technical risks.
1 Like
One option is that nothing would happen because such a generic word is non-claimable.
A better option is that it is usable by Everyone. An index would be presented that lists all NRS names that are associated with safe://mushrooms. For example:
safe://mushrooms
|–>safe://mushrooms.tfa
|–>safe://mushrooms.jimcollisom
|–>safe://mushrooms.jlpell
The safe://mushrooms could be a public appendable data that anyone could add their address to (and maybe a short description). This generates a steady stream of PUT income for the network. It also allows for an easy way to navigate the network before search engines arrive.
2 Likes
This might be the same thread bumped again that I’d noted the opportunity that having flexibility on the first word provides for alsorts of other utility.
You could more easily know where to find alsorts with a consensus over time - in the absence of a crawler. safe://applications or safe://app-store would be available to everyone.
Domain names seem like an avoidable error and a bad element of the normal web and runs aground of the complexity of opinion on the value, obliging some oversight and liability or a wild west greed indulgence with a minority spamming NRS to register domains.
The alt as jpell is noting would help focus on the utility and the data as being more important the url.
More flexibility is better for the user… at the expense of those who are trying to leverage brandnames for profit.
There would still be perhaps safe://www.brandname but I can’t see the value and prefer that it is considered to be a null and easily accessible in a way then that can dodge other’s being selfish.
Edit: Also perhaps to consider, is if there is risk with NRS that do not age and the clutter of those then becoming a problem, if there is not simply flexibility built in.
3 Likes
Only if “brandname” is not a common dictionary word from any world language. So “apple” and “google” would need creative differentiation.
Ex. safe://apple.themegacorporation-thatmakes-trendy_expensivekit_1984
2 Likes
This isn’t that dissimilar to Seneca’s proposal. The difference is that you wouldn’t see all the choices presented and the continuous auction is to aid in the browser resolving to the highest ranked.
As for the user being able to differentiate several safe://mushrooms would probably come down to the public key or SafeID that published each.
This being presented to the user early days doesn’t bother me which would mean the continuous auction would then be unnecessary but at some point some kind of ranking or verification should come about.
The continuous auction idea is supposed to make a decentralized effort to allow the browser to resolve to one site for a (hopefully) better UX but not without some down sides.
Again, registering the same domain would be cheap for anyone. Anyone could register safe://Google for cheap! But the network would know the unique address for each, and what SafeID published it could also be presented or available to see.
safe://Google registered by @jlpell
safe://Google registered by @JimCollinson
Etc
But then you could have someone grab @ Google to make the resignation seem more legit.
So is there an auction for SafeID’s? Or are those a free for all too?
Above is the same as what you have suggested without the .jlpell at the end, being presented to the user is not the best UX but maybe a better middle ground and allowing domains to be cheap to keep and permanent, which does fit the fundamentals so that is a nice touch.
None of these are perfect and seems like a tough nut to crack.
Why should an auction determine the highest rank? Hint: It shouldn’t. My proposal essentially crowdsources the indexing process that sets the foundation for search. If theindex is simple and human navigable via hyperlink, it serves an important utility for traversing public data in the early network in the same way we used to web surf in the early 90’s. The browser or other search apps can build from there and rank indexed items according to the whims of the client.
That’s just an opinion. I think the reasoning behind a continuous auction is a good attempt to solve a problem.
Obviously, it doesn’t have to be that way and there could be something better. No offense but your idea isn’t really a solution for the end user, just removing a small amount of complexity to the ones registering domains, the network, and browser. Still good enough, imo. Again, just another persons opinion. I’d be happy with it but I’m not sure grandma would be.
Edit: ah, I see you added to your post. If it builds towards something useful then great.
I disagree. The value and utility of information to the end user has nothing to do with how much marketing budget company A is willing to spend to get their name to show up first via a continuous auction. An auction is antithetical to Safe. Furthermore, pet names are just convoluted bookmarks.
We naturally use words to search for new information we are interested in. Interested in cars? Go to safe://cars to see a list of every safesite ever made where the owner considered their site was related to cars. Too much information there? Use a simple app to sort and search the data listings for what you want. Where can you find an app to do this? Go to safe://applications to see what is available. The process will become more sophisticated and easy for grandma as time goes on, but you need a good foundation to stand on that offers globally unique identifiers which are easy to navigate.
Note: we are already intuitively doing this now on the testnets when we post a list of available safe sites people can go look at.
1 Like
This seems like a reasonable experience to me, unsure what others think.
I’m not in the mood for any debate at the moment. Not that there is much of one. I just want something that works for all participants and you make good points.
As a plus, the labels feature that @joshuef had proposed long ago may help with searching such an index.
Thanks
1 Like
You think you are solving this issue, but now short/generic usernames are becoming part of the issue.
1 Like
Please explain.
Eventually number of unique usernames that are short, easily remembered and wanted will also run out. So you will get a super useful popular NRS name like ‘video’, ‘picture’, ‘blog’, but in long run usernames will run out, become more complex and harder to type over etc, accessibility goes down.
Obviously if names mean anything, there’s a limit but a non-owned first element is a long step away.
There’s likely some additional flex possible - who knows safe:/fr/video or just safe://video2 reboots the whole option on old names that are pinned down. If it becomes omnipresent then video:/decade/ would also help indexing… anybodies guess what will become consensus.
It is a problem for a perpetual web, where event the traditional internet domains do age.
Maybe what the “please let the price go up 
” crowd don’t take into account, is A.I. coming onto the SAFE Network at some point. 
What’s more efficient for A.I? 
1 Accepting bitcoin, Ξ, tether, ¥€$ --exchange $AFE
2 Accept $AFE
Not saying that A.I. won’t trade, matter of fact it loves the “clueless consumers” who provide it cheap utility money. 
Under the brainstormed scenario no one could claim, but Everyone could naturally use simple words like ‘video’ or ‘blog’ to guide clients to their content by indicating the unique video or application “service” offered by the content provider. ‘Generic’ single dictionary words could not be privately owned since they are a public commons.
Consider the unique safeid such as yours being used to describe the location where your published apps are stored. (ex. safe://applications.deusnexus) The safeid ‘deusnexus’ is able to be privately claimed/owned because it is not a simple common dictionary word, but rather a unique composite of words.
Under this scheme, forming unique combinations of characters to construct novel “words” is the valid way to construct a privately owned id. The simple fact that there are less unique three letter combinations of common printable ascii characters than four or five letter combinations is just a matter of mathematics. Usernames will get longer but they won’t “run out”. In past discussion we also mentioned that current three-letter domain words used online like www, net, org would also be public and non-ownable. Moreover, there is no absolute requirement that one needs to stick to “usernames” when unique “user phrases” can be more articulate and fun while also being easy to remember. (Ex. safe://applications.by.bill-nye-the-science-guy )
Just like a single username/password is insufficient for Safe credentials, I’d say single user NRS locator names are also insufficient for Safe in an analogous fashion. Small novel combinations of characters or phrases of catenated keywords can be unique and memorable while simple to type in an address bar or verbally communicate offline.
2 Likes
That’s what www does… safe://www.deusnexus
The alt seems a hard confusion because somewhere you need the sum of all dictionaries just to cater for it, where keep it simple seems… simple.
1 Like