But domains are not in the safe network. They are public IDs. You know its all personal in SAFE
Domains brings in a lot of other baggage that is not required for the safe network. Domains had a lot to do with network engineering and mapping out networks etc and less to do with semantics. And to use it for ID naming just grates and just so wrong.
Maybe an example using completely different things might help.
They are both
- approx round when filled
- things go into them and back out at a different time
- both made of synthetic material
- both are rolled up at times
- both are rolled out at times
- both can get holes in them with bad effect
- both can be used by both men and women
- and so on
But are they at all similar apart from some attributes? Its almost like chalk and cheese these two, just like public IDs and Domains are. The example was hosiery worn by people and a garden hose.
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.
Secure Naming System.
Simple and to the point.
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.
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.
Doesn’t seem like anything that’s widely used and would cause much confusion though
Indeed, after a bit of searching both references seem to be from old, not widely used protocols.
We’ve updated the RFC here:
RFC #0052 RDF for public name resolution
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
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.
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.
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
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.
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://something-else.AC can all point to different data structs (and on and on with
@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?
#www is the fragment of the URL right? How that can point a service MD?
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?
Yeah! Thanks @joshuef that make sense: +1:
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
Thanks, @bochaco So the example here point’s to an IMD to resolve it’s subName
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
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.