[RFC] Public Name System: Resolution and RDF


… And I don’t see a point in investing lifetime into a discussion that just exists to justify a decision that more or less has been made anyway… (feeling reminded on the annoying encoding discussion that has consumes way too much of my lifetime… )

Wouldn’t it make way more sense to discuss this in the main forum anyway if you want to get the opinion of ‘more or less regular people’ and not only developers…?

1 Like

No, actually I saying quite the opposite. I’m saying let’s keep an open mind, let’s think of the end user first and foremost, and let’s find a way of testing so that we can have confidence in the decisions we are making.

I think we’ve been pretty accommodating and open wouldn’t you? We are all sharing our opinions, and having them listened too, are we not?

Given that most of this chat stemmed from the fact that folk somehow were squeamish about PNS (which is pretty inconsequential in the scheme of things.) I don’t think you can say that. TBH if the PNS thing hadn’t be brought up, we’d have probably just continued in calling them public names.

I was really responding to the statement that a 1. people didn’t care about the name (not true) 2. a democratic process wasn’t desired (also don’t think thats true) and 3. that simple, understandable, non-misleading names for new technology with a massively diverse user base can be created in just an hour of someones time.

Sorry that is not my opinion, name is important and why choosing an inappropriate name is very important not to do. Unless you want SAFE to just appear to be the current internet in people’s minds by using the geek names - domains

I didn’t get this impression that people didn’t want to have a democratic process.

Which is why we should drop inappropriate names when shown to be so and consider more appropriate when suggested.

But we have the trend on the internet that the non-geeks have spoken they do want to use the term domain names and are using names like website name, website address, email address, and so on.

SAFE is simple for the user so there is no reason not use use simple names/terms/concepts so that the tech uneducated do not need to learn special definitions to understand how to access a safesite.

My suggestion is something like safename for how to refer to a name in the safe network. A name can be used for all sort of things, and so for a safesite it might be qualified and referred to as a safesite name or safenet address. For mail it could be safemail name. Address is not really legit for mail in SAFE since there is no address and its just the name entered into the mail app.

Not I am not against another way to refer to safe names, as long as its simple and fits with the way people think of referring to other people and sites now-a-days

Anyhow I think I’ll leave it there till good simple ways to refer to names is suggested. I have been pretty clear to my objections to complex references and the use of domains

1 Like

Okay… so I think we need to be able to move forward here. As this is all taking a hell of a lot of valuable time (that’s not to say it’s not important, but just not where I’d nessecarily want to be spending that time right now while we are really in the thick of things!).

So how about a proposal to call the system Name Resolution System (accurate and agreeable, wouldn’t you say?), and then we can leave the door open to a useful user-centred descriptor to go before the name part as and when it becomes required by the UX design. And we can test this in context.

And perhaps in the mean time we can agree to keep it internally codenamed as Public Names?

There are a bunch of other elements to all this still up in the air at the moment, but once they have shaken out a bit, we can perhaps see it all with more clarity, and make a better choice.

What say yee?


NRS is the chosen by 55% of voters so based on that I’d agree

Personally i think the public and APP developers will drive this. I’d suggest that its not forced by any core developer or by others. In my opinion it will develop organically, so keeping it simple for now would be best. Public Names, Safe Names, Safenet Names, Safenetwork Names or just Name are all good for the time being.


I like NRS if it is ‘Name Resolution Service’.
Otherwise, my last attempt, promise.

SNAP : Safe Network Address Protocol
SNAP : Secure Name Address Protocol
SNAP : SAFE Name, Address, Person
SNAP : Secure Name Access Protocol
SNAP : Safe Name Access Protocol

It’s a snap folks!

1 Like

I love that one the best until now!

Not the shortest but comes out very naturally

Oh wow. Hadn’t looked in here for a while. Would have loved to see this level of engagement from everyone in a topic like… for example… the entire SAFENetwork economy (just out of the blue) …

What is it I hear in the back of my head? B… bike- something?

Ah…! Bike shedding! :joy:

I read through the RFC… Will anyone be able to register any number of public names, where the cost is just a tiny amount to write the relevant data? Does this mean that when the network launches there will be a gold rush of name registration, people rushing to register all the common and short names like google/news/weather etc? How will trading of names be facilitated?

p.s. sorry if this has already been asked/answered/discussed


It’s an important issue and indeed has been discussed with various ideas on what to do about it. You’ll find those discussions mainly on the community forum but there is no clear, agreed solution to squatting AFAIK.


As we solidify the working of the rust fetch implementation, I’ve made a PR with some updates to the RFC: https://github.com/maidsafe/rfcs/pull/338

Main things are:

  • A name change!? :open_mouth: :peanuts:
  • data type updates to bring us in line with the modern SAFE Data types
  • a requirement for NRS map links to be versioned.

More detail on all that in the PR.


Is AOD (MutableData) an abbreviation? If yes: which is it? And maybe it is useful to add that to the rfc?

1 Like

AOD would be AppendOnlyData.
MutableData is shortened MD.

It seems the MDs were switched out for AODs, but the text here

I’m using MutableData ( AOD )

was left with MutableData, when it should say AppendOnlyData.

1 Like

Ah, good spot. Will fix that in the PR thanks @draw @oetyng :bowing_man:


FYI, PR updated to be: https://github.com/maidsafe/rfcs/pull/343

This contains fixes to test issues outline by @draw, @oetyng and @bzee :bowing_man:


I’ve just read the version with the latest pull requests.

A couple of questions:

  • This is probably discussed on the forum somewhere, but how does that work with an UTC timestamp being the key?:

As a consequence RDF data described here is a type of ‘versioned’ data, with the key of an AOD being a UTC timestamp , and the value of an entry being a string representation of the RDF data.

  • Is it ok to have a ‘https://…’ instead of a ‘safe://…’-URL in this context? From the latest the latest RFC version:

@vocab”: “https://raw.githubusercontent.com/joshuef/sschema/master/src/

  • So if you don’t append the version (?v=<version>’) to a SAFE NRS URL in the SAFE Browser or the SAFE cli the most version recent is found/used automatically? Or is the version also required there (eventually)?:

    And so in order to facilitate the Perpetual Web and canonical URLs, NRS containers will require that linked data MUST specify a version for the target data.

  • What is the first version: version 0 (?v=0) or 1 (?v=1). Or is version 0 the reference (like when you give no version number in the SAFE Browser), giving you the most recent version and version 1 the real first version.
    -> If you look in the rfc you see 1 instance of ?v=0:

    @id”: “safe://thisxorurl?v=0”,

And concerning version 1:

The RDF document will have a version relating to the version of the Resolvable Map data structure in use. (starting at v1 .)

Keep up the good work :+1:

1 Like

Basically w/ ‘versioned’ data, we’re currently putting a time stamp as a key (though the order of appends can be determined so this is just helpful for UI later most likely), and so you have: <now> : ` as each key: value.

… could you have http links? Hmmm, scheme wise I guess so (nothing blocking it atm), but would this be resolved depends on the app (and the browser would not currently). Should it be prohibited? I’m not sure…

We’re operating under the idea that versions MUST be appended, so any change to underlying data, to be shown art a url MUST update the NRS map itself, thus making changes simpler to track on the domain.

Versions are 0 indexed. So yeh, that RDF v1 quote is outdated. (Ie v=0 gives the first version).

Apologies for formatting, on many iPad at web3 atm, quoting is a pain :expressionless:

Hope that answers your Qs @draw!

1 Like

Thank you for the answers!

  • Concerning the date: is it only informative (for humans), or is it also really necessary as (part of) a ‘primary key’ (or to generate a unique hash/Xor address) to get the data, because is the version number not enough for that (and also for getting the correct order)?
  • Concerning the http links: Not that I think it should be possible. I just noticed it is mentioned in the RFC where I didn’t expect it: I would think you don’t want to access the clearnet to get the graph (@vocab… to be more exact). If it is not prohibited, then the RFC doesn’t need to be updated to be ‘correct’, I guess?

The date is indeed only informative, and not guaranteed to be accurate (it’s created client side). It could really be any value.

Re: HTTP, i think for @context (basically identifying the RDF schema), this is acceptable. There may be situations where you want to reference that you’re using a schema that is at home on the clearnet, so HTTP seems okay here. (It’s not like this URL is actually accessed in any way at the moment, it’s just to know you’re using the same schema as someone else. Down the line, hopefully these’ll all be on SAFE. But I don’t think we need to block that atm.

FYI https://github.com/maidsafe/rfcs/pull/344 is the latest with a tweak sorting the v=1 reference to make that a bit clearer. This supersedes the previous (and I should be able to make any more tweaks directly there now).


FYI, I’ve submitted a pull-request to address some areas that were unclear/undefined. The idea is to make the RFC and the code match, and make these areas clearer for other implementers in the future.


* introduce 'Top Names' nomenclature.
* introduce 'SAFE-URL` nomenclature.
* define 'Public Names' as SubNames + TopNames.  finally consistent with definition as "equivalent" to `host` in a standard URL.
* Add examples for usage of `Public Name`, `Top Name`, `Sub Name`.
* change URL 'host' reference to DNS 'domain', which is a better match
* Re-write Path Resolution section, and include Version.
* Add section SAFE-URL Reserved Query String Parameters
* add 'Fragment Resolution' section
* Add a section on resolving recursive NRS-URLs

See: https://github.com/maidsafe/rfcs/pull/356