You are on the money, @Nigel.
You’d also be able to do the same with a path safe://AC/DC/DirtyDeedsDoneDirtCheap/RideOn. It’s all possible.
Main thing to watch our for with subsusubNames is redirects. Right now I’m proposing a limit of 10, which is an entirely arbitrary number just to keep load times reasonable (though what that actually means in practice we’ll have to see.
I was mulling this over. I totally don’t see a reason not to have one. And i wonder if the simplest approach is just for the directory graph to point to a blank node. That doesn’t require any major changes / additions, perhaps aside from noting it in the Resolvable Map schema that that is what that signifies…
Thoughts?
I’ve posted in the linked data gitter atm. Will drop it in the SOLID forum to see if anyone might want to opine, though it does feel a bit off topic over there (not sure if they have categories for such things on the forum. Will find out soon enough!
@joshuef I was thinking of asking somebody directly. I’ve done this in the past and now your faces are known you could do this, although they are now very busy with Inrupt so may just not have time.
On containers I don’t know the RDF implications, and how we’d translate this in storage implementation. I’m just thinking that the lack of this causes problems in the application side of things. Any app that provides its own UI for storing files may have to tackle this.
@bochaco yes, sorry again. It was of course the public names container! I don’t have an alternative in mind, nor time to figure one out. I’ve not spent time learning the ins and outs of ontologies and RDF handling, so you and Josh are way ahead of me there. Just trying to understand your process and review the proposal through discussion.
About URL resolution: Is it possible to have a Public Name that looks like a XOR-URL? If so, I understand that webFetch will try to resolve it as a XOR-URL first, and then try resolving as a Public Name after the XOR resolution fails, which seems like an inefficient use of GETs even if it is an edge case.
Hmmm, good Q @marcin!
There’s nothing stopping that at the moment, for sure.
It would be a pretty bad choice for a public name (a xor url exmaple: safe://a078516207e36aa2371e17750c93276446bdb4867c027035531b89430aa8d3ae2fa4dbb59 from the proposal post ).
One possible thing is to alert people to this when making a publicName (of given length/style or some such), but that’s not a real solution.
I’m not sure what we’d need to do to prevent it (nor if we should be, given how edgy / terrible that is for a public name… which if you’re doing that, why not just use the xor url?)
I also don’t think this necessarily needs to prevented, just trying to consider all the edge cases 
One interesting consequence of this is that if someone uses an existing XOR-URL as a Public Name, that Public Name will never be resolvable. I don’t know why anyone would want to do that though, and e.g. displaying an alert should be enough to dissuade them.
Yeh, i think that’s the main issue.
It might be worth noting that a client MUST show a warning or some such, so alternative clients should do that also. (Although, this RFC isn’t for management or creation of the _publicNames container… it does touch on it. I think we should probably RFC that out separately, and we can note any/all behaviours we want for that process).
Haha, glad you enjoy @Nigel
But just to clarify: this is a the culmination of lot of work from across the @maidsafe team. This is just bringing it all together and writing it down at last (which there were also many hands in :P)
Of course. I apologize because everyone who contributed deserves credit. @maidsafe amazes me on almost a daily basis. Really proud of you all.
Trying to straighten how WebID, XOR URL, PNS, all work together to achieve safe://AC/DC/DirtyDeedsDoneDirtCheap/RideOn
• WebID needs an associated PublicName in its RDF
• When that WebID saves a song, the app can name the subDomains appropriately in the correct order
• XOR URL is there but abstracted from the user because it was published under a PublicName? But also has its own cool features like under certain circumstances being able to be rendered in the browser.
Now my other question. If I have safe://AC/DC/DirtyDeedsDoneDirtCheap/RideOn
and there are not only multiple albums for an artist but also multiple songs per album (let’s stick with songs in an album for this) can I post multiple subDomains (songs) under safe://AC/DC/DirtyDeedsDoneDirtCheap? Which I believe DirtyDeedsDoneDirtCheap is actually already a subDomain.
Like this.
safe://AC/DC/DirtyDeedsDoneDirtCheap/BigBalls
safe://AC/DC/DirtyDeedsDoneDirtCheap/There’sGonnaBeSomeRockin’
safe://AC/DC/DirtyDeedsDoneDirtCheap/RideOn
etc etc? @joshuef
There is not really a reason to restrict it that way in SAFE (at least as per these proposals), you should be able to have a WebID published at any type of URL, i.e. pubName-URL or XOR-URL, you could have safe://mywebid.nigel#me, or maybe at safe://hyfktced1wsgxzyxuiwrzrukgcagpxzowfy35zpo6hdd5jyhqxij84ri8uo#me. The WebID URL is just to resolve the location of where the WebID Profile document is stored and fetch it.
No, the XOR-URL is not stored as a pubName. The function we expose to resolve the pubName-URLs (webFetch) will also be able to resolve the XOR-URLs. This will be explained in the XOR-URL RFC (it’s also briefly mentioned in the other post where we are discussing about it).
When you invoke the resolver function, it’ll first try to decode it as a XOR-URL, if that step fails (either because it couldn’t decode the URL or because there was not data at the decoded XOR name), it will do a fallback to assume it’s a pubName-URL and try to find the pubName MD with the sha3 hash function, just like it works today for pubName-URLs.
I’ll leave Josh to answer the other questions 
Okay, I have a slight misunderstanding then. I had come to that assumption from your XOR URL demo vid but I’ll go back and watch it again to brush up. Trying to follow along the best that I can 
I’ll be back once I go over this a few more times.
No worries @Nigel, I like the ideas and the way you are thinking about all this, it’s the same type of things we were playing around with in our heads, please keep digging
You just need to think of the resolver to be simply a function which allows us to standardises both types of URLs, and by decoding the URL it can try to find it either by looking at a XORname that it found encoded in the URL, or otherwise by getting the sha3 hash on the URL and look up for a Resolvable Map MD at that location.
As an aside comment, with the ResolvableMaps and FileMaps we should be able to handle all type of combinations for WebID URLs, e.g.
safe://webid.mypub1#mesafe://mypub1#mesafe://webid.mypub1/folder1/card#mesafe://webid.mypub1/folder1/card#mewhendrunksafe://webid.mypub1 (we can support this thanks to the http://xmlns.com/foaf/0.1/primaryTopic of the WebID I believe, otherwise don’t know why it’s needed in a WebID)…and the same combinations with XOR-URLs 
Maybe the xor addressing could use safexor:// instead of safe:// to avoid such ambiguity?
Nice work @joshuef.
I tend not to partake in dirty jokes, but to parrot nigel and hunter
pns
is a difficult acronym to deal with… Can I recommend “sns” for “Safe Name System” or “SAFE Name System”?
Other alternatives might be “sos” for “Safe Object System”, “sons” for “Safe Object Naming System”, or “ons” for “Object Name System”.
Now I see the dirty part. But you say ‘pee en es’, it is not like P(eter) Ness 
Safe Naming System seems a good alternative to me. Open Naming System is also an option.
In the Rfc I see the two following things that are probably incorrect:
- Data is presented in a json, as RDF , as described over here:
- I’m using MutableData ( MD ) and ImmutableData ( ID ) as shorthands.
@id entires…', should probably be ‘@id entries…’And I’m not sure what the following means:
The RDF document should also contain a
defaultgraph (:is intentionally chosen as it is not a valid subdomain portion of a URI), which points to the desired resolution if nokeyis provided. …
What is meant by the ‘:’-character? Should it be ‘:default’ instead of ‘default’ or something else?
And if this is the case, is ‘:default’ something completely intern to the Safe code? You can’t use it in a URI if I understand it correctly and in the RDF code I see ‘"default" : ...’ instead of ‘":default" : ...’.
I’m probably not familiar enough with all this.
And with FileMaps will (long term) the NFS containers still exist/keep using another kind of similar ‘scheme’?
Ah, nice suggestions @jlpell.
I’ll happily admit PNS is not the best acronym to be throwing around. We were trying to get something that was similar to DNS, but was not that to avoid confusion.
SNS has a good ring to it, and I can’t think of what it confuses.
Thanks for catching typos @draw.
Ah, this part is actually redundant now. Ups 
. @bochaco and I had a wee refactor early Thursday of the RFC and this was purged from the examples, but I missed it here. Sorry for the confusion there! Will update the RFC based on this/typos the now 
edit: PR updated