Do we need // in safe url?

We already do :+1:, safe:// will be added automagically for you if you dont type a protocol in.

Thus far we’ve had safe-auth: being used, and we may have some other URL based protocols for triggering certain functionality.

@folaht I think while there could be a protocol written for safe against whatever language, such an endeavour kind of goes against the idea of a protocol, which in the URL sense is to indicate how to treat the rest of the string (as a http or safe req etc). This has to be installed on a user’s system for their device to be able to understand it. So there’s no difference between safe: and whatever:if they both do the same thing… but that depends on a user’s system. Which is why I guess such things are normally standardised to one thing, so we can all share links and know we have appropriate software to handle them…

As to the main question in this thread: // do we need it. No. In fact I think most system can/will handle safe:josh and safe://josh exactly the same. safe: is considered the protocol by javascript URL parsers for example. So in a way it depends on what you prefer to write…

As to what should be displayed by default… well that’s a question that was gone over quite intensely (as far as I remember at least) back when the original browser community engagement thread was a go. safe:// was settled on.

But as I said, safe: or safe://… this is really just a question of what we want a browser to display by default in the URL bar, not what’s actually usable now (which is both).


It should actually be easier to explain. Just ‘browse some_website on safe’ will be sufficient. Moreover some_website doesn’t need www. or .com either, as these are relics from old DNS and are not needed by NRS.


I’m suggesting safe: and whatever: should check for different characters to validate URLs.
That’s a difference.

That’s cool! – I just realized I can do that with https: on my browser as well … all this time I’ve been typing the whole darn thing out … now watch, I’ll keep typing the whole thing out and only realizing after I’ve done it. Dam my crappy typing/mouse memory!


In html, is also an example when slashes are not used. Probably a bit old skool to have visible email addresses on public sites though! :joy:


As has been stated above and elsewhere. There’s currently not any hard limit on characters that you can use in the NRS scheme… So if you’re finding problems with this please make an issue. (And if you could try it via the CLI as well as any browser that would be rad).

(Though we may want limits on valid characters at some point, that’s a big convo that hasn’t thus far been resolved.)


Yep to me it’s always been “slash” and “backslash”.

1 Like

We need smart farts like @neo

1 Like

I disagree. Bad practice is something that goes against usability. Browsers learned to recognize if something was a search or a URL not because it’s easy to do (or can be done unambiguously in all cases) but because it enhanced user experience by a significant margin. It’s a widely appreciated, accepted, and even expected feature so removing it in the name of an abstract ideal is a bad idea simply bad design.

I’ve never run into that and, if a browser has an up-to-date list of all of these as it should, or at least checks against DNS first, it could never happen.

1 Like

It happens with typos and I hate the search happening because of that. A fake site due to typo would still come up so its not a protection feature, but a pain in the arse since I’m expecting the site and when it appears its the search and my info is leaked yet again. And this is with the search from address bar turned off

Do chrome-based browsers allow this behavior to be changed by the user? I believe firefox does. IMO, the solution here is to just allow the user to modify the browsers behaviour to their liking.


Well, having the address bar double as a search bar goes against my usability. People are different and have different preferences.

I agree.

It’s generally good to have things as configurable as possible. One could make the cat command behave like the find command to save a character, but IMHO the default should still be to keep those separate.


What find the latest cat video for laughs


I agree it should be a setting, with maybe the difference that including search should be the default, but I think my wish will be denied by the simple fact that the Safe network won’t have any search services in the beginning :roll_eyes:


That’s just the thing. “Search” is a service that can be provided by anybody - or not. Even Google has several different search functions. The address is an unambiguous link, i.e. part of the very structure of the network. They are very different beasts.

1 Like

I was fortunate enough to attend a talk given by Tim Berners Lee at the Science Museum on the occasion of the thirtieth anniversary of the invention of the World Wide Web.

When questioned about the // in a URL, he explained that at the time it was to fit in with an address protocol developed by NASA, but not used since.

I conclude that moving forward, we could drop the // in a web address.


Why fix what’s not broken? Languages, even minimal ones like a web address, are just a set of conventions that people agree upon regardless of their origin. Try to dig down to where the word “analyze” is coming from. Is it worth “fixing” it?

My position is to keep as much as possible to as close as possible to existing conventions. Any deviation from the familiar that isn’t directly related to the vision is a distraction from it.


I agree with @JoeSmithJr - no point changing something so minor, for little gain and many potential issues. It just isn’t worth it.

1 Like

In every reasonable OS (meaning not windows) the ‘//’ refers to the root directory of the filesystem. It is equivalent to ‘/’ (give ‘cd //’ a try in your favorite terminal). Keeping the ‘//’ is both familiar to users and technically correct. It is logically consistent when considering the safe network from the perspective that it is a global computer with a global filesystem.


I was meaning to respond to the safe: vs safe://.

Technically, safe: is not a URL. So, when dropping the //, you’d actually be dropping URL support. The // is part of the hierarchy and defines the ‘authority’. Both of these are URIs, but not URLs. This is stated in the RFC (the top one is the URL)[1]:

         \_/   \______________/\_________/ \_________/ \__/
          |           |            |            |        |
       scheme     authority       path        query   fragment
          |   _____________________|__
         / \ /                        \

When talking about standards I think it’s very important to be correct about the terms and usage. Especially with these long-standing standards that are fundamental to the web.

I couldn’t have said it better. Every deviation at this fundamental level will cause lots of consequences in implementations for years to come.