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.
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.
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?
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?
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://www.AC, safe://DirtyDeeds.AC, safe://something-else.AC can all point to different data structs (and on and on with Sub Names)
@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.
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 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
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.
