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

[betterthantrav]

@whiteoutmashups

@betterthantrav

This topic is to discuss the possibility of replacing the term Launcher with something more fitting.

@happybeing came up with an interesting point about the term Launcher.

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!

Launcher implies that it will launch an application. This is no longer the case. The launcher is more of an access point into the SAFE Network.

…

[drunkcod]

The Launcher is the new modem! …

We managed to get online and surf the webs when it was a two step process to first connect and then start a browser or email client… I think people can still manage that.

Integrating the Launcher/Gateway/Connector/HeavenlyPortal into another thing seems wrong for many reasons, separation of concerns, release speed, clarity…

[happybeing]

@drunkcod if by “we” you mean a very small proportion of early adopters… then I agree with you. But it is not a strong argument IMO.

[digipl]

If our problem is principally Chrome.

Is possible to made a plugin that capture all the safe://whatever and convert, to Chrome, in whatever.safenet? Maybe using getURL?

The ideal will be have the safe:// but still the possibility of using Chrome.

[drunkcod]

@happybeing I just don’t think the “people can’t figure out how to start two apps or why” argument is very substantial either so I guess we’re even then

There will be a need for a stand alone launcher for quite a few scenarios so that sort of leaves the question “is it convenient enough to warrant the extra effort & complexity to also but it in the browser?”

I just can’t see how it would not muddle the waters, since then users have two routes in, either they start the launcher and then their favorite apps or “The Browser” (the browser then needs to check that no launcher is already present and launch its own version). Or the user starts the browser that then need to prompt for SAFE Network credentials (in order to create an internal launcher).

In the second case are any subsequent apps then granted access in the browser?

I can already imagine the hilarity of explaining to users that depending on in which order they start their applications they need to click Ok in different apps to grant access…

You’ll also teach them that giving away your safe credentials is an expected thing so it only takes one rouge app that does something remotely useful (like showing cat videos) and someone will be harvesting credentials like there’s no tomorrow.

[whiteoutmashups]

Made a list of pros & cons mentioned in this discussion thus far:

I’d say the people have spoken,

what we want is a

Beaker browser that uses safe:… Simplicity that is going down the right path is most important here.

[rand_om]

You seem heavily invested
just doesnt really help the discussion, does it?

[whiteoutmashups]

what? …,.,…,.,‘’

[cretz]

Whew, lots of bikeshedding here and I don’t really have time to read it. I will just say this: use safe://. You’ll make normal URL parsers/formatters happy and will use URL schemes as the RFC intended. This is why several other protocols (which is what this is) use their own scheme (e.g. ftp, news, etc). Don’t use .safenet which implies HTTP which this is not (though we might share the headers and what not).

From RFC 3986 Section 3:

When authority is not present, the path cannot begin with two slash characters (“//”). These restrictions result in five different ABNF rules for a path (Section 3.3), only one of which will match any given URI reference.

Y’all can read the rest, but basically since we have an authority (i.e. which top-level domain to go to obtain the data in the path), we should use the slashes. Basically in URL parlance, safe://foo/bar means foo is the authority and /bar is the path whereas safe:foo/bar means foo/bar is the path.

This isn’t about coming up with something new. Also, the loss of interoperability with URL formats is hardly worth it. That’s all I really have to add on it…don’t want to over-conversate about it.

[Melvin]

@whiteoutmashups

I’d say the people have spoken

Some have spoken but I’ll stop here, have said my part.

[betterthantrav]

@rand_om

thats just because noone has thought of .safe yet! on to the next poll!

@betterthantrav

It does not mater what you put after the .

There needs to be a clear distinction between HTTP and SAFE

…

[happybeing]

We see it differently perhaps because we’re looking at users differently.

To help explain my reasoning, let’s segment users into different groups such as early adopters / tech savvy versus majority who need stuff that just works. Obvs a vast simplification, so not accurate or definitive, but useful for illustration.

First group, no problem.

Second group will have certain characteristics that change the balance. For them (the large majority I suggest), having a separate launcher and learning how it works together with SAFE Apps (browser and other stuff) is I think what we need to consider: versus having one app which is called “SAFE Network”, and operates as both browser and SAFE App Launcher (in the way we originally envisaged SAFE Launcher - hence the name).

For most people (ie the ones who need something that is very simple and just works) the adoption process reduces to:

• download / install and run SAFE Network

Using SAFE Network becomes

• start SAFE Network
• browse SAFE Websites instantly (no account needed)

Storing data requires a one-off account creation process, which once done can offer login whenever the user starts SAFE Network, while saying it is not needed just to browse.

This is a very slick and easy process for both getting on SAFE Network the first time, and each time the user wants to use it. They only have to know about one thing, and it does what it is called, until the point at which they are ready to learn how to do the next thing.

This is one of the least well understood but most crucial things about building a user base. It is also very hard to engineer, but for mass adoption software (or almost anything) needs to be trivially easy for most people to begin using, and only gradually ask more of the user as they become familiar with it and want to move onto doing more. In this context trivially easy for most people means sufficiently within their competence to be trivially easy to understand, and minimal time and effort to achieve.

So for example: getting on to browse SAFE website content should be install and run one thing, storing data is an optional action the user can discover or seek out through the user interface, and when they do, they are prompted to create an account. Once they have done this, and are logged in, further command options become available (such as for messaging, sharing data, creating a web service etc.). Prior to that point those options are also offered, but when activated prompt the user to login or create an account.

Step by step we can lead almost every user to the maximum of their competence at the time, and if we get it right, the software will take them beyond this by teaching them (or rather helping them discover and learn) how to increase their competence and do something they never realised the wanted to do or could achieve.

Creating software that does this takes careful thought, and is hard for various reasons. One is that we naturally assume knowledge and skills of users that they won’t have. Once I know something without thinking about it, it becomes very hard for me to place myself in the shoes of the majority of users, but is readily apparent when I try to show the average person something that to me is trivially easy.

If we want SAFE Network to be adopted by the masses, I think this is what we will have to achieve. Not necessarily on day one, but the sooner the better, so let’s give it a go!

[Traktion]

This is the clincher for me - we don’t want to spend years trying to bash a round peg through a square hole, just because we have a disdain for square pegs.

We need to be compatible with as many libraries and tools as possible. This will allow us to reach a larger audience with less effort/resource. Respectfully, maidsafe are not a Google.

[davidpbrown]

Can browsers that do understand safe:// not just transpose safe:// where it sees .safenet?

Users will only see the form their browser understands.

Default could be considered a compensator as .safenet and then SAFE enabled browers could suggest safe:// or safe:

That would allow for an easy route to supporting users relative to their type of environment… if they disable their add-on they see .safenet and if they enable it they see safe:

I put this type of question in the same box as logo … it’s not really important… the access to content matters so much more. It’s a means to an end, though I do understand OCD urls pawners concern with knowing what their prettified url will appear like - does it matter?

[betterthantrav]

@Traktion

This is the clincher for me - we don’t want to spend years trying to bash a round peg through a square hole, just because we have a disdain for square pegs.

We need to be compatible with as many libraries and tools as possible. This will allow us to reach a larger audience with less effort/resource. Respectfully, maidsafe are not a Google.

This is why we should only use round holes “SAFE:” not round “SAFE:” and square “.safenet” holes.

[anon20713104]

One possible way to solve the problem within Chrome temporarily, until custom protocols are available, would be:

Setup a public gateway which delivers the content of public-ids.

For example:
https://safenetwork.org/safe/SERVICENAME.PUBLICID

A Chrome-Extension could then evaluate https://safenetwork.org/safe/ and retrieve the content from the local Safe-Node. Also public content could be available without installing anything.

Custom Browser and FF-Extensions could also parse domain/path of the public gateway and could additionally implement the safe:// protocol.

Thats the way IPFS is doing it (as i get it) and maybe the easiest way for new users to get into the safenetwork.

[davidpbrown]

Perhaps the answer to this also follows from the way that SAFE is likely to be used.

In the case that SAFE Network will contribute to mixed content, then surely forcing safe: or safe:// makes no sense.

If clearweb devs are going to address content on safenet, they will prefer consistency with http:// and therefore we should prefer allowing .safenet in all cases. Again, that does not prohibit a SAFE enabled browser from doing whatever the user prefers for showing as safe:

If you force safe: or safe://, how will mixed content be practical in a way that allows Everyone? For as much as we care about where the content sits, perhaps many users will not… and the difference in presentation will be confusing, if not rejected.

Following the example set by Tor will not be contested.

[betterthantrav]

@davidpbrown

If you force safe: or safe://, how will mixed content be practical in a way that allows Everyone? For as much as we care about where the content sits, perhaps many users will not… and the difference in presentation will be confusing, if not rejected.

You are assuming that it is a good idea to promote mixed content.

Edit: an analogy would be saying back in the 90’s that we cant build it that way, because AOL does not support it and we want to support as many users as possible, so we should do it the way AOL does it.

[betterthantrav]

If HTTP is the internet super highway, then SAFE is the internet super flyway. Because, where we are going we don’t need any roads.

[davidpbrown]

@betterthantrav

You are assuming that it is a good idea to promote mixed content.

On the contrary; you are assuming it is not.

Default should be the most open option, otherwise you are making an assumption.

Why limit what SAFE can be?..