[RFC] Public Name System: Resolution and RDF

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).

2 Likes

This is so damn genius. Great work @joshuef

1 Like

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) :slight_smile:

3 Likes

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

4 Likes

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 :slight_smile:

1 Like

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 :grimacing: I’ll be back once I go over this a few more times.

1 Like

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#me
  • safe://mypub1#me
  • safe://webid.mypub1/folder1/card#me
  • safe://webid.mypub1/folder1/card#mewhendrunk
  • even safe://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 :wink:

2 Likes

Maybe the xor addressing could use safexor:// instead of safe:// to avoid such ambiguity?

3 Likes

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”.

2 Likes

Now I see the dirty part. But you say ‘pee en es’, it is not like P(eter) Ness :smile:
Safe Naming System seems a good alternative to me. Open Naming System is also an option.

2 Likes

In the Rfc I see the two following things that are probably incorrect:

  1. I think the ‘:’ has to be followed with a link, or should it be replaced with a ‘.’?
  • Data is presented in a json, as RDF , as described over here:
  • I’m using MutableData ( MD ) and ImmutableData ( ID ) as shorthands.
  1. type: ’ @id entires…', should probably be ‘@id entries…’

And I’m not sure what the following means:

The RDF document should also contain a default graph ( : is intentionally chosen as it is not a valid subdomain portion of a URI), which points to the desired resolution if no key is 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’?

4 Likes

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.

1 Like

Thanks for catching typos @draw.

Ah, this part is actually redundant now. Ups :expressionless: . @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 :+1:


edit: PR updated :+1:

2 Likes

There would be worse I’m sure. Public Mnemonic System would be worse for 1/2 the population. But considering this might end up the acronym “forever” it might be best to think of a better one now before this one becomes embedded in our minds arrrrgggggghhhh

How about PNSYS

Or Better Public Name Resolution PNR
Or Public Name Resolution System PNRS

3 Likes

You can. But just to clarify, a subName is similar to a subdomain, and so would be before the publicName.

safe://BigBalls.AC/DC/DirtyDeedsDoneDirtCheap/

It’s that form that you had originally. What I was wanting to suggest with the use of paths (in a File Map), was just that you could achieve a more readable URL with that setup. (I didn’t mean to imply that those paths were subNames.)

So you have both options available to you. Using subNames you can get the safe://someName.Before.ThePublicName setup. And pointing your ThePublicName, or indeed the subName it resolves to (here: someName) to a File Map, you can then use paths to expand the URL:

safe://someName.Before.ThePublicName</ThisPart/IsNowAPath>

Does that make more sense? (I’m drinking my coffee now, but not sure if it’s kicked in yet :stuck_out_tongue: ) If not let’s keep it going as this is the kind of Qs we want to help make the RFC as clear as possible :+1:

3 Likes

Yes I think it does @joshuef thank you for the distinction between the two approaches!

There are a couple things I’m still unclear on as I try to wrap my head around this but I’ll keep mulling it over till I can ask a more coherent question. :yum:

4 Likes

safe://jams.demo.JamsUsersPublicName/Albums/GreatestHits/BestSongEver

safe://jams.demo.JamsUsersPublicName/Albums/GreatestHits/SecondBestSongEver

Is somewhat what I had in mind when a user uploads their music (to give an example of a full path) but I am also assuming they won’t be able to use the jams subName or .demo service since that is owned by the app owner and we don’t plan on storing on behalf of the user so that they own/retain control of their data.

Am I wrong here? Is this possible?

Kind of curious if you could have paths with the same names just published under a different PublicName :thinking:

Still haven’t had time to dig in again just yet (with a much better understanding after your examples @joshuef ) but this popped in my head on my way over here. I appreciate any help, not trying to make you guys do all the heavy lifting but I’m sure others reading the thread could benefit too. :wink::wink: haha

Right. Any Public Name can point to any MD. Normally that would be controlled by the owner of this Public Name, this can point to Sub Domains and onwards. So it could depend on the app…

The app could simply use a Public Name owned by the user and map Sub Names etc,.

The app could include a user’s Resolvable Map as a target for a Sub Name in its own Public Name (though the user wouldn’t have control over if that stayed there, so I would consider that sub optimal.

(It could conceivably be both, but I still don’t know why we’d want the latter).

Thats’s entirely possible. What you’re saying with a Public Name is that it points to some data. This could be a Resolvable Map of Sub Names (or just a File Map), which can point to a File Map.

That File Map is a simulation of paths of a filesystem. And is completely independent of all other File Maps. So any number of users can have the same paths, pointing to different data (or indeed the same datas).

2 Likes

It is possible, but I’m not sure if you are describing the possible way or the not possible way. It depends who owns JamsUsersPublicName.

If the app owner owns that, they own the subNames too. But JamsUsersPublicName public name reads to me like the user owns it, in which case they own the subNames too.

The latter means that there is a copy of JAMS app at the user owned JamsUsersPublicName.

I’m not sure if that’s what you have in mind, but it is possible, easy to do, and won’t use many PUTs because they won’t need to pay to upload the JAMS source files, they will just reuse the XOR addresses of the source files.

This is how I envisaged users can own their own SAFE Plume blog, I just didn’t get around to implementing if fully yet. One day!

So to summarise, a user can effectively run a copy of JAMS on their own publicName, and would then own the jams and demo subNames on that publicName, and your app could set this up for them with a ‘create my JAMS’ command which registers their chosen publicName, and makes an instance of JAMS there.

That may not be what you have in mind. An alternative is for the app to be at one location owned by you as developer, but the user’s music stored and shared by the user at a location which they own. I’m not sure if this is what you have in mind, but it might be sensible, I’m not sure. I’d have to think more about that.

1 Like

I have looked at the RFC since @happybeing pointed me to the pull request. Didn’t yet look at it critically though I believe it’s generally a great RFC. A few remarks:



2.2 Many SubName s

safe://<subName>.<subName>.<subName>.<subName>.<publicName>

  • As above, resolving each additional substring, up to a defined maximum of redirects (implemented in the resolver.)

Reading chapter 2, it’s not entirely clear to me how many subNames are supposed to be resolved. I assume the middle subName is also a Resolvable Map, is that right?




Once the final data has been resolved in a browser, if a Files Map type of Resolvable Map has been located, then the trailing url path would be resolved, too.

In the above sentence, what does ‘type of’ mean in this context? I think I misunderstand this sentence. It describes the ‘final data’ being resolved, and then talks about “then the trailing url path would be resolved, too.”



@id entries must point to a XOR-URL for consistency (while pubNames may change, this data will not move location);

The above refers to @id entries, which I believe is specific to JSON-LD. I’d suggest to remove it or change it so it applies to RDF triples in general (@id is a subject (?)). Same applies to:

Providing different @type info or other details in the RDF can facilitate service discovery.



Is it possible to combine a Resolvable Map with a File Map? This so that looking up a public name directly allows fetching of files. Or does one really need a subname for that which refers to a File Map? What if one does not want a subname? How to point the default directly to a File Map?



The last part about the public name container confuses me (although I think I know what is meant). It says this:

The structure of a user’s _publicNames container (for managing their Public Names ) must be:

It then states ‘The Public Name Map’, but I can’t find a definition of this. Then it says:

  • A Public Name must point to a Resolvable Map RDF schema. With the target MD location XOR-URL as the value to the key.

This is where I get lost. What is the ‘key’ that is mentioned? What value?

Somehow initially I thought the above was explaining a new RDF structure for the public names container. I assume the public names container is not RDF, but a plain key-value MD. Where the key is the public name string and the value is the XOR-URL of a Resolvable Map.



Again about this snippet:

@id entries must point to a XOR-URL for consistency (while pubNames may change, this data will not move location);

I assume @id is the subject of a triple. A subject is the resource in question. Can I suggest that this subject might also be referred to by using the (default) Base URI? Let me illustrate what I mean in Turtle by taking the mypubname example from the RFC:

@prefix safe: <https://joshuef.sschema> .

<>                                        // relative to default base URI (or <.> (?))
    a               safe:ResolvableMap  ;
    safe:default    <#somewhere>        .

<#somewhere>                              // relative to default base URI
    a               safe:ResolvableItem ;
    safe:resolvesTo <safe://arandomxor> ;
    safe:targetType safe:FilesMap       .

(See RDF 1.1 Turtle for more information about IRI.)

I mention this because I would like the RFC to impose as few unnecessary limits as possible. I suggest using the relative IRIs a little more too in the examples.



As an aside: JSON-LD is harder to interpret than plain N-Triples or Turtle. I suggest using the Turtle format for illustrating and defining schemes and examples.

5 Likes