This is probably beating a dead horse at this point, but safe: is definitely the technically correct answer in this case, as the SAFE Network is another way of serving sites rather than another type of domain. It’s most analogous to things like HTTPS, and no-one would ever have considered writing URLs for HTTPS sites as http://website.https instead of https://website.
Besides that, I think that the official SAFE browser should auto-infer the protocol like most normal browsers do these days, so if someone types “base.hdastwb” into their URL bar it should automatically take them to safe://base.hdastwb. This is a much more streamlined way of getting to SAFEsites quickly, and one that would be much more clunky with a TLD than with a proper protocol.
As for the topic of third-party browsers, I agree that Chrome support isn’t something that we should be focusing on, since Chrome is not exactly the best browser for the privacy-aware anyway. However, I would very much like to see a Firefox plugin/distribution/fork for the SAFE Network for some very compelling technical reasons: all of the other browsers (Beaker, Brave, and Chrome) that have been thrown around here are basically based on Chromium (or at least use Chromium’s JavaScript and layout engines) and so they’re all basically the same internally. Firefox is based on different technology, and it has a different set of advantages (such as better support for asm.js and lower memory usage), and I think that having more options rather than one “one-size-fits-all” option is better for users. This is completely irrelevant to the safe: vs. .safenet debate since Firefox actually has a comprehensive plugin interface which supports custom protocols, but I think it’s an important point to make considering some of the other discussion that’s been going on.
It’s not about those who have a SAFE enabled browser… those will do whatever, it’s about non-SAFE users seeing safe: links in the normal way as URLs.
Also, will it not created extra overhead for the browser to seek out what is safe: as well as what it already does for http://… perhaps that’s not an issue.
I agree with @davidpbrown about the validity of mixed content but would also like to point out that using safe:// won’t stop anyone from doing it. As long as the browser knows how to interpret it, by using custom protocols for example, it should be just fine. You would need to install an extension for this to work but you also need to tinker with your proxy setting for .safenet to work so both case are not transparent to the user.
The big advantage of .Safenet is that it works right now and also works with Chrome. But I’m not sure this makes a strong argument considering we are still early in alpha and everything is allowed to change.
So in the long term I’m more on the side of using safe://. As @cretz points out that would be the standard way of doing it. On the short term I think it’s fine to continue to support .safenet. The network will be reset a few times before it goes live for real so it’s not like we will be stuck with a bunch of incompatible data. Meanwhile, we should work on creating extension for all browser that support custom protocol so when we finally decide to switch to safe:// people have options on how to browse Safe.
So I vote for the third option: .safenet for now, safe:// at launch. Which I believe was the plan from the start, .safenet always has been a temporary solution, as long as it’s useful let’s use it. When we are ready to replace it then we’ll do that.
For me, safe:// is the correct way to go. It’s clear, neat. There is no confusion, when you enter that in your browser you know that you are connecting into something different (better ).
I hate .safenet ! To me this is totally wrong.
.safenet suggests that this is just like another top-level domain (like .com, .org, .io, ect…). Which it is not!
Web browsers have evolved into digital vehicles. They have a variety of features, and customize in every detail to give the best user experience.
This site shows the most popular browsers (vehicles) today. Obviously, Chrome is #1 at 37%.
Networks like: clear net, dark net, and soon to be SAFE Network… are travel locations in the digital universe. There will be many curious people traveling to the SAFE Network.
What happens when tell people to exit their favorite Chrome car and use our SAFE car to travel inside SAFE? Some will, some won’t, and others will wait until a friend or relative convinces them. Like it or not this is a barrier to entry.
I hope we seriously consider what we’re asking. It’s not a big ask for early adopters. But total strangers are a different story. I am in favor of using ( safe:// ), which is my “personal” preference. But there are limitations fishing in a smaller pond compared to the open ocean. Hopefully we can grow our pond into a lake and eventually become the new ocean but right now, it’s just a pond.
Regarding the SAFE Browser
Assuming we successfully create our own exclusive browser ( safe:// ) or non-exclusive browser ( .safenet ) have we considered long term questions?
Who and how will the SAFE browser be supported and funded after initial release?
Can it compete against other browsers that have spent years polishing?
Will it offer a complete experience or is it just for limited use on the SAFE Network?
If the SAFE Network is as good as we hope, other browsers will adopt the ( safe:// ) protocol but I think we would have to be super amazing awesome before that happens anytime soon.
TL;DR
My advice… get it done as cheaply and easily as possible with minimal consumer effort to transition. Otherwise, we might bite off more than we can chew and end up choking. If the Network does really well, we will evolve!
It won’t be a smaller pond for long at all while we have things like total uncensored data and ability to earn $$$$$$ through farming.
People download Skype to chat.
They’ll download SAFEr to be free
EDIT: And let us not forget that it’s not like .safernet has no downloads involved. You still have to download & install the plugins! And possibly .pac’s. So .safernet is not better.
No, not possibly pacs. At least not anything that would be built as part of the SAFEr browser proposal.
I understand you don’t like .safenet, but that’s simply not true and as has been noted a few times.
There is a working POC for this that will work wither with safe: (beaker), or .safenet (brave), without a proxy.
Downloading plugins for a browser is a likely occurrence in the future. Plugins for clearnet browsers (which is not something proposed to be built as part of he SAFEr browser proposal) would not require a pac or proxy (if they were built properly), no matter the final implementation URL structure.
But that’s not true either. A Chrome plugin could just as easily route requests to the launcher without the need for a proxy. It just won’t be able to handle safe: links as a url construct itself.
So a .safenet link in a chrome with SAFE plugin would not require a plugin.
What I’m asking is that if Chrome doesn’t need anything (plugin, pac, etc) to access .safenet links on SAFE (is this what you’re saying?), then why do we still need a pac today with FFox? Can we use chrome now to view all the current test net websites?
I have to turn in for the night. I’ll try and fire in tomorrow morning before I’m away for the weekend to clarify more about this, @whiteoutmashups. (I’m not familiar with the FF setup)
).