That’s right, edited now.
Edit: Actually, I wasn’t specifically meaning to use or not use //, it was only the ~/ I was referring to.
2 Likes
Okay, we may not need it, but… every damnd* protocol has it.
I really think we need to hold on to some familiarity.
Http://
Https://
Sftp://
Fish://
Safe:// ← keep this, as part of my “sales routine” is it is a new protocol. You’ve seen http:// you’ve seen the secure https://, well now there is safe:// which is https:// on steroids.
If you have to get rid of // please at least alow people to enter it. From a noo ie angle, I’m very dependent on using the above argument
.
- okay, not many protocols, but it’s the standard and we should make people feel comfortable.
5 Likes
I don’t think we are talking about removing it anymore, that was my understanding (and also proponent) on this thread, but perhaps about having something like safe:~// or safe:root// for the named containers owned by an account. It’ll be good to clarify what other were getting out of all this
EDIT: you may be right though as I’m not sure we can have all that together as per comment #42 above
3 Likes
I’m still thinking we should not confuse things without good reason, so for web-like URIs safe:// is still my preference.
Maybe for special SAFE functionality something different like safe:root although I’m not convinced yet. I see pros and cons. I still think the ‘//’ is a good marker - it screams URI in a way that dropping it does not, and lots of things will break or be harder to get working if we diverge unnecessarily.
So safe://~root or something else which retains the safe:// consistently for all URIs might be better. Something other than ‘~’ could be used if that’s too weird / hard to find on a keyboard.
7 Likes
Please no “~” character, I think it is one of the worst characters. “: / .” Characters seems like they always work no matter what keyboard or OS settings is default.
2 Likes
I’m not trying to push myself for safe:~ as I see some like you @tobbetj don’t like it, but I personally love the safe:~ one as a linux user, but again I’m not trying to be pushy and see if there is a consensus, I’m happy as long as we have a form of URL for the Root Container 
I just imagine myself with easily typing $ safe files sync ~/Pictures/ safe:~/pictures/
5 Likes
I can understand that if you use Linux alot than it seems natural. I have got that character to work on Ubuntu and similar before, but when I tried earlier today on Windows 10 I could not get that button to work. I tried every possible combination, as it is the third special character on the same button, for me, also not the corsair app or windows settings did help. But I’am on swedish layout which is part of the problem but that character causes me pain.
Safe:root seems more intuitive to me, but it probably don’t matter that much which of the alternative ends up being implemented.
Windows don’t care to let me choose the correct layout, just like the honey badger, windows don’t give a f*ck. 
Even if most, even I, will use Linux for SAFE as the default solution.
A few variants retaining the recognisable, parseable form of URI:
$ safe files sync ~/Pictures/ safe://~/pictures/
$ safe files sync ~/Pictures/ safe://$/pictures/
$ safe files sync ~/Pictures/ safe://-/pictures/
$ safe files sync ~/Pictures/ safe://./pictures/
$ safe files sync ~/Pictures/ safe:///pictures/
Why is it so many things after “//”, it confuses me alot and looks kind of odd to me when it becomes to much characters after “//” when I expect the address to begin. 
Is Safe:~//pictures/ possible. To me it feels not right that for example “/” is the first thing that you see after “//”, if pictures is the first folder of the container it feels strange if it looks like it is the second folder.
Of the alternatives
Looks most intuitive and coherent.
$ safe files sync safe://⌂/pictures/ ~/Pictures/
$ safe files sync safe://^/pictures/ ~/Pictures/
$ safe files sync ~/Pictures/ safe://√/pictures/
Currently there are 2 kinds of safe URLs:
- NRS maps
- XOR URLs
In both cases these URLs references globally addressable objects in the network.
If I understand correctly, this not the case of the objects we are talking about because they are internal to an account.
So, a distinct syntax must be found for them:
-
I like
~character because it indicates clearly this belongs to my own personal container. -
But another possibility could be to use a different scheme name, the same way there is
file://...to reference files in my local computer that is different fromhttp://...referencing global resources in the web. It could be something likesafe-account://...(just an example, I have no strong opinion on the scheme name itself).
2 Likes
Don’t know if > is allowed by the parsers, just some more random thoughts:
safe:>documents/
safe:~documents/ (as an alternative to safe:~/documents)
@tobbetj you make me wonder if this is a problem for Linux users using other keyboards or how do they really manage it
1 Like
The problem with a few URLs proposed here is that they’re not URLs because they don’t follow the IETF standards (disallowed symbols).
This solution actually follows standards. NRS could also include reserved names, like ’localhost’ in DNS. E.g. a URL of safe://account could be reserved to point to ones root container.
The reason I am pedantic about standards is because I think it should either be followed completely or ignored. Why follow part of the URL standard and end up with safe://~/pictures instead of creating a new one to be like @pictures.
Also, another option is to implement the more general URN standard: safe:pictures. These URNs only have meaning on one’s local machine, as far as I know. (I alluded to the difference between safe:// and safe: before.)
edit: I see now that safe:root was mentioned already, I apologize. But, it’s important to stress that this would completely follow standards and makes a lot of technical sense.
6 Likes
The problem is that it collides with account NRS map, contrary to localhost which doesn’t collide with a domain name because a different scheme name is used.
You’re misunderstanding. I propose reserving it to prevent a collision. localhost is not a scheme. It’s a reserved name, that’s why I compared it.
Yes, but I don’t like reserved names.
I agree, the scheme is file:// and this is what avoids the collision
That’s also why I personally don’t like anything after the //, unless we really really need to have something, if not just avoid the hassle of extra validations in URL resolvers. How do you reserve it?
3 Likes
That’s a valid reason. Just consider it part of the options one haves while still following IETF standards.
No, even with http:// there is no collision, because your machine will never try to resolve it externally. This has nothing to do with file://.
Same as localhost is likely reserved. Machines will never look it up on the DNS because it is mapped to 127.0.0.1. Though you have a point, an application might mess up and still try to resolve it, only to find out a scammer has the AD in his hands. This is not possible on DNS as long as the DNS root servers don’t resolve the localhost. TLD.
So, indeed, not a very good idea. This is why a URN really attracts me as it only haves local meaning. So no worry it will resolve to something you don’t own.
3 Likes
Absolutely beautiful!