Do we need // in safe url?

As stated earlier in the thread you can already use either SAFE: or SAFE://

So I’m not really sure why this discussion is continuing - are people requesting to take an option away from the users?

1 Like

My point is that they’re not interchangeable. Let me demonstrate this by output given by Node.js parsing (I left out the identical property values):

{ //new URL('safe://example.org')
  href: 'safe://example.org',
  host: 'example.org',
  hostname: 'example.org',
  pathname: '',
}
{ // new URL('safe:example.org')
  href: 'safe:example.org',
  host: '',
  hostname: '',
  pathname: 'example.org',
}

With // the example.org is interpreted as the host, without it it’s a path.

4 Likes

I think this also reinforces the slash vs double slash - that code above would likely break if changed to a single slash, just like loads of other code would.

1 Like

Thanks for the clarification. I’m still not fully understanding though.

If I type in http:google.com … it still goes to google.com as the host - the browser seems to add-on the // in the url automatically.

Should I assume this isn’t the case with safe: ? [edit: I guess it isn’t as you used nodejs to get that output?] … Or are you specifically wanting a separate functionality between safe: and safe://

I think what browsers do and what browser do not do should be of little importance to this discussion. Browsers want users to have a good and simple user experience and apparently helps the user by inserting the slashes. My perspective on this discussion is mostly technical, not about end-user experience or display mechanisms.

3 Likes

I think we can take advantage of this, and from the output shown by @bzee , it seems it can even work with standard URL parsers. As you probably realised with the introduction of XOR URLs, plus the NRS we can operate with any content using just a safe:// URL, but we also had thoughts about being able to access the account’s ‘root’ Container (the Container which will hold links to what are called “default containers” in Alpha2) with a URL. So if an account has a link named ‘music’ from the Root Container, the owner of the account could access it with safe:music, it could be even linked from any content and when a user is accessing that link from anywhere it will be resolved to his/her own Root Container in his/her account (he/she would need to be logged in). Thus, also applications like JAMS can use this type of URLs (called RootContainer URLs…?) to reference to playlists stored by the user in his/her account, as well as any other data that is needed by any music app.

6 Likes

To access files in the root container from the safe browser I would recommend changing the protocol designation instead to a uri like this -

home://documents/cure-for-cancer.odt

This much more clear, than mixing it with a safe:documents like designation. KISS.

But they are effectivelly the same protocol safe:, why would you change the protocol in the URL?

1 Like

Less confusion. It’s more direct /clear and less archaic. You may see it as a protocol designation, but a laypersons view is that of location. The “safe:” is implicitly understood as being out in the wild on the public global safe computer. A “home:” designation is a more personal/private location.

The “home://documents/” path could also be intuitively understood to be a shortcut to “safe://bochaco/documents” or something similar.

I’m not sure I understand you post exactly, but I hope we can avoid fixed (default) names that cannot be changed. I dislike “special folders” like “Documents”, “Music”, “Videos” on my desktop. I’d like to be able to decide what those are called myself, e.g. “Text”, “Sound”, “Movies” etc.

1 Like

“Chickens”, “Moose” … :wink:

2 Likes

Yes, in Alpha2 we had default containers which names were fixed and hard-coded. We will be moving to an RDF representation for the Root Container, therefore apps will read/write that container using same vocab and using the names they choose for these links to music/documents/etc., of course this then becomes part of what is expected from RDF to cope with, i.e. music apps would use the same name and vocabs to refer to the data they store/manage, as well as document management apps, and so on.

I think this is why I disagree with your proposal, apart from me disliking the idea of having more than one protocol which I believe adds more confusion per se, e g. “so why is that url you shared not safe: but home: ? You told me was on SAFE?” …“ahh yeah it’s still on SAFE, trust me!”

I think that idea of home being safer and more private than out on a network is really part of the past, without mentioning how archaic it will become when SAFE is massively used, how many people store personal data on their mobile phones?
Once SAFE is out, would you think your PC, tablet, phone, closet is safer and more private for personal data? I want my private and personal data on safe not at home, just like I don’t want my money at home but on a safe place.

5 Likes

I definitely see your point and agree with your disagreement to what I posted above. The “home://” thing was the first thing that came to mind when reading your post because the use of “safe:anything” is ugly and archaic. I don’t necessarily like “home://” either but tried to sell it as an alternative. I do like how you’ve kept the “safe://” the same for xor-urls and nrs addresses. Regardless of my previous post, I do like and agree with the idea of keeping a single “safe://” for every type of network access. If you want to have shortcuts to special account folders, something else than “safe:documents” is much more preferable. Perhaps “safe://@documents”? Convince me I’m wrong. Mostly playing devil’s advocate here.

1 Like

I’m not convinced I can convince you :rofl: and I actually prefer others to convince you and me of the best one :smile:
But I can comment on that other too, having a character to imply some special meaning/treatment is really ugly IMHO, you step into the field of validating characters for NRS names/subnames.

2 Likes

Yes, I figured you would say that. It would mean some NRS names are reserved, which some are for/against. For the moment I like the idea of reserving ALL single words, but that is another topic. Maybe this banter will get the creative juices flowing in some other folks.

3 Likes

Maybe a special character isn’t so bad. We have it in Linux after all. What about sticking with the familiar?
safe:~
To access documents container you could do something like:
safe:~/documents

5 Likes

Nice. Wish I had suggested that one. You could also work this in to path navigation from the command line on the safe_cli.

3 Likes

I use Linux and I’m familiar with it. Not many other people I know are. It’s also a pain to find on many keyboards.

I agree with this @JoeSmithJr. ~/ is really basic and trivial for us here, but that is like asking a pilot about anything in the commercial flight routines. He’d answer in sleep, when intoxicated by CO2 or high G-forces. No-one else would.

  1. I wouldn’t say that Linux is necessarily a wonder of great design. It has so strange and iffy naming and structure, IMO…
  2. The main audience of this network is not Linux-aware people, in fact they are probably not very techy at all, since that is a minority of world’s population, and I’d say target audience is the world’s population.
  3. Why not just be simple? What would we call - in simple language, no special signs or hieroglyphs (!#%&(=@£$€$[}) - that place where everything starts, that what holds everything else? Technically we’re calling it root container (so, could give safe:root). But are there more intuitive notations? I mean this root thing, what’s that, a carrot, (a clarinet? :wink: @JimCollinson)
5 Likes

I guess you mean safe:root rather than safe://root ?

3 Likes