This runbook covers all steps necessary to install the Internet Computer Operating System (IC-OS) using the legacy NitroKey HSM instructions. To use the non-HSM onboarding instructions, follow the [[IC-OS Installation Runbook]].

The physical machine is expected to be racked and stacked according to its respective manual.

To complete these steps, you are expected to be physically present in the data center your machine(s) reside(s). Once you successfully onboard your first node, you can bring up the others in parallel.

If you encounter issues through any of these steps, check the [[Node Provider Troubleshooting]] page. If that does not solve your problem, you are encouraged to ask for assistance in the [[Node Provider Matrix channel]].

==1. Choose onboarding path (HSM vs no HSM)==
If you chose the [[Node Provider Onboarding#5. Choose onboarding path .28HSM vs no HSM.29|HSM Node Provider Onboarding Path]], '''continue to the next step.'''

If you chose to onboard '''without''' a Nitrokey HSM, follow the [[IC-OS Installation Runbook]] to onboard your nodes.

==2. Obtain requirements==
*A USB (3.0 speed that can hold at least 4GB) to put the image file on.
** Faster USBs will allow the process to go much faster.
*The NitroKey HSM for your data center.
*[Optional] A USB hub
** This is helpful at some data centers for simultaneously connecting keyboard, mouse, Nitrokey, etc.
*It is recommended that each server has a label with the BMC's MAC address for ease of identification in future dashboard upgrades.

==3. Download installation image==
Download the latest release of the '''IC-OS USB Installer Image''' and the '''corresponding checksum''' from the [https://dashboard.internetcomputer.org/releases Internet Computer Dashboard Releases].
*Note that you should always use a release that is less than 6 weeks old in order to ensure that your node can keep up with the blockchain.

==4. Verify checksum and unarchive file==
===Mac OS X===
#Open the Terminal and type:
#:<syntaxhighlight lang="shell">shasum -a 256 ~/Downloads/disk-img.tar.gz</syntaxhighlight>
#Compare the calculated checksum with the '''IC-OS installation image checksum''' file downloaded in the previous step. '''Warning:''' Only continue if they are identical, otherwise please post your issue in the [[Node Provider Matrix channel]].
#:Open the Terminal and type: <syntaxhighlight lang="shell">tar xzvf ~/Downloads/disk-img.tar.gz</syntaxhighlight>

===Linux / Ubuntu===
#Open the Terminal and type:
#:<syntaxhighlight lang="shell">sha256sum ~/Downloads/disk-img.tar.gz</syntaxhighlight>
#Compare the calculated checksum with the '''IC-OS installation image checksum''' file downloaded in the previous step. '''Warning:''' Only continue if they are identical, otherwise please post your issue in the [[Node Provider Matrix channel]].
#:Open the Terminal and type: <syntaxhighlight lang="shell">tar xzvf ~/Downloads/disk-img.tar.gz</syntaxhighlight>

===Windows===
#Open PowerShell and type:
#:<syntaxhighlight lang="shell">Get-FileHash -Algorithm SHA256 .\Downloads\disk-img.tar.gz</syntaxhighlight>
#Compare the calculated checksum with the '''IC-OS installation image checksum''' file downloaded in the previous step. '''Warning:''' Only continue if they are identical, otherwise please post your issue in the [[Node Provider Matrix channel]].
#:Open PowerShell and type: <syntaxhighlight lang="shell">tar xzvf .\Downloads\disk-img.tar.gz</syntaxhighlight>

==5. Create Bootable USB Stick==
===Mac OS X===
#Open the Terminal and type:
#:<syntaxhighlight lang="shell">diskutil list</syntaxhighlight>
#All available drives should be shown. Identify which device corresponds to your USB stick. You may need to unmount the USB drive:
#:<syntaxhighlight lang="shell">sudo diskutil unmount /dev/YOUR_USB_DEVICE_MOUNTED_PARTITION # E.g. /dev/disk4s1</syntaxhighlight>
#The file path is an example. Use the absolute path to the downloaded image. '''Warning:''' You risk losing your own data if you specify a wrong device.
#:<syntaxhighlight lang="shell">sudo dd if=/Users/YOUR_USER_NAME/Downloads/disk.img of=/dev/YOUR_USB_DEVICE bs=1M</syntaxhighlight>If you get a “device is busy” error from the dd command, you can try running the following command to unmount all of the partitions on the disk, then re-run the dd command:
#:<syntaxhighlight lang="shell">sudo diskutil unmountDisk /dev/YOUR_USB_DEVICE # E.g. /dev/disk4</syntaxhighlight>

===Linux / Ubuntu===
#Open the Terminal and type
#:<syntaxhighlight lang="shell">blkid</syntaxhighlight>
#All available drives should be shown. Identify which device corresponds to your USB stick. You may need to unmount the USB drive:
#:<syntaxhighlight lang="shell">sudo diskutil unmount /dev/YOUR_USB_DEVICE_MOUNTED_PARTITION # E.g. /dev/sdb1</syntaxhighlight>
#Replace ''/dev/YOUR_USB_DEVICE'' with the device that corresponds to your USB stick. '''Warning:''' You risk losing your own data if you specify a wrong drive.
#:<syntaxhighlight lang="shell">sudo dd if=~/Downloads/disk.img of=/dev/YOUR_USB_DEVICE bs=1M</syntaxhighlight>

===Windows===
#Download and install [https://rufus.ie/en/ Rufus Portable]
#Start Rufus
#Select the USB stick under device and select the previously downloaded IC-OS disk image and press start
#:[[File:05.png|480px|screenshot]]
#You may see some warnings. Make sure you don't have any other USBs in your computer and chose OK
#:[[File:06.png|480px|screenshot]]
#:[[File:07.png|480px|screenshot]]
#The "Ready" bar will go from left to right as it completes.

==6. Add configuration ==

===A. Open Config.ini in a text editor===

===='''Mac OS X'''====

#Open Finder. You should now be able to see the CONFIG partition. If it's not visible, remove the USB and insert it again.
#:[[File:mac_01.png|580px|screenshot]]
#Double-click <code>config.ini</code> to open it in TextEdit.

===='''Linux'''====

#Open the File Manager. You should now be able to see the CONFIG partition. If it's not visible, remove the USB and insert it again.
#:[[File:linux_01.png|580px|screenshot]]
#Double-click <code>config.ini</code> to open it in KWrite.

===='''Windows'''====

#Open the Disk Management utility with a right click on the Start menu.
#:[[File:09-b.png|300px|screenshot]]#:
#Right click the CONFIG partition.
#Select Change drive letter or paths...
#:[[File:10-b.png|780px|screenshot]]
#Select any letter from the drop-down list.
#:[[File:11-b.png|480px|screenshot]]
# Click OK.
# You should now be able to see the CONFIG partition in your Windows Explorer. Select the <code>config.ini</code> configuration file.
#:[[File:12-b.png|780px|screenshot]]
#Click on Edit to open it.

===B. Edit Config.ini===

#Insert your IPv6 prefix, subnet and gateway.
#:[[File:Edit config ini.png|580px|screenshot]]
#:*The IPv6 prefix should consist of four groups of hexadecimal digits, separated by colons (':'). Each group can contain up to four hex digits.
#:* For example, a valid prefix could look like this: <code>2a00:fb01:400:100</code>
#:*'''Important:'''
#:** The prefix should not have a trailing ':'
#:**IPv6 CIDR notation allows for a double colon ('::') to represent consecutive groups of zeroes in an address. However, the prefix configuration in this context does '''not''' support '::'. The '::' shorthand should '''not''' be used. Even if some groups are all zeros, they must be explicitly written out.
#Save the changes.
#:*If you have trouble saving this file directly, you may need to save to a known location first, then copy the file into place.
#:*If you need help, please do not hesitate to post your issue in the [[Node Provider Matrix channel]].
#:*:[[File:mac_03.png|580px|screenshot]]

==7. Connect Crash Cart==
#In order to configure the UEFI and initiate the installation of the IC-OS, please connect a crash cart to the physical machine.
#Plug-in the VGA/Video, keyboard and IC-OS USB stick
#:[[File:08.png|580px|screenshot]]

==8. UEFI Setup and Boot Menu==
Use the related page below to set up the BIOS/UEFI according to your hardware vendor.

*[[Node Provider Machine Hardware Guide#Gen 2 Node Machine requirements|Gen2 hardware]]
**[[IC-OS Installation - UEFI Configuration - Gen2 Dell]]
**[[IC-OS Installation - UEFI Configuration - Gen2 Supermicro]]
**[[IC-OS Installation - UEFI Configuration - Gen2 Gigabyte]]
**[[IC-OS Installation - UEFI Configuration - Gen2 ASUS]]
*[[Node Provider Machine Hardware Guide#Gen 1 Node Machine requirements|Gen1 hardware]]
**[[IC-OS Installation - UEFI Configuration - Gen1 Dell|IC-OS Installation - UEFI Configuration - Gen1 Dell (Poweredge R6525)]]
**[[IC-OS Installation - UEFI Configuration - Gen1 Supermicro]]
***
'''Important:''' Do NOT enable the RAID bios setting. Doing so will cause issues with the IC-OS installation.

Resume from this point when you are finished configuring the BIOS.

==9. IC-OS Installation ==
#Please wait while the USB Installer is booting up. This process can take up to 3 minutes.
#:[[File:35-sm.png|580px|screenshot]]
#The IC-OS installation starts. Please keep an eye on the progress. This part can take up to 10 minutes. Please remember to check the [[Possible Node Onboarding Errors]] page if you encounter any errors.
#:[[File:36-sm.png|580px|screenshot]]
#Once you get asked to insert the HSM, please remove the keyboard and instead insert the HSM USB device.
#:[[File:37-sm.png|580px|screenshot]]
#If the installation finished successfully, it will initiate a reboot. '''Please do not unplug the USB stick or HSM USB''' device at this point.
#:[[File:38-sm.png|580px|screenshot]]

==10. First Boot==
Please remember to check the [[Possible Node Onboarding Errors]] page if you encounter any errors onboarding.

🚨 '''Do NOT re-try the IC-OS installation after completing this section, as this can cause duplication within the registry.'''
#The first boot of the IC-OS still requires the HSM USB device. Please wait until further instructions. This step can take up to 2 minutes.
#:[[File:39-sm.png|580px|screenshot]]
#Once you see this message, you may unplug the HSM USB device, USB stick and VGA/Video. Your machine successfully joined the Internet Computer! **'''Label the server with the node ID for easy future identification in the dashboard (at least the first 10 characters). ***'''
#:[[File:Node join message.png|580px|screenshot]]

Congratulations! Your machine successfully joined the Internet Computer! The machine has joined the IC and the Node Provider will start receiving rewards!

🚨 Again: Once you reach this stage and see this message, '''do not attempt to restart the onboarding process.''' Doing so may cause duplicate entries in the registry.
==11. Verify node onboarding ==

#Verify that your node was successfully onboarded by checking its status on the [https://dashboard.internetcomputer.org/ dashboard] is set to either “Awaiting Subnet” or “Active in Subnet”.
#*The dashboard can be searched by your Node Provider principal. There, you should see the Node ID of your node (Node ID outputted in step 10).
#*If the status of your node is not either “Awaiting Subnet” or “Active in Subnet”, or if it is not listed under your Node Provider principal, you should contact the [[Node Provider Matrix channel]] for assistance.
#*:[[File:Dashboard-node-verification.png|thumb|998x998px]]

2022-11-15T10:45:24Z

Ruediger.birkner: Ruediger.birkner moved page Boundary nodes to Boundary Nodes: Capitalization of the title

The boundary nodes are the gateway to the Internet Computer (IC), which allow users to seamlessly access the canister smart contracts running on it. The following figure shows how the boundary nodes form the edge of the IC and all accesses to the IC have to go through one of the boundary nodes.

[[File:High-Level Overview.png|600px|center]]

== Boundary Node Internals ==

At a closer look, boundary nodes consist of two parts: the API node, which provides an endpoint for [https://internetcomputer.org/docs/current/references/ic-interface-spec/#http-interface API canister calls], and the HTTP gateway, which provides an HTTP endpoint for users to access the canisters hosted on the IC with their stock browser.

[[File:Boundary Node Overview.png|800px|center]]

=== API Node ===

The API endpoint resides at <code>ic0.app/api/v2</code> and is specified in the [https://internetcomputer.org/docs/current/references/ic-interface-spec/#http-interface IC’s Interface Specification].

Whenever a boundary node receives an API canister call, it passes it through a filter and then routes it to the right replica node in the IC.

Filtering within the boundary node consists of rate-limiting and an operator-maintained denylist. The rate-limits are in place to protect the IC from being overwhelmed with external accesses. The denylist allows a boundary node operator to comply with local legal frameworks (e.g., blocking gambling services in a particular geography).

After an API canister call passed the filtering stage, the boundary node extracts infers the destination canister ID and uses the routing table to look up the subnet in which this canister is hosted. It then randomly chooses a replica within that subnet to which it forwards the API call. The random selection of the target replica ensures that an API call eventually reaches an honest node when the client keeps retrying.

Finally, the boundary node forwards the API canister call to the selected replica node in the core of the IC.

Since the API Node is simply passing the API canister call on to the IC, no trust is required.

=== HTTP Gateway ===

Unfortunately, not all applications natively support API canister calls and therefore cannot directly talk to the canisters hosted on the IC. The [https://internetcomputer.org/docs/current/references/ic-interface-spec/#http-gateway HTTP gateway protocol] bridges that gap by enabling canisters to handle conventional HTTP requests allowing, for example, browsers to interact with canisters. A gateway implementing this protocol translates between HTTP requests and API canister calls and can be implemented in various forms (e.g., as a stand-alone proxy, as a browser plugin, or as a [https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API service worker]).

The boundary nodes provide two different implementations of the HTTP gateway protocol:

* Service worker: under <code><canister_id>.ic0.app</code>, the boundary nodes serve a [https://www.npmjs.com/package/@dfinity/service-worker service worker], which is installed in the browser and acts as an HTTP gateway directly in the user’s browser;

* <code>icx-proxy</code>: under <code><canister_id>.raw.ic0.app</code>, the boundary node runs [https://github.com/dfinity/icx-proxy <code>icx-proxy</code>], an HTTP gateway implementation suitable for all clients that do not support a service worker.

==== Service Worker ====

[[File:Service Worker Flow.png|900px|center]]

When accessing <code><canister_id>.ic0.app</code>, the boundary node returns a service worker implementing the HTTP gateway protocol, which is installed directly in the user’s browser (step 1 and 2). From then on, the service worker will intercept all HTTP requests and translate them to API canister calls (step 3). These API canister calls will then go through the API endpoint of the boundary node to the IC (step 4). The replica sends the response back through the boundary node to the service worker (step 5 and 6). For all responses, the service worker verifies the correctness of the response and only translates it into a proper HTTP response for the browser if it passes all the checks (step 7).

==== <code>icx-proxy</code> ====

The HTTP Gateway endpoint implements the HTTP gateway protocol, which translates between HTTP requests and API canister calls. This endpoint resides at <code><canister_id>.raw.ic0.app</code>. Whenever a boundary node receives such a request, it forwards it to <code>icx-proxy</code>, a service running directly on the boundary node that implements the HTTP gateway protocol. <code>icx-proxy</code> translates the HTTP requests into API canister calls and forwards them to the API endpoint of the boundary node. It verifies the certificates of the responses and constructs an HTTP response to send back to the client. Here, the user needs to trust the boundary node as the boundary node is constructing the API calls and verifying the correctness of the IC’s response.

== Additional Features of the Boundary Nodes ==

=== Globally-Distributed ===

The boundary nodes serving <code>ic0.app</code> are globally distributed and organized in regional pools. All requests are directed to the geographically closest pool and load balanced over the instances within that pool. The health of the boundary nodes is constantly monitored and in case of failure, boundary nodes will be removed from the pools.

=== SEO ===

Bots and crawlers, such as the ones used by search engines, unfortunately do not support service workers and are therefore not able to index content hosted under <code>ic0.app</code> out-of-the-box. However, they are able to access all the content under <code>raw.ic0.app</code> as the translation from HTTP requests to API calls happens within the boundary node. Therefore, boundary nodes detect all accesses of crawlers and bots to <code>ic0.app</code> and internally redirect them to <code>icx-proxy</code>. This allows the dapps running on the Internet Computer to seamlessly integrate into the Web 2.0 world. These dapps can be indexed by search engines and their metadata can be read in order to generate previews and cards on social platforms.

=== Caching ===

To improve the user-perceived performance of the dapps hosted on the IC, the boundary nodes currently provide response caching. Responses to requests are cached for 1s.

== Future Boundary Node Developments ==

To follow future boundary node developments check out the [https://internetcomputer.org/roadmap/ public roadmap], the [https://forum.dfinity.org/ IC developer forum] and the thread on the [https://forum.dfinity.org/t/boundary-node-roadmap/15562 future boundary node architecture].

Boundary Nodes

2022-11-15T10:44:15Z

Ruediger.birkner: The boundary nodes are the gateway to the Internet Computer (IC), which allow users to seamlessly access the canister smart contracts running on it.

File:Service Worker Flow.png

2022-11-15T10:26:22Z

Ruediger.birkner:

Upon the first request, the boundary node serves the service worker, which is then directly installed in the user's browser. From then on, the service worker intercepts all HTTP requests and translates them to API calls. The service worker verifies the certification of all responses.

File:Boundary Node Overview.png

2022-11-15T10:18:03Z

Ruediger.birkner:

The boundary node consists of two parts: the API node and the HTTP gateway.

File:High-Level Overview.png

2022-11-15T10:15:28Z

Ruediger.birkner:

High-level overview of how the boundary nodes provide access to the core of the Internet Computer. All requests go through one of the many boundary nodes, no matter where they originated (e.g., browser, mobile application, IC-native browser, web-extension).

HTTP asset certification

2022-11-02T14:09:07Z

Ruediger.birkner:

HTTP asset certification is a protocol that allows canisters to certify bodies of responses to GET HTTP requests.
The receiver of such responses can use the IC public key to authenticate the body of the response.
The protocol relies on [https://smartcontracts.org/docs/interface-spec/index.html#system-api-certified-data Certified data] feature of the IC.

== Canister protocol ==

A canister must follow the following protocol to certify assets:

<ul>
<li>
Construct a [https://smartcontracts.org/docs/interface-spec/index.html#_certificate hash tree] that maps paths of HTTP resources to SHA-256 hashes of their bodies.
An example of such a tree:
<pre>
*root*
└── http_assets
├── index.html -> SHA256(body)
├── ...
└── /css/styles.css -> SHA256(body)
</pre>
</li>
<li>
Compute the root hash of the tree and call [https://smartcontracts.org/docs/interface-spec/index.html#system-api-imports <code>ic0.certified_data_set</code>] with the bytes of the hash as the argument.
</li>
<li>
Add a [[#IC-Certificate header]] to each certified HTTP response.
</li>
</ul>

== Validator protocol ==

The validator follows the following steps to validate the certificate of resource at path <code>PATH</code> served by canister <code>CANISTER_ID</code>:

* Hash the body of the HTTP response, obtaining hash <code>DATA_HASH</code>.
* Check that the response contains the <code>IC-Certificate</code> header.
* Decode the <code>certificate</code> and the <code>tree</code> from the value of the <code>IC-Certificate</code> header.
* Check the validity of the certificate as described in the [https://smartcontracts.org/docs/interface-spec/index.html#certification Interface Specification: Certification]. This step requires knowing the IC root key.
* Check that <code>lookup(/http_assets/PATH, tree) = Found(DATA_HASH)</code>
* Check that <code>lookup(/canister/CANISTER_ID/certified_data, certificate.tree) = Found(reconstruct(tree))</code>.

== IC-Certificate header ==

The <code>IC-Certificate</code> header is a Structure Header (as per [https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-header-structure RFC proposal]) is a dictionary with members <code>certificate</code> and <code>tree</code>, both of which are Byte Sequences:

<pre>
IC-Certificate: certificate=:<base64(c)>:, tree=:<base64(t)>:
</pre>

where

* <code>c</code> is the CBOR-encoded certificate (see [https://smartcontracts.org/docs/interface-spec/index.html#certification-encoding Interface Specification: Encoding of certificates]).
* <code>t</code> is a Hash Tree, CBOR-encoded according the CDDL <code>#6.55799(hash-tree)</code> where <code>hash-tree</code> is the corresponding [https://smartcontracts.org/docs/interface-spec/index.html#api-cddl CDDL production in the Interface Specification].

The <code>certificate</code> must be a valid [https://smartcontracts.org/docs/interface-spec/index.html#_certificate Internet Specification: Certificate] with

<pre>
lookup(/canister/<canister_id>/certified_data, certificate.tree)
= Found (reconstruct(tree))
</pre>

The <code>tree</code> exposes the relevant nodes in the <code>/http_assets</code> subtree to allow the client to lookup the request path to get the expected body hash.

=== Example ===

For this example, we fetched <code>/index.html</code> resource of the Internet Identity canister (canister id <code>rdmx6-jaaaa-aaaaa-aaadq-cai</code>) available at https://rdmx6-jaaaa-aaaaa-aaadq-cai.raw.ic0.app/index.html.
The SHA-256 hash of the resource at the moment of fetching is <code>478afb8206ca0b566a7f138e623accd169fa822602d2f6d717fb67d1045f4f0d</code>.
The response contained the following header:

<pre>
IC-Certificate: certificate=:2dn3omR0cmVlgwGDAYMBgwJIY2FuaXN0ZXKDAYMBggRYIIudikoDwH1gRK637olblUhMUX3HlE0Dihj8MTACxGzHgwGCBFggyCRYc8M/ugt8G7C8RPYayn+l4sdBj8gvFotzJELnQ32DAYIEWCA1/+UHZ9SF67w4ssjOi+Jv3ch7WQNzezGmhtuvB+RDpYMCSgAAAAAAAAAHAQGDAYMBgwJOY2VydGlmaWVkX2RhdGGCA1ggWUt10wjWinx0aAWyrNEi/0R7VeuhalDMjGDErzIbZzqCBFgg/VtZRZdYyK/sr3KF2jWeS1rblF+4ajwfDv2ZbCGpaTiCBFggSoI5JS0pCusHP4nh6h780ebr961E0lVnFkFwzF5pZaeCBFggcKidPEGiPoFMPYfEyNGsDRYWmry1iGX0HNUEoKhIATeCBFggR0zdKUZOMcm5EHNl5Tee3XWqbq1gArwUGzZ2FH4rWtmCBFggTkwJcNrh0eJ9FutJcn6th9eCbM2KXnloxed0acxmQNeDAYIEWCA6SNH8IT1JMHEDEE99csK1kw7bqHh7kGMfNDs6popfCoMCRHRpbWWCA0nFnbXrts/65xZpc2lnbmF0dXJlWDCkXN2tcvH5b+xFCzfkuJMqrZDcplfW8vDziJwzx08WOPI4rh2TIGYZ3R6dgQTF0CA=:, tree=:2dn3gwGDAktodHRwX2Fzc2V0c4MBggRYIDgtAGcz5VvevwiEwwZB9zpkt17C9LE6o/O37bEwQUawgwGDAksvaW5kZXguaHRtbIIDWCBHivuCBsoLVmp/E45iOszRafqCJgLS9tcX+2fRBF9PDYIEWCCx2L8SfJwOydBkUxjc8tKXDVUeoiw8qEYI+8b+HRWIWYIEWCAqZ+3yoFSA9s+jbLFbtcVz+wi0HF9x51Kx38qPcBhiDA==:
</pre>

We can extract the following data from the header value:

<pre>
ROOT HASH: 0b2d843df534ac8ed2331fe2782deb71d23a08d9b4019a8fa695ec7fde93de36
TREE HASH: 594b75d308d68a7c746805b2acd122ff447b55eba16a50cc8c60c4af321b673a
SIGNATURE: a45cddad72f1f96fec450b37e4b8932aad90dca657d6f2f0f3889c33c74f1638f238ae1d93206619dd1e9d8104c5d020
CERTIFICATE TIME: 2022-02-02T08:23:24.851277509+00:00
CERTIFICATE TREE:
HashTree {
root: Fork(
Fork(
Fork(
Label("canister", Fork(
Fork(
Pruned(8b9d8a4a03c07d6044aeb7ee895b95484c517dc7944d038a18fc313002c46cc7),
Fork(
Pruned(c8245873c33fba0b7c1bb0bc44f61aca7fa5e2c7418fc82f168b732442e7437d),
Fork(
Pruned(35ffe50767d485ebbc38b2c8ce8be26fddc87b5903737b31a686dbaf07e443a5),
Label(0x00000000000000070101, Fork(
Fork(
Label("certified_data", Leaf(0x594b75d308d68a7c746805b2acd122ff447b55eba16a50cc8c60c4af321b673a)),
Pruned(fd5b59459758c8afecaf7285da359e4b5adb945fb86a3c1f0efd996c21a96938),
),
Pruned(4a8239252d290aeb073f89e1ea1efcd1e6ebf7ad44d25567164170cc5e6965a7),
)),
),
),
),
Pruned(70a89d3c41a23e814c3d87c4c8d1ac0d16169abcb58865f41cd504a0a8480137),
)),
Pruned(474cdd29464e31c9b9107365e5379edd75aa6ead6002bc141b3676147e2b5ad9),
),
Pruned(4e4c0970dae1d1e27d16eb49727ead87d7826ccd8a5e7968c5e77469cc6640d7),
),
Fork(
Pruned(3a48d1fc213d49307103104f7d72c2b5930edba8787b90631f343b3aa68a5f0a),
Label("time", Leaf(0xc59db5ebb6cffae716)),
),
),
}
TREE:
HashTree {
root: Fork(
Label("http_assets", Fork(
Pruned(382d006733e55bdebf0884c30641f73a64b75ec2f4b13aa3f3b7edb1304146b0),
Fork(
Label("/index.html", Leaf(0x478afb8206ca0b566a7f138e623accd169fa822602d2f6d717fb67d1045f4f0d)),
Pruned(b1d8bf127c9c0ec9d0645318dcf2d2970d551ea22c3ca84608fbc6fe1d158859),
),
)),
Pruned(2a67edf2a05480f6cfa36cb15bb5c573fb08b41c5f71e752b1dfca8f7018620c),
),
}
</pre>

== Limitations ==

* The protocol supports only one resource per path. This does not work well with content negotiation protocol.
* The protocol does not support certification of HTTP statuses and headers. Only resource bodies can be certified.

== Canisters using HTTP asset certification ==

* [https://github.com/dfinity/internet-identity/blob/7ff3dd51dd98c7b1b43d83950c9f31ea7159103d/src/internet_identity/src/main.rs#L775 Internet Identity canister]
* [https://github.com/dfinity/nns-dapp/blob/49126394df77b9583e508277fc736eda51de47be/rs/src/assets.rs#L123 NNS frontend]
* [https://github.com/dfinity/certified-assets Certified assets canister]

== Validators ==

* [https://github.com/dfinity/ic/tree/master/typescript/service-worker Certifying Service Worker]
* [https://github.com/dfinity/icx-proxy/blob/b0de0437fe6806a96d942465e5ee284c23b812e8/src/main.rs#L470 ICX proxy]