Should we drop the double slash in safe urls?

Features
1
2 Likes
2

No. But let one slash also be used if desired.

ā€œA pathname consisting of a single slash shall resolve to the root directory of the process. A null pathname shall not be successfully resolved. A pathname that begins with two successive slashes may be interpreted in an implementation-defined manner, although more than two leading slashes shall be treated as a single slash.ā€

https://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap04.html#tag_04_11

So

safe:/mav

Is the same as

safe://mav

and so is

safe:///mav

3

I am not talking about the pathname portion of the url. I am talking about the separator between protocol and host.

We can debate if these terms are directly comparable with nrs urls, but looking at rfc0053 I am talking about the leading part of <safe-url> not the <path-query-fragment> part (the latter being equivalent to pathname in http urls).

See rfc2616 section 3.2.2 for more details (they call pathname abs_path).

To repurpose the example you give to illustrate where the root slashes of the pathname would be

safe:mav/

is the same as

safe:mav//

is the same as

safe:mav///

but I am questioning whether we should have

safe:mav vs safe://mav

Related, bitcoin does not use // to separate protocol from address:

4

This is a good question cause we have the opportunity and why not? I would say most likely why not would be most are use to the way it is and will expect the same. Though increasingly people are more used to using the url address bar as a search field/quick action to a site. I start typing in amaz and it automatically puts in amazon.com, at no point was https:// ever typed. But if one was expected to type out the url I would assume they would follow convention.

2 Likes
5

For safe it works well to think of it in terms of ssh rather than http. The ā€˜safe:ā€™ in.

safe://some/remote/path

Is an indicator about which server you are accessing the files on. In our case the ā€˜serverā€™ is the Safe Network itself.

Potentially one could change to some other or alternative safe network, maybe a local one. Using the same safe cli you could access some files there by:

safe4me://some/other/Safe-like-Network/path

Probably not the answer you wanted. But itā€™s a very logical and self consistent representation that views the entire network as a virtual server you can interact with just like you would ssh a present day server.

This might be an indication of a good way to brand the safe cli as a Safe Secure Shell, ie. SSSH.

6

I donā€™t see it that way. The spec on url doesnā€™t frame it that way either.

safe: is the protocol, ie what ā€˜languageā€™ is being sent to and fro the wire between machines.

Itā€™s not a hierarchy or a location. Itā€™s the protocol.

I can see where youā€™re coming from, but I think the semantics of ā€˜protocol plus colonā€™ is exactly that, communicating what the protocol is. Claiming it as a location or whatever is not helpful.

safe4me:// would still be speaking the safe: protocol. So use safe: (or safe://).

Itā€™s not speaking http protocol or ssh protocol or bitcoin protocol.

http has a headstart here because google.com (without the protocol) can be assumed to be http protocol because of the .com being ubiquitous to that specific protocol. But safe:mav cannot be simplified since mav has no implication of which protocol to use to resolve the name, eg safe or ethereum or namecoin.

The debate is whether safe:<nrs-name> should be used instead of safe://<nrs-name>. Is the : enough of a separator or should we (for familiarity or whatever) use :// as the separator.

The debate is not about what each part around that separator means. That is well established across many implementations, many protocols, much history. Iā€™m open to being convinced otherwise but so far Iā€™m very much not convinced.

2 Likes
7

Yes correct from my understanding

Did you mean safe4me: or safe: ?

I would like to see the need for slashes to be removed. But with the history of the web, maybe we need to recognise still safe:// as well

8

Right now both options work in the safe browser

8 Likes
9

I did mean safe4me. I was using the example from the post above.

1 Like
10

If you are having the protocol, then leave as a colon double slash.
Double slash is useful for accessibility makes reading a lot easier.

The option would be to remove safe:// all together but that might not be ideal for the embedding of ā€œsafeā€ and awareness that the user is using a safe browser and not some random unsafe browser that has removed the protocolā€¦ which I wonder some were tending to a few months back.

Firefox I notice has the domain clear and the protocol and suffix detail in a lighter shade of grey. So, that kind of works well for making the domain very apparent.

Also, if the issue of NRS becomes that there is some other unique detail added to the domain, then that can be set among the protocol.

Merging the protocol and domain will not make it easier to understand or read.

11

I think breaking with the convention will cause a world of pain for developers and probably users because so much existing software, developer and user expectations are now formed around the existing standard.

For example, it would make hundreds of JavaScript libraries unusable (probably thousands) creating a significant additional cost for development, introducing bugs and reducing the utility because of the reduction in delivery of apps. Instead developers will have to convert safe URLs to and from double slash, and in some cases will have to rewrite libraries in order to get functionality which copes with the non standard format.

And it will persist for some time because I expect developers will remain reliant on libraries developed for the clearweb for the foreseeable future.

TL;DR: a really bad idea IMO!

7 Likes
12

Would it though? Iā€™d honestly challenge this assumption.

For example using built-in javascript

u = new URL("https:safenetforum.org/t/should-we-drop-the-double-slash-in-safe-urls/32652")

Works as expected.

Copy https:safenetforum.org/t/should-we-drop-the-double-slash-in-safe-urls/32652 into the browser address bar and it works.

https:safenetforum.org/t/should-we-drop-the-double-slash-in-safe-urls/32652
does not automatically turn into a link in discourse.

2 out of 3 on my basic test workedā€¦ would be interesting to have more data.

The spec says without double slash is invalid for http urls but valid for non-http urls.

url-parsing Ā· GitHub Topics Ā· GitHub :grimacing:

3 Likes
13

Agree Iā€™m making an assumption here, but I am sure lots of code will exist out there that looks explicitly for the double slash. Iā€™ve certainly seen it and written code like myself :blush: because it can be relied upon. I mentioned JavaScript, but of course this will apply to all languages, itā€™s just Iā€™m most familiar with the JS libraries and code that Iā€™ve been learning for the past four ish years.

This is true, but! :wink:

  • weā€™re talking about a use that is directly equivalent to http in terms of websites, so developers will both assume, and find it much easier to get going with Safe if the protocol has fewer differences than more. For example, keeping things similar probably made it much easier for me to demonstrate Solid apps on Safe. I think every difference we introduce will have a negative impact on the adoption of Safe by developers, and on their productivity, unless thereā€™s a direct and immediate compensating benefit to the change. I donā€™t see that in this instance.
  • not many developers learn how to do stuff from the specs. They are hard to understand, and most prefer to learn by looking at existing code, blog posts etc, and of course StackExchange! So they tend to learn conventions first and specs if they really, really have to. The W3C specs are particularly gruesome IME. I have been reading them since the early nineties all through the development of HTML/CSS etc and I still struggle with them. Having said that, theyā€™ve improved things a bit by providing primers for some specs.

url-parsing Ā· GitHub Topics Ā· GitHub

:rofl:

4 Likes
14

Also about parsing beyond internetā€¦ protocol:// is a clear indication of something internet domain like. Simple something: could be alsorts of other contexts. Software highlighting urls is just one example that might fall over.

Change for changeā€™s sake, is not worth thinking aboutā€¦ unclear any advantage.

2 Likes
15

How often do you use ssh?

16

Please, please keep this the default:
safe://something

I get the double slash is not needed, but we should follow http://, ftp://, ssh:// notation. I dont want safenetwork to be unique just because it can be unique.
Some principles of the network will be hard for peple to understand and we cannot do much about it, but other things like this notation, we can make easy to understand just by making it same as things people already know. So please, dont try to reinvent a wheel.

5 Likes
17

Literally every day like this:

$ ssh me@example.com

So for me the double slash is not part of ssh protocol, but I guess that must just be me.

It seems opinion is donā€™t change from double slash. I thought since the guy who invented the scheme thought the slashes were a mistake then we had a chance to correct this perceived mistake, but if people dislike the change then it doesnā€™t bother me. Thought it was worth considering.

Isnā€™t it also directly equivalent to mailto: urls for emailing? And bitcoin: urls for sending payments? Iā€™m not trying to say ā€œletā€™s not use slashesā€, just trying to put all the cases forward for why we might drop it. I think those cases are strong, but in the end what matters is the user experience so Iā€™m happy to forgo technicalities for the sake of that interest. But letā€™s not follow tradition without really exploring the other side properly.

Eyeballing List of URI schemes - Wikipedia it seems pretty even, and Ctrl^F shows 112 results both for :// and :< (only approx since some are duplicates and the formats vary).

Iā€™m not really fussed either way, the question was a genuine question not a leading one. Been good to hear what people think about it.

1 Like
18

Those are typically hidden for machine use in context. The double slash matters for human readability.

1 Like
19

@mav I agree that there are cases where double slash is omitted, my point is about http and the convention rather than whether the spec allowes it. BTW Tim has also said that, well weā€™re stuck with it now, presumably because changing it on the old web would break a lot of stuff. But TBH, if browsers allowed it, it would get fixed quite quickly so I might be wrong about his reasoning. Maybe itā€™s because he has bigger fish to fry, and it isnā€™t really a problem.

1 Like
20

I agree but suspect a troublesome issue might be IOT and all those devices out there with old un-upgradable code.

1 Like