Discussion: safe: or safe:// protocol versus .safenet domain

Development
21

I agree that if we choose to go with safe:// the browser either has to be built in to the launcher (or vice versa) or at least bundled together with the launcher software (1 install, 2 programs). So it will be a mandatory installation.

I was wondering wouldn’t users need to install the launcher software even if they would use a plugin in another browser? Or was it supposed to work with just the plugin, where the plugin is the launcher as well?

If not the integrating or bundling with the launcher would not hinder adoption since they need to install the launcher anyway. In this case making safe:// links open the supplied browser like Francis suggested will be all that’s needed to make it a somewhat seamless user experience.

2 Likes
22

I agree with this. I like that the launcher is one app that does a single job, access Safe. I think there are many disadvantages to merging it with the browser that should be kept in mind.

  • It exposes the code to developers that are completely unrelated to Safe. I prefer if people tinkering with the code of the launcher are developer specialized in it and people I trust and know, MaidSafe.

  • It makes it less stable and secure since any bug in the code of the browser might make it crash or expose vulnerabilities. You really don’t want the launcher to become broken because someone tried to add a feature to the browser.

  • Forking the browser could lead to a proliferation of different launcher code. It also makes it easier for other browsers to compete with the first one since they don’t need to also code a launcher.

  • Having to run the browser to access Safe consume unnecessary resources if you just want to use a standalone Safe app. This become especially important on less performant devices.

For all these reasons I think it would be a mistake to try to merge the launcher with the browser. Bundle them together for sure though, no problem there.

Anyway my 2 cents.

2 Likes
23

If that were the case, then you must be the wealthiest person alive as you can predict markets and make billions. No, the truth is we cannot predict human behavior to think otherwise is hubris -but if you could, it would require a huge burden of proof on your part - like your bank account balance showing how you’ve profited off of such knowledge.

24

Hey guys!

I am just wondering if the way IPFS solves this issue wouldn’t be the best!?

Please have a look here:
https://github.com/ipfs/go-ipfs/issues/1678

2 Likes
25

As i understand it, IPFS is using a “normal” Folder prefix “/ipfs/”. This can be recognized by all browser-extensions. Also an additional protocol for custom browser would be possible.

IPFS has a pulic gateway which is, in my opinion, a really good thing for user adoption. (https://ipfs.io/ipfs/QmYwAPJzv5CZsnA625s3Xf2nemtYgPpHdWEz79ojWnPbdG). Because they also use the prefix “/ipfs/” there, future browser extension can recoginze these URI’s also and redirect to a local IPFS-Client instead of the centralized gateway.

@frabrunelle Is such a public gateway planned?

1 Like
26

@Krekc yes, browser plugins need a separate app (e.g launcher) in order to access SAFEnetwork

@DavidMtl you raise things we should consider but I don’t accept that they are serious issues. Principally I don’t know if merging them makes the code significantly less reliable or introduces security vulnerabilities. I see your logic, and accept complexity is a source of problems, but having a separation is also creating complexity so I think it’s a moot point without further insight.

Also, the last point can be mitigated: alternative “launcher” can still be provided to cater for a “no browser wanted” low resource option. Building a browser that doubles as app access point doesn’t prevent having other access point apps. Even if this wasn’t the case I think as with the clear web, the browser will be the killer app on SAFEnetwork so long as people are still booting locally rather than directly from the network, making the SAFE browser ubiquitous for almost everyone for some time.

Separate point: writing the above makes me question again why we call it “Launcher” - it was once going to manage SAFE Apps (maintain a list from which users would choose what to run - hence launch) but now it is just an access point, so maybe we should reconsider that. I think “Launcher” is confusing to users and developers. Let’s kill the Launcher! :wink:

3 Likes
27

Ridiculous analogy. Understanding human behavior is far different than predicting stock markets or the price of oil.

28

@anon20713104 thanks, that’s very useful.

What’s clear here is that there are two almost orthogonal issues here, though with some implications for each other:

  • the total user experience (SAFEnetwork access: launcher/access point, SAFE Apps, web browsers, browser plugins, and content addressing)
  • URL format used in browsers and how this maps to SAFE content URI addressing

It’s confusing because there have been some assumptions that are not valid, as well as implications from one to the other. Also, legacy terminology such as “Launcher” that is a bit misleading IMO.

Maybe we should focus on the user experience we want and then see how this impacts the URL scheme afterwards rather than the other way around as we have been doing?

29

@DavidMtl is right IMO. If we merge the two it’ll require that you start the SAFE browser to authorize separate apps. Not good…

30

I have not read whole thread yet, but a couple of points:

  1. those who want to expose safe net sites over clear web can create a proxy. A docker container which mount the safe net and proxies requests to it (via, say nginx), would do fine. More refined solutions could come in time.

  2. there is no need to bundle everything in one big app. Keep them separate and interface where necessary. If people are desperate to integrate the launcher with the browser, they can just get the browser to talk to the FFI interface directly (I.e. the browser bypasses the launcher). There are integration advantages from this approach to too (keep web apps together, but treated as full apps on safe net).

31

+1 for safe: and I’ll keep this short since I’m not too well read on this topic. Having the url as such does send a clear and calming message and also leaves open the possibility for .com/.gov/.edu/.nets correct? I think that is one familiarity “leg netters” (that’s what I’m calling legacy net people now) won’t want to give up for ease of organization and memory. Just my thoughts

3 Likes
32

@Pierce Why is it not good?

Look practically, what’s the first application almost everyone starts as soon as they fire up their PC, or the most used App on mobile?

If you don’t do this, the user has to know and remember to always start the launcher first. Or rely on every app developer to include a prompt if it doesn’t get a response from launcher. I expect many apps won’t do this because, let’s face it, most developers are human (MaidSafe excepted) and therefore lazy, forgetful, pressed for time etc. :wink:

As I just wrote, I think we need to think through the various user experiences and consider the form of URL that works best with those.

I’m also open to a separate launcher (with a different name :wink:) installed with and started seamlessly by the browser, I just want us to think through the details of both options in detail rather than vote for one or the other before doing so.

2 Likes
33

Launcher implies it will launch an application. I would suggest calling it a gateway. Gateway implies allowing access.

1 Like
34

The more I think about it, I have to agree with @happybeing that it would be best to integrate the launcher/gateway with a browser. This would give the user a seamless experince and let the user know that they are using a new internet.

1 Like
35

This may need a new topic @moderators

@betterthantrav:

Launcher implies it will launch an application. I would suggest calling it a gateway. Gateway implies allowing access.

Gateway is technically correct but a bit rubbish (generic, technical - how many granny’s will think “network access point/connection” when they read “gateway”?). How about just calling it SAFE Network as in…

Install SAFEnetwork
Run SAFEnetwork
Use SAFEnetwork
Start SAFEnetwork
To run the SAFE-FS App first install and run SAFEnetwork
etc

1 Like
36

Well it’s an insight that we already have, it’s called separation of concerns. It’s the reason why many popular games also use a launcher to handle authentication and update. It makes things easier to manage.

The launcher also needs to be very agile so if an update needs to be done quickly there should be no chance that it gets stuck because the browser is trying to push an update at the same time and failing its QA test.

I understand the userability concern but I can’t see how bundling them together makes things so complicated that we are ready to open such a big can of worm.

Either way. That’s still pretty far from us. Developing a launcher isn’t a week-end job. So I’m not overly concern about this being done any time soon especially since we already have a pretty good launcher already. I think dev time should be spent elsewhere.

3 Likes
37

With an .safenet extension this will not be popular, simple as that. Make it a prefix, safe://. If Chrome wont reprogram to support it so be it. After all, we are removing servers from the Internet, guess wich company stands to lose the most if that happens. Answer is Google. Today nobody can catch up to them with just a good idea and good code, they have server complexes worth billions. Ofcourse they will not embrace resetting the playing field so that anyone can compete again. When safenet becomes popular Chrome may support safe:// or it may not, so be it. Damn the torpedoes, full speed ahead I say.

9 Likes
38

safe: sends a clear message. A new protocol. A new internet.
.safenet is “just” a TLD. Although, a safe one.

But, I agree that it is not as clear cut which approach is best for fast or large adoption.

4 Likes
39

Is it an option to support both: safe and a domain (now .safenet)?
With the domain a temporary solution until Chrome and other browsers support safe:
Of course when a webdesigner creates a link he has to choose between the two.
But maybe replace .safenet with a name that indicates safe: is preferred: e.g. .safetwo, .safetoo, .safetmp, …

40

Yeh, I don’t see there being any reason there can’t be (and why there won’t eventually be) many different launchers (like there are many bitcoin wallets).

Some browser integration might be desirable down the road, equally, a browser could detect/trigger launch of the launcher too, if it’s not running.

I think for an initial browser it’s not necessarily a key feature. (It could be reinstated as a further stretch goal, or we look at this once we get the initial, simpler, browser out).

As @Viv has noted, there’s no direct security benefit of safe: vs .safenet.

What was leaning me towards .safenet was the idea of adoption and a consistent experience across all potential implementations. (Imagining a chrome extension as inevitable.).

I mean adoption not only in chrome etc, but also with the aim of a SAFEr Browser being a user’s main browser. Beaker itself is not as polished as Brave. .safenet is possible in Brave. But perhaps this is going to far at this point? (which does seem to be the case; features can always come later).

As noted, by a few folks, chrome / clearnet browser extensions will be inferior as who knows what else is installed in the browser. We cannot control this.

I also think these extensions will be a given… As noted above, TOR do not recommend extensions to access the network, but extensions exist… Eventually, they will exist for SAFE too.

Any extensions can/could do parsing of links to the preferred format, or trigger SaferBrowser launching with either safe: or safenet links.

The choice is then somewhat… should we be looking to facilitate potential implementations in the name of adoption / a consistent experience? (I’m aware of some sentiment around this already…).

If this is something we decide not to facilitate, the choice of safe: vs .safenet then is somewhat simpler.

2 Likes