Hello - I’m in the process of updating the Primer and I’m a bit stuck on this part concerning the NFS (chapter 10). I never quite understood it in the first place and with the introduction of AppendOnly data and the stipulation that MD must now be private I’m really unsure.
Websites on the SAFE Network can be identified using URLs thus: safe://service_name.public_id (e.g. safe://mysite.alice). Working in a similar way to the familiar Internet Domain Name System (DNS), these human-readable addresses are translated into Network addresses on SAFE using the Decentralized Naming System - also abbreviated DNS [Now NRS, correct?].
On the SAFE Network the DNS takes a hash of the Public_ID, so ‘alice’ in our example becomes a string of 256 characters. The browser takes this hash and uses it as the address to find the corresponding MutableData entity [Are we still using MD or is this now AD?].
Now the browser finds the Service Name ‘mysite’ in Alice’s MutableData entity. The corresponding value will be a MutableData Name [I never understood this bit, is Name a key? Is it still MD?]. Using that MutableData Name and the type tag of 15002 the browser can now obtain the address of another MutableData entity which is part of the NFS and contains the names and addresses of the ImmutableData files that make up the website. With this information it can start retrieving the website’s files.
All MD are now AD above (because this is all published data so we store all versions).
NFS is not yet clear, currently it has vanished and I’m not sure it will be coming back although for this section I’m not sure it matters because…
Instead of retrieving an MD with type tag 15002 I think an AD with be retrieved which is used as in RDF emulation mode as a Files Container. I can’t remember the type tag, but could look this up later.
Thanks Mark. That’s helpful. Clearly quite a lot has changed, I’ll wait for @bochaco to confirm the details. I take it the data map of a file is still MD as it is never public and there is a strong case for deletion?
Here’s what the RFC says. (the doubt I have is that according to this RFC we can never delete a previous name, just create a new version).
NRS data on the network, is by its very nature, public. Which means that it cannot be deleted. This concept forms the basis of the Perpetual Web, where data can only be appended to (using AppendOnlyData). 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. This means that all versions of the data can be accessed (via version ?v=222 url params, see xorurl rfc for more info, as well as the order of this data, and the timestamp changes were made. (Although these timestamps are applied client side, and therefore are optional so should not be treated with any reverence.)
“MutableData name” is just shorthand for its XOR-name, which is part of a MutableData address which also consists of a tag type and kind (sequenced or unsequenced).
Assuming here you talk about the new FilesContainers, they could be Published/Unpublished AppendOnlyData, so far we have only implemented the published version which is what is allowing us to have websites on phase1 releases, each version (i.e. each appended entry) of the AppendOnlyData is a full RDF (not really an RDF yet but it will be) with the mapping of files names to Published Immutable data XOR-URLs. Thus, these FilesContainers cannot be removed, they belong to the pWeb.
Eventually (just as soon as other higher priority things are solved) we will also have Unpublished FilesContainers, which will be Unpublished AppendOnlyData, with an RDF that has the mapping from files names to Unpublished Immutable data XOR-URLs, these will be removable from the network since we know that Unpublished data is removable.
Thanks @bochaco. By ‘data map’ I mean the record of where the various chunks that make up a file reside, the map that is held by the client so that a file can be retrieved. I’ve seen David refer to this as a data map, but I don’t know if that’s the official name for it. Is this still current? If so the data type would be an MD, correct?
ah right, that’s part of the self-encryption mechanism which is still not in place in new APIs/releases.
I presume that for unpublished data it could still be MDs, but if we want to have self-encryption for published data (well, we may not need to support encryption in this case, but the chunking process) then it may have to be an AppendOnly data, or even can be an ImmutableData as it won’t change.
For me too @JPL, and if I remember correctly the data map was an Immutable data chunk before, so I presume the answer then is it will still be a Published/Unpublished Immutable data chunk. What before was a MD (the NFS MD) is what now is a FilesContainer (i.e. AppendOnlyData). I hope this clarifies completely, i think i was even confusing myself in previous response