[RFC] Public Name System: Resolution and RDF


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


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



Peener, better known as, well. You get the idea. Sorry I ruin everything. I actually really like SNS for SAFE Name System.


I am not following what you’re trying and concluding.

What is the point of a default on a ‘files map’, i.e. directory? I understand the point of a default service in a resolvable map, but that seems like a whole different use case.


Unless I get it wrong, it can be used when you are fetching a webapp/website and there is no explicit file in the path of the URL, e.g. in safe://myname.mypubname is translated to safe://myname.mypubname/index.html, and currently that index.html default is hard-coded, so by having a default in the FilesMap the browser can fetch it for loading the website/webapp.

Perhaps another example/use case would be that the default in a directory with pictures is the album’s cover picture, or in JAMS the default in the directory with songs files is the album’s cover @Nigel :wink:

So you mean this would be a hint with links to other FileItems in the same FilesMap so the browser can trigger the fetch of all them in parallel, presumably caching them for when the website/webapp tries to fetch them?
If so, It sounds interesting, although wouldn’t it be better to keep this as a separate feature, as it’s probably more of an enhancement and which may be even just something specific for the browser app…?..


I had to look that up. New one for me. Learn something new every day. Guess people who eat Hot Dogs never consider how they got their name either. :wink:

Guess its gotta be SNS then


…we might wanna consider avoiding a potential collision with this other SNS…?!..: https://github.com/solid/solid/issues/201 :roll_eyes:


It should be possible to find a meaningful 3 letter acronym of format <x>ns, d<x>s or dn<x>.
And preferably one without an unwanted collision or connotation.

A couple of other ideas:

Dna dynamic naming arrangement
Dnc dynamic naming coordination
Dno dynamic naming organization
Dnr dynamic naming regulation or resolution

Xns Xns naming system


A default on a Files Map allows you to configure index.html or whatever.html to be resolved when pointing straight to a Files Map without a path defined. (Similar to how you can configure a server to default to a given resource if nothing is specified).


Hmmmm. Not sure. It could certainly be something we add to the schemas later, if that’s what you mean (to avoid muddying the waters of this RFC).

I think it makes sense to exist in the schema to define it properly though (And the idea is general enough, I don’t think it should be browser specific… (A video could depend upon a list of subtitles to retrieve eg).


Throwing some more 3 letter combos at the wall:
DDN - distributed domain naming
DRS - domain resolution system


They are not domains in SAFE are they? Just public names and concept of domain is not present.

Distributed Naming System - DNS
Distributed Public ID System - DPIS or DPIDS or DPS


DPS doesn’t sound too shabby. I thought we were previously referring to SAFE’s DNS as Decentralized Naming System?


How about…
SAFE Decentralized Naming System


Playing with some words for fun… don’t hold me to any of these…

SNLS : Safe Name Lookup System , pronounced “Snails” because it’s fast!
SORS : Safe Object Referral System, because it hurts to translate XORs manually.
ROX : Respect Our XOR.
POX : Provider Of XOR, “Page redirects easily transmitted from person to person…”
SOX : [S]AFE [O]bject [X]ORs, “Better than your old SOCKS from the 90’s”
SDR : Safe Domain Resolution, “At least it’s better than a random basket of fiat.”
XOR : [X]OR [O]bject [R]esolution. “If GNU can do it why can’t we?”
SNR : Safe Name Resolution, “Maximize your signal to noise ratio in the SAFE network!”
DDT: Distributed Domain Translation, “Poison for worms and malware alike.”


I’m note so sure. The public name controls all the private data and services/subdomain prefixes too. Each user is the master of their domain are they not?


Haha I like this one