[RFC] Public Name System: Resolution and RDF


#62

Others that came to mind today were for SAIS, pronounced “say-I-S”, which has the same syllables as the familiar “Dee-N-S”.

SAIS : Safe Autonomous Identification System

SAIS : Secure Autonomous Identification System

It’s also a play on the French word for “I know”… such as “I know where your XOR is for the requested public ID.” Also hints at the fact that there is AI in the middle of the Safe System. :wink:


#63

SNS anyone?
Secure Naming System.
Simple and to the point.


#64

That one was popular, but @bochaco mentioned that project Solid started talking about a SNS or SolidNS last month…

I like XNS a lot from @draw. Xor Name System is also simple and to the point. It also sounds like an advanced Xtra special Domain Name System that the marketing folks could have fun with.


#65

The XNS acronym is already taken by something similar. From the other <x>NS acronyms I do find the current meaning of QNS cool: Quantity Not Sufficient.


#66

Doesn’t seem like anything that’s widely used and would cause much confusion though


#67

Indeed, after a bit of searching both references seem to be from old, not widely used protocols.


#68

hi all,

We’ve updated the RFC here:

RFC #0052 RDF for public name resolution

David.


#69

I’ve done some small updates / clarifications based on feedback here over the last week or so.

This also involved removing the publicName container info, which I’ll work into its own RFC.

This is in a new PR: https://github.com/maidsafe/rfcs/pull/284


#70

There has been a long and occasionally heated discussion on simplifying RDF on a w3 mailing list I subscribe to. Can’t say I understand a great deal of what’s going on, but a guy called David Booth has helpfully summarised the discussions here https://docs.google.com/document/d/12cPE-oi90bde1phn0H0_tJQzYAJ7gD1mQl13H0Lo694/edit# Just mentioning it in case it’s useful.


Solved: Requested service is not found
#71

Hey @joshuef @hunterlester @bochaco is it possible for this proposal to be exposed as experimental through the SAFE Browser on the Alpha 2 network or is it not possible because changes to safe client libs would have to be made?

Also I t’s been awhile since I’ve read up here so should refresh but this affects current NFS implementation correct?

Getting a 404 error when using the full RFC link.


#72

It should be possible, I think. It’s something I’m hopeful to get to soon, actually.

It would/could affect the NFS impl. It’s a point to discuss, do we want/need both? What do we lose if we do that? Should current NFS be modded to work atop this perhaps?

Full RFC is merged in now, https://github.com/maidsafe/rfcs/blob/master/text/0052-RDF-for-public-name-resolution/0052-RDF-for-public-name-resolution.md

I’ll get that updated in OP. Thanks for the heads up @Nigel


#73

Curious if you mean 10 redirects for each sub name?
So safe://AC/DC could have 10 redirects (going to 10 different albums) and safe://AC/DC/DirtyDeedsDoneDirtCheap could also have 10 redirects (going to the songs of that album) etc etc or just 10 redirects for anything after safe://AC/DC?

It’s an interesting idea and the former would be cool as hell but then each album would only be able to redirect to 10 songs per album. Just pondering what to do.


#75

It’s more like safe://AC is one redirect to a Map, which in turn could default to another map (and on and on) up to ten times, before getting to the FilesMap, which would then handle DC as a folder and DirtyDeedsDoneDirtCheap as a file within.

So it’s not that one thing can go 10 places, so much as finding that one thing, can do 10 redirects before we give up trying to find where the data actually is.


All of which is a different thing to using subNames eg : safe://www.AC, safe://DirtyDeeds.AC, safe://something-else.AC can all point to different data structs (and on and on with Sub Names)


#76

@joshuef I’m quite confused with this statement

`safe://www.happyurl` is the same as `<safe://asdadfiojf3289ry9uy329ryfhusdhfdsfsdsd#www>`*”

Here in PNS www is the Sub name that points an MD and happyurl is the Public name that again points an MD.
But in the XOR-URL,

  • which doesn’t have a typetag and the XOR-URL without tagtype is an immutable data right?
  • And #www is the fragment of the URL right? How that can point a service MD?

#77

@Shankar_S
The PNS system would use RDF (at an MD) to manage its subdomains.

The example XOR-URL is pointing to this same MD.

Thus, you can resolve the www portion of that RDF doc either as part of the subName system (www.happyurl), or as a document fragment with the retrieved RDF doc w/ direct access via the XOR-URL system.

Does that clarify some?


#78

Yeah! Thanks @joshuef that make sense: +1:


#79

I guess @Shankar_S was also pointing out that the example XOR-URL ( <safe://asdadfiojf3289ry9uy329ryfhusdhfdsfsdsd#www>) doesn’t have a type-tag/port so it’s not targetting a MD but an IMD. However I’m thinking that once we have RDF for PNS, we should be able to resolve things from an RDF stored in both MD and IMD…?..specially if we encode the content-type in the IMD XOR-URL so the resolver knows it’s an RDF and try to find the subName in it to resolve…?..this would be an scenario of immutable public name :slight_smile:


#80

Thanks, @bochaco So the example here point’s to an IMD to resolve it’s subName www.
As all our public names are in MD, should the example need to be updated? Or is it fine to keep it as immutable public name


#81

Just to clarify, what I mentioned was a proposal which I’m not sure if it was considered in the RFC, so I guess we need to analyse it and make sure it make sense to have this also supported.
Apart from that, it sounds to me somthing like resolving subNames even from a XOR-URL would be dependant on how the XOR-URL is finally defined, as there were ideas around using subNames for encoding things like typetag or version (not saying I’m in favour of them though).
Edit: I got confused, but the example is not using the subName in the URL for www but the fragmentstring, in that case, as per the discussions in XOR-URL RFC this could be considered to be against the separation of what part of the URL should be used merely for routing to the content and what is for the client side to use like querystring and usually fragmentstring are.


#82

That depends. On the XOR-URL level this routes to the ResolveableMap eg. The fragment is not part of that data resolution.

Then the app, could choose to resolve the fragment (if its a document that supports that, eg RDF / ResovleableMap). That’s beyond the scope of the XOR URL IMO