The routing problem in content-centric networks is making (efficiently and resiliently) a connection between content names and hosts.
The overall idea of the user-oriented name system is to address a subset of the problem where the content is addressed by author first and filename second (but in a manner that still de-couples content from hosts).
UNS, much like DNS, works as a hierarchical resolution algorithm. It talks to root-level ANS servers to find trackers given an author name.
Trackers, much like bittorrent, enable hosts to register their ability/desire to serve content for a specific content name, which is then later used to answer user queries of where to find content.
UNS servers exchange data between themselves with a gossip protocol, propagating the routing tables (mapping usernames to trackers) to each other, eventually converging.
An HTTP gateway can be put between users and hosts by querying CNS to determine which hosts are contribuiting serving the filename. WebPackaging plays role of giving crypotgraphic attribuition to the original author - independently of who is hosting it.
Author-oriented names are represented as syntactically structured strings. A concrete example are email addresses (e.g. [email protected]): they are structurally well-defined and easily identifiable. Another example could be a pgp key. Domain names is another example. I'll use domain-name addresses going forward for simplication.
For example, sgo.to is my personal domain name.
Trackers register their desire to track hosts with CNS for a name pattern (e.g. ** register their desire to track host for any name).
HTTP server hosts (e.g. 199.73.55.35) query CNS to find which trackers are responsible for the sgo.to name. They then go on to register their desire to host content for sgo.to, associating their IP addresses with file patterns.
Browsers resolve the sgo.to DNS which points to a CNS HTTP gateway. The gateway talks to CNS to query what trackers track the sgo.to name. The gateway then talks to to trackers to identify which host hosts the resource. Finally, the gateway fetches the HTTP resources through HTTP and returns their response.
CNS servers and trackers run a gossip protocol between themselves, creating a network of copies of the routing tables, enabling the network to be resilient to single-point failures.
- ~7B people on earth
- ~100 character per username (e.g. [email protected])
- 16 bytes per IP address
Leads to ~11 TB (7,000,000,000 * 100 * 16 / (1,000,000,000,000)).
Even if we extrapolate a future with 100X people on earth, that would still lead to something that would fit into current storage capacity for a single machine.
If it is possible to store a mapping of all users to IP addresses in a single machine, then the next level of scalability challenge is storing all named-content.
//[email protected]/foobar.html
//[email protected]/photos/2018/07/01/IMG12134354.png
...
One design is to enable entries to point to other pages.
//[email protected]/photos/... -> 123.334.343.122
//[email protected]/photos/... -> 123.334.343.123
...
Assuming all levels (e.g. root level with all usernames and page levels) fit into a single machine's storage capacity, we could trade the runtime querying to storage, flooding every single node with all of the information it needs to make decisions without querying the network further for the level it is responsible for.
CNS nodes proxies HTTP servers to enable the de-coupling of content from host.
- Ultimately a public key
PGP:AB41.C1C6.8AFD.668C.A045.EBF8.673A.03E4.C1DB.921F
- bitcoin addresses
bitcoin:17NKcZNXqAbxWsTwB1UJHjc9mQG3yjGALA
- namecoin addresses
- email addresses
[email protected]
Naming is composed of two parts:
- author
- filename
For example:
//PUBLIC_KEY/path/dir/filename.ext
Or
//[email protected]/path/dir/filename.txt