.safe is the best option.
.safenet is too long, for something that will be typed billions of times in the years to come.
safe:// is too weird. Better to following the example of .onion, which is an accepted and widely recognized pseudo-TLD.
Do you understand the difference between a domain and a protocol?
2 Likes
I understand that the distinction is arbitrary at the interface. You can program the browser to represent its session however you want.
Iâm suggesting to work backwards from what is easiest and most expected by the user. The protocol is not necessarily germaine to that part of the design.
Anyway, do you understand the most elementary principles of having a conversation?
It is not arbitrary. Arbitrary would imply random choice and whim. There is a good reason to use safe:// instead of http://. Because The SAFE Network is a new protocol that is replacing HTTP and is not a new domain for HTTP.
1 Like
That does not matter to the typical user. To him it is a browser.
Any engineer who expects to impose his fineness of terminology upon the uncaring user has his head up his arse and is unfit for designing a UI.
If it doesnât matter to the user, then why would they care if it was safe:// or http://? In stead of catering to the masses that donât care, why donât we build The SAFE Network technicaly correct.
Edit: why is it so hard to have a civil discussion with you. You always revert to vulgarity and bullying anytime you donât get your way. I believe this is the last time I interact with you on the forum.
1 Like
To the user the choice is arbitrary because he is oblivious to the distinction you are trying to make.
The masses care enough to use it. They just donât care to respect your purist concerns.
To be clear, http is actually correct for .safenet. That is, HTTP is being used to communicate with the proxy. However, as soo as you remove the proxy and actually communicate directly with the safe net APIs, then it bus something different.
There are lots of other schemes. Adding another for safe net would definitely seem appropriate and desirable. We donât really want to hack a URL format together, especially when they will quickly become sticky and hard to purge.
Other schemes here: http://www.webreference.com/html/tutorial2/4.html and UriSchemes - W3C Wiki (inc. Official ones and how to register new ones).
Edit: interestingly, mailto and news both skip the // and are considered opaque URL schemes. However, this is more due to the browser passing control into another app, than anything else. Some info here: URI (Java Platform SE 7 )
Some specific on URLs, URNs and URIs on the above link too, which demonstrates a convention safe net should adhere to (I.e. not safe:, but safe://):
âA URI is a uniform resource identifier while a URL is a uniform resource locator. Hence every URL is a URI, abstractly speaking, but not every URI is a URL. This is because there is another subcategory of URIs, uniform resource names (URNs), which name resources but do not specify how to locate them. The mailto, news, and isbn URIs shown above are examples of URNs.â
4 Likes
safe:// is definitely familiar grounds to a massive majority of people. I need to start using that when explaining to customers about the safe net. It will make it 1000x more relevant to their understanding. Lately Iâve just been saying Iâm invested in something that will be as big as the Internet in the 90âs, and will eliminate credit card fraud, etc. But thatâs a mouthful, and leaves a lot more to be explained (especially if I just say the first part). The very fact that this new SAFE technology is so powerful that it adds another high-density dimension to browsers (SAFE:// could be the third most-used protocol in the entire world?) should speak volumes to how definite this project is that nobody else is doing.
8 Likes
This is a slightly fancier version of âfacebook is the internetâ. Claiming the safe network is browser-based is myopic. Itâs much more.
The safe network will be used in many different ways, not just for webpages in a browser. The representation of resources on the network should reflect that. safe: is the correct representation of resources on the safe network.
End users may not care about the technical details, but they do care about the vibrancy of the ecosystem. The best way to make the ecosystem vibrant is make it easy for developers to build products for the end user. Developers that see amateur and incorrect use of URIs will be frustrated and feel less reason to hold themselves to the same high standard as the underlying platform. End users will suffer from poor technical decisions, even if they never see it directly.
2 Likes
.safe is an existing TLD.
3 Likes
I still do not understand why this is a discussion. .safenet is supposed to be a temporary solution until we get plugins and a browser 
1 Like
Thanks, I didnât know that. That is the only sound objection in this thread.
1 Like
Because people have different opinions than you 
Youâre putting words into my mouth, then arguing that strawman. Classic sophistry. I was not stating my own view, but how the majority of potential users will view it.
My view is that safe as a prefix is a jarring break with the familiar, and also that new apps such as browsers need backward compatibility with existing systems.
Good point, itâs always good to discuss differing opinions.
This is a topic about using the safe: or safe:// protocol versus a .safenet domain. I deleted 1 reply as it was off-topic and a personal issue between 2 people without saying a word about what this topic is about. Keep it a bit cool please, and on-topic. Thank you.
4 Likes
I support the safe: - safe:// protocol and firmly believe that providing chrome users as reasonable a seamless access to the safenetwork as possible is the right balance.
Is there a reason the safe: protocol could not be the primary and preferred method and .safenet domain just facilitate access - with all the caveats and warnings - to the large chrome user base for a temporary periodâŚsay 12 months after launch?
IMO the chrome users and dev community should be included in the target.
3 Likes
We should only be conditioned by our greater vision ahead ,
not by temporary shortcomings of a quirky browser like Chrome
( which I use all the time , apart from other ) subject to change and adaptation .
Safenet has and is its own protocol and the standard is to use the scheme
model for its indication , and the host model for locating data on a protocol .
Scheme means safe: http:// https:// ftp:// etc , and Host means the
usual variations of subdomain.domain.tld/section/anysubsection
It would be utterly confusing & counterproductive to change that
established nomenclature for protocol schemes and data hosting
merely to circumvent browser shortcomings or unwillingness to
allow newly emerging players .
Why should adoption complying to the industry standard not also happen
on Chrome , eventually ? And why should we compromise a proper
implementation of our protocol & hosting to fit retarded policies ?
Letâs be principled all along the ride ; itâs longterm wisdom , itâs greater .
6 Likes
Everyone must be in the target group, even non-Chrome users. Chrome is so prevalent only because it is an opt-out option in the installation wizard of so many other apps, such as Acrobat Reader (and hardly anyone unchecks the box) and not on its technical merits.
The launcher should be an automated agent that runs on OS startup and sits in the system tray, red or orange, by analogy with a wifi agent, and the user clicks it and logs in when he wishes to access SAFEnet (no doubt the OS will cache its fields, needing only a click to activate).
Thatâs how it will actually happen, regardless of what anyone thinks here and now, if not straight away then someone will write it like that.
The remainder of the user experience will be similar to current usage of the Internet, if not straight away then someone will write it like that.*
Indeed, that agent in the system tray will have a checkbox to connect whenever SAFEnet is available, again by analogy with a wifi agent, (if not straight away thenâŚ).
Am I describing an overall pattern here? Yep. All the bloviating in the world wonât make a shred of difference (vote on this, vote on that). It will follow efficiency and usability, implemented by the more perceptive developers.
* I can see myself and others repeating that phrase in future so maybe it requires an acronym.