[RFC] Public Name System: Resolution and RDF

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:


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


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

  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’?


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:


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


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


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:


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:


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:




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


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


  • 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 https://www.w3.org/TR/turtle/#sec-iri-references 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.


Each subName is its own Resolveable Map. You could potentially string them to infinity, which is why I suggest we put a timeout limit on that.

Originally, I was intending a Files Map to be a sub class of Resolvable Map (being all but the same, but for the context of its use (which can be important for the resolver).

With this I’m intending to mean, the last MD of Files Map type… and we then go on to resolve the path of the url, with what we’ve found there.

I’ll clarify this in the RFC :+1:


I find myself wondering the same. While we’ve set up the default construct to allow for now wanting a Sub Name… Do we require a Resolvable Map before a Files Map. I don’t think so. I can’t see a reason to need it… thoughts? (@bochaco?)

Yeh, we actually spoke briefly about this being its own RFC, which I think might be worth doing as it is not strictly anything to do with the resolution (beyond the sha3 hash of name pointing to our first Map. So I think that might be worth doing, to give that the space it needs to clarify such things (as I think it is confusing trying to shim it in here).

(Though in short: it would be RDF, so yes, talking about keys is somewhat confusing. Though to clarify in our current setup of using MD, a sub graph will actually map to a key, such that we can have safe://<yourPublicName> as a key in the MD (which would be the subject of the graph, and target @id in jsonld terms).

This should actually be changed to talk about resolvesTo, and is something I’ve missed after we did a refactor of the graphs last week :expressionless: (Though I agree on the use of base URI’s where it’s appropriate).

I honestly don’t find turtle any easier, and more often than not, more confusing. This comes down to personal preference IMO. (There are many w3c specs which choose JSON-LD over turtle in their examples).

But the representation becomes important when considering how it might map to our data structures (namely MD in this case, as that’s what we’re suggesting to use, and the mapping is important when considering performance on fetches/iterating over graphs etc).

I’m not really into adding in two formats for examples though, as it would make everything very long (given the limitations of github presentation… a tabbed setup for examples would be ideal).


Thanks for answering on all of my comments!

I found the documentation relevant to JSON-LD about Base URIs here by the way: https://json-ld.org/spec/latest/json-ld/#base-iri

Gotta love that specification!

I definitely agree on that; I prefer JSON-LD too. But, objectively I think Turtle is quicker to understand — it plainly describes the triples, without the complexity of the JSON syntax and JSON-LD specific keywords and constructs. However, RDF is complex per definition so that’s an argument in favor of JSON-LD.

That should not influence the RFC though. Per the other topic about storing RDF in MDs I would like the RFC to keep an open mind on the formats it chooses to describe. A ‘tabbed setup’ would indeed be perfect in this case.

I’ve been brainstorming a bit about this. It’s about the speed with which something can be looked up. Visiting a website by its public name with this RFC will require 3 (or 4) sequentially dependent fetches (GETs): first the public name Resolvable Map, then the Files Map, then the file itself which is a MD/ID. Combining both maps would eliminate one lookup (at least for the single public name case).

(In case we’re talking about an index.html file, then that file will contain references to other resources, e.g. a CSS file, which are sequentially dependent on the first file.)

Now, on the clearnet I’ve seen a few WebIDs and other RDF documents in the wild. What I often see is that a resource that’s being referred to is also briefly described:

<https://www.w3.org/People/Berners-Lee/card#i> a foaf:Person;
  foaf:givenName "Tim"@en;
  foaf:familyName "Berners-Lee"@en;
  rdfs:label "Tim Berners-Lee"@en.
:me foaf:knows <https://www.w3.org/People/Berners-Lee/card#i>.

(Taken from https://ruben.verborgh.org/profile.ttl)

In this case Ruben Verborgh states he knows Tim Berners-Lee, and describes certain properties of the resource. (@happybeing, perhaps there is a name or concept for this kind of ‘cache’. (I imagine it might result in some inconsistencies about resources.))

Anyway continuing the brainstorm, I imagine this might be leveraged to make it quicker to go from public name to an index.html with its CSS/JS dependencies. That could be done by describing the File Map briefly so a client could preload an important index file. That might make a Resolvable Map and a File Map somewhat combined. Perhaps even describing the dependencies of index.html so that a client can also preload the CSS so the page loads well immediately.


I agree with this in principle. Though when it gets to fetching/iterating as you’re considering later on, it is relevant. And so having the RFC written in that makes sense for clarity when discussing these concepts…

FilesMap and Resolveable Map are very similar. Their properties are the same (more or less), but the separation allows them to be indicative of what the resolver can expect (files vs sub names).

With which, if you point to a Files Map, and do so straight from a Public Name graph, it could well be noted (via targetType, eg) so if we allow it, a Public Name could point to:

  • A Resolvable Map (with default set, or subdomains, to allow for simple safe://<my public name>
  • A Files Map which points to files and has a default one to load ( such as index.html)

The only reason you cannot point directly to a file, with a Public Name is that it’s determined by the sha3 hash of the name string, which points to an MD which is created to manage this (so always at least 2 fetches are needed).

‘Caching’ via preloading some props can definitely be handy (to know if it’s interesting for this app or that). Though I think the the index.html context, you either pull this and then get those files… Or you’d have to describe some file dependencies to get any discernible difference.

ie, your Files Map graph for index.html could potentially be:

	   "@context": {
		   "@vocab": "https://raw.githubusercontent.com/joshuef/sschema/master/src/"
	   "@type": "FileItem",
	   "@id": "safe://thisxorurl/#/index.html",
       "targetType": 'html',
       "target": "<XOR-URL location>",
       "size": '22',
       "creationDate": '<UTC>',
       "updateDate": '<UTC>',
       "dependsUpon" : ["/style.css"] // <--- indicating other resources needed
1 Like

The only problem I see is that you need to know how to resolve both the subNames and the path, so if we have only one type of resolvable struct (i.e. ResolvableMAp or FilesMap) we then need to define how you’d resolve a path in the case there is a subName, and how you’d do it in the case there is no subName/s. In theory you can have all graphs in the same struct, so yo perhaps don’t need to create a separate FilesMap if you know you want a set of files to be mapped from a publicName, but we should also allow to link to graphs which are in a separate location since you may be uploading a directory to the network without publishing it, but eventually you may want to publish it with a publicName so you will need a way to link it to from the publicName ResolvableMap.

So I think it all comes down to how complex we want the resolver’s logic to be so it can cover all these scenarios, like allowing a ResolvableMap to be both a ResolvableMap and a FilesMap, plus having FilesMap on their own for files organised as directories randomly on the network (e.g. queryable thru an NFS emulation layer and its XOR location).


Hmmmm, yeh things can start to get complex if you point to a Files Map direct, w a default…


	   "@context": {
		   "@vocab": "https://raw.githubusercontent.com/joshuef/sschema/master/src/"
		"@type": "FilesMap",
		"@id": "safe://thisxorurl",
        "default" : "#/surprise.html"
	   "@context": {
		   "@vocab": "https://raw.githubusercontent.com/joshuef/sschema/master/src/"
	   "@type": "FileItem",
	   "@id": "safe://thisxorurl/#/surprise.html",
       "targetType": 'html',
       "target": "<XOR-URL location>",
       "size": '22',
       "creationDate": '<UTC>',
       "updateDate": '<UTC>'
	   "@context": {
		   "@vocab": "https://raw.githubusercontent.com/joshuef/sschema/master/src/"
	   "@type": "FileItem",
	   "@id": "safe://thisxorurl/#/some/deep/path/style.css",
       "targetType": 'test/javascript',
       "target": "<XOR-URL location>",
       "size": '22',
       "creationDate": '<UTC>',
       "updateDate": '<UTC>'

If default is set to surprise.html, we get that page rendered. Even though random doesn’t exist, a default does.

But with this setup, you get problems when trying to retrieve a resource on a path… Say surpise.html links to style.css… you’re coming back to this Files Map which resolves a default which is the ID surprise file.

So then would the resolver fall back to the FileMap to attempt to retrieve the requested style.css file…?

I think, you’re right @bochacho, that there’s not so much need to think about using FilesMap direct etc, as if we’re looking at saving some fetches… Because you can store more graph data in a given MD/ID… So there’s no real need to be going down that road / introducing this complexity.

That seems like the sane thing. And perhaps worth clarifying that such a thing is possible. :+1:

So that’s a few updates to get into the RFC now :+1:

Last thing that might be useful to add is the option for including dependsUpon or some such in your schema… As that can be a nice way to start preloading site files and reduce fetch times.

Concurrency being key in most site loading situations that could potentially be quite the boon to page loads with many resources…


I think both of these are strong (unless i’m missing some initialism… :stuck_out_tongue: )


1 Like