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.
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://www.AC
, safe://DirtyDeeds.AC
, safe://something-else.AC
can all point to different data structs (and on and on with Sub Names
)
@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?
@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?
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.
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
@joshuef here is that list
ONS - Open Naming System @draw, @neo
sns - safe naming system @jlpell
PNR - Public Name Resolution
PNRS - Public Name Resolution System
NNS - Network Naming System
PNNS - Public Network naming System
PDNS - Public Distributed Naming System
DDN - distributed domain naming @drehb
DRS - domain resolution system @drehb
DPIS - Distributed Public ID System - or DPIDS or DPS
SDNS - SAFE Decentralized Naming System
DPNS - Distributed Public Naming System
Following up re: @rob’s shortlist
I believe SNS is a writeoff w/r/t Solid Name System. And DPNS will suffer as much as PNS just with added definite article.
I’m wary of Public ID
in there as there’s a lot of potential with WebIDs and I fear sowing confusion around the ID
term,
I’d personally advocate for less words to acronise (PNR > PNRS) .
From that list, I prefer: