URL Hint Protocol
<!-- TITLE: URL Hint Protocol --> There exists a root `Registry` contract at address 0x42 (this is the auctioning thing). There exists a contract interface, `register`, which `Registry` implements. Entries in `register`, when looked up (indexed by a string32 name) have several value fields, including `content` and `register`. `content` is the content hash which gets loaded when you enter this name into Mist/AZ. `register` is the address of a subregistry contract (some contract implementing `register`) which gets queried recursively. ### Example - `eth://gavofyork` results in the main Registry (at 0x42) being queried for the entry `gavofyork`. The content field of this entry (a SHA3 hash of a zip file OR manifest) is used to display content (see Content section for more info). ## URL Composition All URLs canonically begin `eth://` and are a number of components, each separated by a `/`. The field `register` is used to do a recursive lookup. So the components of `gavofyork/tools/site/contact` would comprise four components, in order: `gavofyork`, `tools`, `site`, `contact`. Any periods `.` before the left-most slash `/` delineate components which are specified in reverse order. So non-canonical forms of the above address are: - `tools.gavofyork/site/contact` - `site.tools.gavofyork/contact` - `contact.site.tools.gavofyork` NOTE: any periods after the leftmost `/` are treated no differently than other alphanumeric characters. ### Example - `eth://gavofyork/site` results in the main Registry (at 0x42) being queried for the entry `gavofyork`. The register field of this entry (an address of a `register`-implementing contract) is then queried for the entry `site`. The `content` field of this entry is used to display content. # Content Normally Swarm would be used to determine the content from the content hash. For 1.0, this will not be possible, so we will fall back to using HTTP distribution. To enable this we will include one or many URLHint contracts, which provide hints of URLs that allow downloading of particular content hashes. Find the contract in dapp-bin. The content downloaded should be treated in many ways (and hashed) to discover what the content is. Possible ways include base 64 encoding, hex encoding and raw, and any content-cropping needed (e.g. a HTML page should have everything up to body tags removed). It will be up to the dapp/content uploader to keep URLHint entries updated. The address of the URLHint contract will be specified on an ad-hoc basis and users will be able to enter additional ones into their browser.