Thanks yes this is exactly what I was trying to say.
…or also some sort of proxy pac thing
I agree and we only get one crack at this.
I don’t care about the developers, going to safe: is just a part of professional development and keeping up with new trends and standards…adapt and migrate, this is a competitive and no business worth it’s salt will stand by and let new starts gazump them, just because they have to change code to run on SAFE.
If the bar is set a little higher and you need to do some research and change some code, I think that’s actually a good thing. The majority of users are going to come in via the popular applications or their replacements, if it’s an incumbent then they have the resources to adjust, if it’s a startup…well that’s what startups do, they disrupt and eat this stuff for breakfast, take market share…game on.
I don’t care about what the IETF or ISOC proclaim is standard, you spend 10 years developing patents just to roll over to something that is acknowledged as broken by the original creator of an IETF RFC.
If we go with safe: maybe adoption is a little slower, they have 10 years to migrate…will incumbents risk waiting it out?
6 Likes
@joshuef This is a bit of cool hackery on IPFS’s part - could we learn from/apply this approach of theirs?
1 Like
It’s hard to believe this is even a debate. (spoilers - it should be safe:)
At the highest level, this is a discussion about URIs
From the Wikipedia entry for Uniform Resource Identifier:
A generic URI is of the form
scheme:[//[user:password@]host[:port]][/]path[?query][#fragment]
The debate is between a scheme safe: and a top level domain of the host .safenet.
Schemes
RFC 2718 Guidlines for new URL schemes is the resource to understand why new schemes may be introduced, as proposed by using safe:
There is a description of schemes as a protocol specifier in section 2.2.2 URL schemes associated with network protocols
Most new URL schemes are associated with network resources that have one or several network protocols that can access them. The ‘ftp’, ‘news’, and ‘http’ schemes are of this nature. For such schemes, the specification should completely describe how URLs are translated into protocol actions in sufficient detail to make the access of the network resource unambiguous.
Section 2.3 Demonstrated utility outlines reasons against using safe: as a scheme:
New URL schemes are expensive things to support. Often they require special code in browsers, proxies, and/or servers. Having a lot of ways to say the same thing needless complicates these programs without adding value to the Internet.
Top Level Domain
The host section of the URI contains the top level domain.
Hosts are explained in RFC 3986 - Uniform Resource Identifier Generic Syntax, particularly in Section 3.2.2 - Host
The host subcomponent of authority is identified by an IP literal encapsulated within square brackets, an IPv4 address in dotted-decimal form, or a registered name.
Hosts are used to locate a piece of information.
The safe network is not a different location for data, it’s a different protocol.
It is abundantly clear at all levels (technical, professional, developers, end-users, software libraries, …) that the scheme safe: is the correct approach and not the top level domain.
If safe is an improved version of the internet, let’s do it right by using safe: and not go backwards by using an unregistered top level domain name based around a centralized DNS system.
20 Likes
- Because I’m one of these people that hate having to download yet another application and LIKE using “a legacy browser.” If you’ve gone to the trouble of tricking out firefox, have all your favorites on firefox, and are familiar with firefox why do you want to move to another browser? This is the same problem I have when trying to get people to adopt instant messenging that can be encrypted via pidgin. People just don’t care. They use skype or facebook or whatever else and don’t want to bother switching to a new app. 2. What happens when your browser/launcher fails because you’ve got too many tabs open or something thus causing a cataclismac crash of every single SAFE app you have running?
So you propose to make the Mac version of SAFEnet? Have you ever used a mac? Yes they are awesomely user friendly but good luck installing linux on them or switching out the hardware on that walled garden of a centralized box. My point is good user friendly documentation would be a better solution for those problems than centralization or confusing the issue further.
I think that the Launcher should have the ability to have addons and perhaps having a browser intergrated to the launcher as an ADDON or having some kind o crossover interface between the SAFEBrowser and Launcher might work. (Similar to how some websites have integration protocols with their forums or photogalleries). But using the SAFEBrowser shouldn’t be required in order to use the launcher. You should be able to opt to use whatever browser you wish.
1 Like
I am totally at a loss at why we are still having this discussion. The browser proposal was published and people have already sent their money and support. This is the exact reason we are still talking hypothetical of the real SAFEnetwork rather than using it even in its most simple form. I love the mental exercises and there is a seemingly an unlimited pool of creative geniuses here, but lets just build one damn thing already and finish it. Then we can spend weeks analyzing and pontificating to our hearts content.
This %^&&$ browser to me was a great SIMPLE project to prove the community can drive development. I want a wagon…sure it can be a sleek amazing wagon but if it doesn’t have wheels and able to carry anything than it is worthless; I don’t care how many rocket blasters or force fields it has. @joshuef your requested money needed to build the browser is there, so just build it. At this point I think everyone’s time could be better spent building shit. Really unless you have provided some kind of tangible effort to this specific project then you should just be watching and learning how to actually build something instead of just talk about it. @joshuef it is almost impossible you are going to build the perfect browser that will never need changing through our lifetime. Hell I’d be happy if you build something we all decide is crap—learn from, and then build something better later. I always learn more from failure versus from my successes.
Just build it please. Then we can talk after. If not then someone else will and three weeks from now and you are still talking about the dream browser you can just send those funds to reimburse someone who has enough confidence to finish a project; this “first” iteration is likely to be terrible and that is okay. I don’t care if I have to use a decoder ring that translates everything into Japanese…I’ll still use and test it all the same.
2 Likes
Because I’m one of these people that hate having to download yet another application and LIKE using “a legacy browser.” If you’ve gone to the trouble of tricking out firefox, have all your favorites on firefox, and are familiar with firefox why do you want to move to another browser?
This is a good point - one I’ve made myself in the past! 
It’s not an issue though with my proposal (which has nothing to do with Macs or walled gardens). Anyway, legacy browser user experience with my launcher in the browser proposal is as follows:
- Download SAFEnetwork
- run SAFEnetwork - get asked if you want to use an existing browser - answer yes
- choose one of the options - choosing firefox/chrome etc this will enable a proxy for you (automatically)
- browse using your firefox browser as normal
No different than with stand alone launcher, but… if you ever want to just browse quickly to a SAFEnetwork website or app you can - if you want to - just open the SAFEnetwork itself and use the browser tab that’s in there.
What this achieves is an easy migration path for legacy users. This is the key to mass adoption: disrupt existing workflow as little as possible while providing small, easy steps towards a better workflow.
As they spend more and more time on SAFEnetwork, and in SAFE Apps, the user will at some point want to migrate their bookmarks etc to the SAFEnetwork, but they don’t have to move anything until they are ready to do so. We just make it possible, and easy to transition, step by step.
4 Likes
This - …
1 Like
That sums it all up so well , we should all just line up consenting to keep coherence aboard ,
more or less , the many reasons in favour have been laid out with much clarity & simplicity .
It appears to me and others here quite clear that there is enough fear inducing a rather flawed
compromise . Such fear is not a good counsellor , it’s been & is the courage to go for the new
that wins our hearts and minds over , gaining ground as it reaffirms it’s independent position
regarding how internet can be envisioned for the better .
We really shouldn’t submit to the very flawed and vulnerable ways we try to overcome . And
moreover , instead we should go proudly forward naming our protocol for what it is under the
scheme definition as safe: sfn: or sf: & leave the host section to locate data on our network .
It’s not wise to delude ourselves by creating a compromised approach ,
reducing our protocol and scheme artificially to fit the ‘host’ definition .
4 Likes
So much idiocy about terminology and image. Get a fricking life!
If it works as it says on the tin then you could call it “a lump of green putty you found in your left armpit” and they’ll still be lining up.
Cheers,
The Non-Voting Vogon
4 Likes
Just wanted to say thanks again @joshuef for giving us back safe:// 
Been using it on the browser a bunch lately.
Guess we never know how much we really appreciate things until we lose them!!
3 Likes
Another +1 for “safe:” instead of “.safenet”
I just downloaded the browser that was forked from beaker, and using safe:// automatically feels like a much, much nicer experience for browsing. It looks much cleaner and shorter in the address bar too. (“safe://dirvine” vs. “http://dirvine.safenet”, or, for my little test site, “safe://test.am2on” vs “http://test.am2on.safenet”)
safe:// wins this one out for me. It’s simpler, cleaner, and the technically correct answer.
4 Likes
Another argument against .safenet - people try the links without the launcher/proxy and assume it is broken/rubbish.
Putting it safe:// should cause the browser to either fail hard or try to search, both of which may better instruct the user to configure their system.
4 Likes
Using a fixed route location will mean all links relative to the domain must include this. This would be even harder to change from than .safenet, IMO, as either .safenet or safe:// resolve to the same place for “/”.
1 Like
Another argument against .safenet is http:// shows as insecure in the browser - no padlock, which people will assume should be present.
As no top level domain exists, https is always going to warn users about security too. This would obviously be ironic considering the advantages of safe net.
3 Likes
interesting, that one didnt come up at all when we were pondering about it i think.
1 Like
It will be factually misleading to maintain http:// on safenet sites ,
we have our own protocol , and to state we are on the http://
protocol should be avoided as soon as we get a browser .
While in testnet and early alpha , it’s okay to use the workaround .safenet with proxy setup on http://
2 Likes