aboutsummaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
authorpukkamustard <pukkamustard@posteo.net>2021-07-19 14:20:14 +0200
committerpukkamustard <pukkamustard@posteo.net>2021-07-19 14:20:14 +0200
commit07296d5c86c31faea55dec511a39e3dc8976f73b (patch)
treec748e4ddff6f2cbec2cb53f308b81c11c8da822c /doc
parentd2905d6208a5c7acebcfd176adf690d811a2a3d9 (diff)
remove specification
Split specification and reference implementation into seperate repositories.
Diffstat (limited to 'doc')
-rw-r--r--doc/diagrams.org119
-rw-r--r--doc/eris-cache.org53
-rw-r--r--doc/eris-merkle-tree.svg417
-rw-r--r--doc/eris.adoc567
-rw-r--r--doc/eris.adoc.license3
-rw-r--r--doc/eris.org728
6 files changed, 0 insertions, 1887 deletions
diff --git a/doc/diagrams.org b/doc/diagrams.org
deleted file mode 100644
index f814c20..0000000
--- a/doc/diagrams.org
+++ /dev/null
@@ -1,119 +0,0 @@
-#+TITLE: Diagrams
-#+PROPERTY: header-args:dot :cmdline -Nfontname=sans-serif -Tsvg :eval never-export :exports results
-
-* Merkle Tree
-
-#+BEGIN_SRC dot :file eris-merkle-tree.svg :exports results
-digraph {
- node [shape=record] ;
-
-
- subgraph cluster__level_0 {
- style=dotted;
- label="level 0 (input content)";
- labeljust="l";
-
- block_7 [shape=box,color=lightblue,style=filled,label="block-7"];
- block_6 [shape=box,color=lightblue,style=filled,label="block-6"];
- block_5 [shape=box,color=lightblue,style=filled,label="block-5"];
- block_4 [shape=box,color=lightblue,style=filled,label="block-4"];
- block_3 [shape=box,color=lightblue,style=filled,label="block-3"];
- block_2 [shape=box,color=lightblue,style=filled,label="block-2"];
- block_1 [shape=box,color=lightblue,style=filled,label="block-1"];
- block_0 [shape=box,color=lightblue,style=filled,label="block-0"];
-
- rk_0_7 [shape=record, color=yellow, style=filled, label="r | k"];
- rk_0_6 [shape=record, color=yellow, style=filled, label="r | k"];
- rk_0_5 [shape=record, color=yellow, style=filled, label="r | k"];
- rk_0_4 [shape=record, color=yellow, style=filled, label="r | k"];
- rk_0_3 [shape=record, color=yellow, style=filled, label="r | k"];
- rk_0_2 [shape=record, color=yellow, style=filled, label="r | k"];
- rk_0_1 [shape=record, color=yellow, style=filled, label="r | k"];
- rk_0_0 [shape=record, color=yellow, style=filled, label="r | k"];
- };
-
- rk_0_0 -> block_0 [style=dotted];
- rk_0_1 -> block_1 [style=dotted];
- rk_0_2 -> block_2 [style=dotted];
- rk_0_3 -> block_3 [style=dotted];
- rk_0_4 -> block_4 [style=dotted];
- rk_0_5 -> block_5 [style=dotted];
- rk_0_6 -> block_6 [style=dotted];
- rk_0_7 -> block_7 [style=dotted];
-
- subgraph cluster__level_1 {
- style=dotted;
- label="level 1";
- labeljust="l";
-
- node_1_0 [shape=record, color=lightblue, style=filled, label="node"];
- node_1_1 [shape=record, color=lightblue, style=filled, label="node"];
- node_1_2 [shape=record, color=lightblue, style=filled, label="node"];
- node_1_3 [shape=record, color=lightblue, style=filled, label="node"];
-
- rk_1_3 [shape=record, color=yellow, style=filled, label="r | k"];
- rk_1_2 [shape=record, color=yellow, style=filled, label="r | k"];
- rk_1_1 [shape=record, color=yellow, style=filled, label="r | k"];
- rk_1_0 [shape=record, color=yellow, style=filled, label="r | k"];
-
- };
-
- node_1_0 -> rk_0_0;
- node_1_0 -> rk_0_1;
-
- node_1_1 -> rk_0_2;
- node_1_1 -> rk_0_3;
-
- node_1_2 -> rk_0_4;
- node_1_2 -> rk_0_5;
-
- node_1_3 -> rk_0_6;
- node_1_3 -> rk_0_7;
-
- rk_1_0 -> node_1_0 [style=dotted];
- rk_1_1 -> node_1_1 [style=dotted];
- rk_1_2 -> node_1_2 [style=dotted];
- rk_1_3 -> node_1_3 [style=dotted];
-
- subgraph cluster__level_2 {
- style=dotted;
- label="level 2";
- labeljust="l";
-
- node_2_1 [shape=record, color=lightblue, style=filled, label="node"];
- node_2_0 [shape=record, color=lightblue, style=filled, label="node"];
-
- rk_2_1 [shape=record, color=yellow, style=filled, label="r | k"];
- rk_2_0 [shape=record, color=yellow, style=filled, label="r | k"];
-
- };
-
- node_2_0 -> rk_1_0;
- node_2_0 -> rk_1_1;
-
- node_2_1 -> rk_1_2;
- node_2_1 -> rk_1_3;
-
- rk_2_0 -> node_2_0 [style=dotted];
- rk_2_1 -> node_2_1 [style=dotted];
-
- subgraph cluster__level_3 {
- style=dotted;
- label="level 3";
- labeljust="l";
-
- node_3_0 [shape=record, color=lightblue, style=filled, label="node"];
-
- rk_3_0 [shape=record, color=yellow, style=filled, label="r | k"];
-
- };
-
- node_3_0 -> rk_2_1;
- node_3_0 -> rk_2_0;
-
- rk_3_0 -> node_3_0 [style=dotted];
-}
-#+END_SRC
-
-#+RESULTS:
-[[file:eris-merkle-tree.svg]]
diff --git a/doc/eris-cache.org b/doc/eris-cache.org
deleted file mode 100644
index 138b27b..0000000
--- a/doc/eris-cache.org
+++ /dev/null
@@ -1,53 +0,0 @@
-# SPDX-FileCopyrightText: 2020 pukkamustard <pukkamustard@posteo.net>
-#
-# SPDX-License-Identifier: CC-BY-SA-4.0
-#+TITLE: ERIS Cache
-#+AUTHOR: pukkamustard
-#+HTML_HEAD: <style>body {margin: 40px; font-family: sans-serif;} #content { line-height: 1.6; font-size: 16px; color: #222; max-width: 800px;margin: 40px auto;} pre.src {overflow: auto;}</style>
-#+PROPERTY: header-args:scheme :session *eris-cache-model-repl* :eval never-export
-#+OPTIONS: toc:nil
-
-#+BEGIN_abstract
-An extension to the W3C PROVenance Interchange Ontology to describe the activity of content-addressed caching with the ERIS encoding.
-#+END_abstract
-
-#+TOC: headlines 2
-
-* Introduction
-
-By content-addressing RDF data we can increase the robustness of systems as the content is decoupled from a single location where it is hosted [cite:ContentAddressableRDF2020].
-
-A lot of content is already published using location-addressed identifiers (URLs). Such content can be made content-addressable. This improves the availability of the location-addressed content and may be seen as a content-addressed cache.
-
-We propose a vocabulary to describe the original source of the content-addressed cache as well as other circumstances that describe the creation of the cache as an extension to the W3C PROV-O ontology [cite:lebo2013prov].
-
-The proposed ontology is tied to the ERIS encoding scheme [cite:ERIS_2020].
-
-* Vocabulary
-
-#+BEGIN_SRC ttl :exports code :tangle eris-cache.ttl
-@prefix ec: <http://purl.org/eris/cache#> .
-@prefix prov: <http://www.w3.org/ns/prov#> .
-@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
-@prefix owl: <http://www.w3.org/2002/07/owl#> .
-
-<http://purl.org/eris/cache#>
- a owl:Ontology ;
- rdfs:label "ERIS Cache Vocabulary"@en ;
- rdfs:comment "An extension to the W3C PROVenance Interchange Ontology to describe the Activity of content-addressed caching with the ERIS encoding."@en .
-
-ec:CreateCache
- a rdfs:Class ;
- rdfs:label "CreateCache" ;
- rdfs:comment "The activity of creating an ERIS encoded, content-addressed cache of some content.";
- rdfs:subClassOf prov:Activity .
-#+END_SRC
-
-
-bibliography:refs.bib
-
-#+BEGIN_EXPORT html
-<p>
-<a rel="license" href="http://creativecommons.org/licenses/by-sa/4.0/"><img alt="Creative Commons License" style="border-width:0" src="https://i.creativecommons.org/l/by-sa/4.0/88x31.png" /></a><br /><span xmlns:dct="http://purl.org/dc/terms/" href="http://purl.org/dc/dcmitype/Text" property="dct:title" rel="dct:type">ERIS Cache</span> by <a xmlns:cc="http://creativecommons.org/ns#" href="https://openengiadina.net/" property="cc:attributionName" rel="cc:attributionURL">openEngiadina</a> is licensed under a <a rel="license" href="http://creativecommons.org/licenses/by-sa/4.0/">Creative Commons Attribution-ShareAlike 4.0 International License</a>.
-</p>
-#+END_EXPORT
diff --git a/doc/eris-merkle-tree.svg b/doc/eris-merkle-tree.svg
deleted file mode 100644
index 8008cf7..0000000
--- a/doc/eris-merkle-tree.svg
+++ /dev/null
@@ -1,417 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
- "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
-<!-- Generated by graphviz version 2.42.3 (20191010.1750)
- -->
-<!-- Title: %3 Pages: 1 -->
-<svg width="710pt" height="643pt"
- viewBox="0.00 0.00 710.00 643.00" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
-<g id="graph0" class="graph" transform="scale(1 1) rotate(0) translate(4 639)">
-<title>%3</title>
-<polygon fill="white" stroke="transparent" points="-4,4 -4,-639 706,-639 706,4 -4,4"/>
-<g id="clust1" class="cluster">
-<title>cluster__level_0</title>
-<polygon fill="none" stroke="black" stroke-dasharray="1,5" points="8,-8 8,-156 694,-156 694,-8 8,-8"/>
-<text text-anchor="middle" x="95.5" y="-140.8" font-family="Times,serif" font-size="14.00">level 0 (input content)</text>
-</g>
-<g id="clust2" class="cluster">
-<title>cluster__level_1</title>
-<polygon fill="none" stroke="black" stroke-dasharray="1,5" points="207,-164 207,-313 493,-313 493,-164 207,-164"/>
-<text text-anchor="middle" x="239" y="-297.8" font-family="Times,serif" font-size="14.00">level 1</text>
-</g>
-<g id="clust3" class="cluster">
-<title>cluster__level_2</title>
-<polygon fill="none" stroke="black" stroke-dasharray="1,5" points="279,-321 279,-470 421,-470 421,-321 279,-321"/>
-<text text-anchor="middle" x="311" y="-454.8" font-family="Times,serif" font-size="14.00">level 2</text>
-</g>
-<g id="clust4" class="cluster">
-<title>cluster__level_3</title>
-<polygon fill="none" stroke="black" stroke-dasharray="1,5" points="315,-478 315,-627 385,-627 385,-478 315,-478"/>
-<text text-anchor="middle" x="347" y="-611.8" font-family="Times,serif" font-size="14.00">level 3</text>
-</g>
-<!-- block_7 -->
-<g id="node1" class="node">
-<title>block_7</title>
-<polygon fill="lightblue" stroke="lightblue" points="686,-52 618,-52 618,-16 686,-16 686,-52"/>
-<text text-anchor="middle" x="652" y="-30.3" font-family="sans-serif" font-size="14.00">block&#45;7</text>
-</g>
-<!-- block_6 -->
-<g id="node2" class="node">
-<title>block_6</title>
-<polygon fill="lightblue" stroke="lightblue" points="600,-52 532,-52 532,-16 600,-16 600,-52"/>
-<text text-anchor="middle" x="566" y="-30.3" font-family="sans-serif" font-size="14.00">block&#45;6</text>
-</g>
-<!-- block_5 -->
-<g id="node3" class="node">
-<title>block_5</title>
-<polygon fill="lightblue" stroke="lightblue" points="514,-52 446,-52 446,-16 514,-16 514,-52"/>
-<text text-anchor="middle" x="480" y="-30.3" font-family="sans-serif" font-size="14.00">block&#45;5</text>
-</g>
-<!-- block_4 -->
-<g id="node4" class="node">
-<title>block_4</title>
-<polygon fill="lightblue" stroke="lightblue" points="428,-52 360,-52 360,-16 428,-16 428,-52"/>
-<text text-anchor="middle" x="394" y="-30.3" font-family="sans-serif" font-size="14.00">block&#45;4</text>
-</g>
-<!-- block_3 -->
-<g id="node5" class="node">
-<title>block_3</title>
-<polygon fill="lightblue" stroke="lightblue" points="342,-52 274,-52 274,-16 342,-16 342,-52"/>
-<text text-anchor="middle" x="308" y="-30.3" font-family="sans-serif" font-size="14.00">block&#45;3</text>
-</g>
-<!-- block_2 -->
-<g id="node6" class="node">
-<title>block_2</title>
-<polygon fill="lightblue" stroke="lightblue" points="256,-52 188,-52 188,-16 256,-16 256,-52"/>
-<text text-anchor="middle" x="222" y="-30.3" font-family="sans-serif" font-size="14.00">block&#45;2</text>
-</g>
-<!-- block_1 -->
-<g id="node7" class="node">
-<title>block_1</title>
-<polygon fill="lightblue" stroke="lightblue" points="170,-52 102,-52 102,-16 170,-16 170,-52"/>
-<text text-anchor="middle" x="136" y="-30.3" font-family="sans-serif" font-size="14.00">block&#45;1</text>
-</g>
-<!-- block_0 -->
-<g id="node8" class="node">
-<title>block_0</title>
-<polygon fill="lightblue" stroke="lightblue" points="84,-52 16,-52 16,-16 84,-16 84,-52"/>
-<text text-anchor="middle" x="50" y="-30.3" font-family="sans-serif" font-size="14.00">block&#45;0</text>
-</g>
-<!-- rk_0_7 -->
-<g id="node9" class="node">
-<title>rk_0_7</title>
-<polygon fill="yellow" stroke="yellow" points="614,-88.5 614,-124.5 668,-124.5 668,-88.5 614,-88.5"/>
-<text text-anchor="middle" x="627" y="-102.8" font-family="sans-serif" font-size="14.00">r</text>
-<polyline fill="none" stroke="yellow" points="640,-88.5 640,-124.5 "/>
-<text text-anchor="middle" x="654" y="-102.8" font-family="sans-serif" font-size="14.00">k</text>
-</g>
-<!-- rk_0_7&#45;&gt;block_7 -->
-<g id="edge8" class="edge">
-<title>rk_0_7&#45;&gt;block_7</title>
-<path fill="none" stroke="black" stroke-dasharray="1,5" d="M643.66,-88.43C644.87,-80.67 646.34,-71.28 647.7,-62.56"/>
-<polygon fill="black" stroke="black" points="651.2,-62.82 649.29,-52.4 644.29,-61.74 651.2,-62.82"/>
-</g>
-<!-- rk_0_6 -->
-<g id="node10" class="node">
-<title>rk_0_6</title>
-<polygon fill="yellow" stroke="yellow" points="529,-88.5 529,-124.5 583,-124.5 583,-88.5 529,-88.5"/>
-<text text-anchor="middle" x="542" y="-102.8" font-family="sans-serif" font-size="14.00">r</text>
-<polyline fill="none" stroke="yellow" points="555,-88.5 555,-124.5 "/>
-<text text-anchor="middle" x="569" y="-102.8" font-family="sans-serif" font-size="14.00">k</text>
-</g>
-<!-- rk_0_6&#45;&gt;block_6 -->
-<g id="edge7" class="edge">
-<title>rk_0_6&#45;&gt;block_6</title>
-<path fill="none" stroke="black" stroke-dasharray="1,5" d="M558.42,-88.43C559.52,-80.67 560.85,-71.28 562.09,-62.56"/>
-<polygon fill="black" stroke="black" points="565.59,-62.79 563.53,-52.4 558.66,-61.81 565.59,-62.79"/>
-</g>
-<!-- rk_0_5 -->
-<g id="node11" class="node">
-<title>rk_0_5</title>
-<polygon fill="yellow" stroke="yellow" points="445,-88.5 445,-124.5 499,-124.5 499,-88.5 445,-88.5"/>
-<text text-anchor="middle" x="458" y="-102.8" font-family="sans-serif" font-size="14.00">r</text>
-<polyline fill="none" stroke="yellow" points="471,-88.5 471,-124.5 "/>
-<text text-anchor="middle" x="485" y="-102.8" font-family="sans-serif" font-size="14.00">k</text>
-</g>
-<!-- rk_0_5&#45;&gt;block_5 -->
-<g id="edge6" class="edge">
-<title>rk_0_5&#45;&gt;block_5</title>
-<path fill="none" stroke="black" stroke-dasharray="1,5" d="M473.94,-88.43C474.82,-80.67 475.88,-71.28 476.87,-62.56"/>
-<polygon fill="black" stroke="black" points="480.38,-62.73 478.03,-52.4 473.42,-61.94 480.38,-62.73"/>
-</g>
-<!-- rk_0_4 -->
-<g id="node12" class="node">
-<title>rk_0_4</title>
-<polygon fill="yellow" stroke="yellow" points="363,-88.5 363,-124.5 417,-124.5 417,-88.5 363,-88.5"/>
-<text text-anchor="middle" x="376" y="-102.8" font-family="sans-serif" font-size="14.00">r</text>
-<polyline fill="none" stroke="yellow" points="389,-88.5 389,-124.5 "/>
-<text text-anchor="middle" x="403" y="-102.8" font-family="sans-serif" font-size="14.00">k</text>
-</g>
-<!-- rk_0_4&#45;&gt;block_4 -->
-<g id="edge5" class="edge">
-<title>rk_0_4&#45;&gt;block_4</title>
-<path fill="none" stroke="black" stroke-dasharray="1,5" d="M390.97,-88.43C391.41,-80.67 391.94,-71.28 392.44,-62.56"/>
-<polygon fill="black" stroke="black" points="395.94,-62.58 393.01,-52.4 388.95,-62.18 395.94,-62.58"/>
-</g>
-<!-- rk_0_3 -->
-<g id="node13" class="node">
-<title>rk_0_3</title>
-<polygon fill="yellow" stroke="yellow" points="284,-88.5 284,-124.5 338,-124.5 338,-88.5 284,-88.5"/>
-<text text-anchor="middle" x="297" y="-102.8" font-family="sans-serif" font-size="14.00">r</text>
-<polyline fill="none" stroke="yellow" points="310,-88.5 310,-124.5 "/>
-<text text-anchor="middle" x="324" y="-102.8" font-family="sans-serif" font-size="14.00">k</text>
-</g>
-<!-- rk_0_3&#45;&gt;block_3 -->
-<g id="edge4" class="edge">
-<title>rk_0_3&#45;&gt;block_3</title>
-<path fill="none" stroke="black" stroke-dasharray="1,5" d="M310.27,-88.43C309.94,-80.67 309.54,-71.28 309.17,-62.56"/>
-<polygon fill="black" stroke="black" points="312.66,-62.24 308.74,-52.4 305.67,-62.54 312.66,-62.24"/>
-</g>
-<!-- rk_0_2 -->
-<g id="node14" class="node">
-<title>rk_0_2</title>
-<polygon fill="yellow" stroke="yellow" points="203,-88.5 203,-124.5 257,-124.5 257,-88.5 203,-88.5"/>
-<text text-anchor="middle" x="216" y="-102.8" font-family="sans-serif" font-size="14.00">r</text>
-<polyline fill="none" stroke="yellow" points="229,-88.5 229,-124.5 "/>
-<text text-anchor="middle" x="243" y="-102.8" font-family="sans-serif" font-size="14.00">k</text>
-</g>
-<!-- rk_0_2&#45;&gt;block_2 -->
-<g id="edge3" class="edge">
-<title>rk_0_2&#45;&gt;block_2</title>
-<path fill="none" stroke="black" stroke-dasharray="1,5" d="M228.06,-88.43C227.18,-80.67 226.12,-71.28 225.13,-62.56"/>
-<polygon fill="black" stroke="black" points="228.58,-61.94 223.97,-52.4 221.62,-62.73 228.58,-61.94"/>
-</g>
-<!-- rk_0_1 -->
-<g id="node15" class="node">
-<title>rk_0_1</title>
-<polygon fill="yellow" stroke="yellow" points="120,-88.5 120,-124.5 174,-124.5 174,-88.5 120,-88.5"/>
-<text text-anchor="middle" x="133" y="-102.8" font-family="sans-serif" font-size="14.00">r</text>
-<polyline fill="none" stroke="yellow" points="146,-88.5 146,-124.5 "/>
-<text text-anchor="middle" x="160" y="-102.8" font-family="sans-serif" font-size="14.00">k</text>
-</g>
-<!-- rk_0_1&#45;&gt;block_1 -->
-<g id="edge2" class="edge">
-<title>rk_0_1&#45;&gt;block_1</title>
-<path fill="none" stroke="black" stroke-dasharray="1,5" d="M144.34,-88.43C143.13,-80.67 141.66,-71.28 140.3,-62.56"/>
-<polygon fill="black" stroke="black" points="143.71,-61.74 138.71,-52.4 136.8,-62.82 143.71,-61.74"/>
-</g>
-<!-- rk_0_0 -->
-<g id="node16" class="node">
-<title>rk_0_0</title>
-<polygon fill="yellow" stroke="yellow" points="30,-88.5 30,-124.5 84,-124.5 84,-88.5 30,-88.5"/>
-<text text-anchor="middle" x="43" y="-102.8" font-family="sans-serif" font-size="14.00">r</text>
-<polyline fill="none" stroke="yellow" points="56,-88.5 56,-124.5 "/>
-<text text-anchor="middle" x="70" y="-102.8" font-family="sans-serif" font-size="14.00">k</text>
-</g>
-<!-- rk_0_0&#45;&gt;block_0 -->
-<g id="edge1" class="edge">
-<title>rk_0_0&#45;&gt;block_0</title>
-<path fill="none" stroke="black" stroke-dasharray="1,5" d="M55.31,-88.43C54.53,-80.67 53.6,-71.28 52.74,-62.56"/>
-<polygon fill="black" stroke="black" points="56.2,-62 51.73,-52.4 49.23,-62.7 56.2,-62"/>
-</g>
-<!-- node_1_0 -->
-<g id="node17" class="node">
-<title>node_1_0</title>
-<polygon fill="lightblue" stroke="lightblue" points="215,-172.5 215,-208.5 269,-208.5 269,-172.5 215,-172.5"/>
-<text text-anchor="middle" x="242" y="-186.8" font-family="sans-serif" font-size="14.00">node</text>
-</g>
-<!-- node_1_0&#45;&gt;rk_0_1 -->
-<g id="edge10" class="edge">
-<title>node_1_0&#45;&gt;rk_0_1</title>
-<path fill="none" stroke="black" d="M215.66,-172.47C208.43,-167.44 200.73,-161.73 194,-156 185.56,-148.82 176.95,-140.33 169.44,-132.48"/>
-<polygon fill="black" stroke="black" points="171.74,-129.81 162.35,-124.91 166.63,-134.6 171.74,-129.81"/>
-</g>
-<!-- node_1_0&#45;&gt;rk_0_0 -->
-<g id="edge9" class="edge">
-<title>node_1_0&#45;&gt;rk_0_0</title>
-<path fill="none" stroke="black" d="M214.78,-186.41C187.28,-182.42 144.22,-173.77 111,-156 99.37,-149.78 88.22,-140.54 79.1,-131.78"/>
-<polygon fill="black" stroke="black" points="81.5,-129.23 71.96,-124.62 76.54,-134.17 81.5,-129.23"/>
-</g>
-<!-- node_1_1 -->
-<g id="node18" class="node">
-<title>node_1_1</title>
-<polygon fill="lightblue" stroke="lightblue" points="287,-172.5 287,-208.5 341,-208.5 341,-172.5 287,-172.5"/>
-<text text-anchor="middle" x="314" y="-186.8" font-family="sans-serif" font-size="14.00">node</text>
-</g>
-<!-- node_1_1&#45;&gt;rk_0_3 -->
-<g id="edge12" class="edge">
-<title>node_1_1&#45;&gt;rk_0_3</title>
-<path fill="none" stroke="black" d="M313.36,-172.11C312.97,-161.27 312.45,-147.1 312,-134.79"/>
-<polygon fill="black" stroke="black" points="315.49,-134.45 311.63,-124.58 308.49,-134.71 315.49,-134.45"/>
-</g>
-<!-- node_1_1&#45;&gt;rk_0_2 -->
-<g id="edge11" class="edge">
-<title>node_1_1&#45;&gt;rk_0_2</title>
-<path fill="none" stroke="black" d="M292.97,-172.19C287.04,-167.11 280.66,-161.45 275,-156 267.18,-148.47 259,-139.89 251.79,-132.07"/>
-<polygon fill="black" stroke="black" points="254.28,-129.6 244.96,-124.55 249.1,-134.31 254.28,-129.6"/>
-</g>
-<!-- node_1_2 -->
-<g id="node19" class="node">
-<title>node_1_2</title>
-<polygon fill="lightblue" stroke="lightblue" points="359,-172.5 359,-208.5 413,-208.5 413,-172.5 359,-172.5"/>
-<text text-anchor="middle" x="386" y="-186.8" font-family="sans-serif" font-size="14.00">node</text>
-</g>
-<!-- node_1_2&#45;&gt;rk_0_5 -->
-<g id="edge14" class="edge">
-<title>node_1_2&#45;&gt;rk_0_5</title>
-<path fill="none" stroke="black" d="M407.57,-172.21C413.65,-167.12 420.19,-161.46 426,-156 433.99,-148.49 442.35,-139.91 449.72,-132.08"/>
-<polygon fill="black" stroke="black" points="452.46,-134.28 456.7,-124.57 447.33,-129.51 452.46,-134.28"/>
-</g>
-<!-- node_1_2&#45;&gt;rk_0_4 -->
-<g id="edge13" class="edge">
-<title>node_1_2&#45;&gt;rk_0_4</title>
-<path fill="none" stroke="black" d="M386.85,-172.11C387.38,-161.27 388.07,-147.1 388.67,-134.79"/>
-<polygon fill="black" stroke="black" points="392.18,-134.74 389.17,-124.58 385.18,-134.4 392.18,-134.74"/>
-</g>
-<!-- node_1_3 -->
-<g id="node20" class="node">
-<title>node_1_3</title>
-<polygon fill="lightblue" stroke="lightblue" points="431,-172.5 431,-208.5 485,-208.5 485,-172.5 431,-172.5"/>
-<text text-anchor="middle" x="458" y="-186.8" font-family="sans-serif" font-size="14.00">node</text>
-</g>
-<!-- node_1_3&#45;&gt;rk_0_7 -->
-<g id="edge16" class="edge">
-<title>node_1_3&#45;&gt;rk_0_7</title>
-<path fill="none" stroke="black" d="M485.24,-186.97C513.48,-183.41 558.15,-175.05 592,-156 602.7,-149.98 612.7,-140.99 620.83,-132.39"/>
-<polygon fill="black" stroke="black" points="623.67,-134.47 627.74,-124.69 618.46,-129.79 623.67,-134.47"/>
-</g>
-<!-- node_1_3&#45;&gt;rk_0_6 -->
-<g id="edge15" class="edge">
-<title>node_1_3&#45;&gt;rk_0_6</title>
-<path fill="none" stroke="black" d="M485.18,-172.72C492.79,-167.64 500.91,-161.86 508,-156 516.77,-148.76 525.71,-140.13 533.46,-132.17"/>
-<polygon fill="black" stroke="black" points="536.4,-134.16 540.77,-124.51 531.33,-129.33 536.4,-134.16"/>
-</g>
-<!-- rk_1_3 -->
-<g id="node21" class="node">
-<title>rk_1_3</title>
-<polygon fill="yellow" stroke="yellow" points="431,-245.5 431,-281.5 485,-281.5 485,-245.5 431,-245.5"/>
-<text text-anchor="middle" x="444" y="-259.8" font-family="sans-serif" font-size="14.00">r</text>
-<polyline fill="none" stroke="yellow" points="457,-245.5 457,-281.5 "/>
-<text text-anchor="middle" x="471" y="-259.8" font-family="sans-serif" font-size="14.00">k</text>
-</g>
-<!-- rk_1_3&#45;&gt;node_1_3 -->
-<g id="edge20" class="edge">
-<title>rk_1_3&#45;&gt;node_1_3</title>
-<path fill="none" stroke="black" stroke-dasharray="1,5" d="M458,-245.31C458,-237.29 458,-227.55 458,-218.57"/>
-<polygon fill="black" stroke="black" points="461.5,-218.53 458,-208.53 454.5,-218.53 461.5,-218.53"/>
-</g>
-<!-- rk_1_2 -->
-<g id="node22" class="node">
-<title>rk_1_2</title>
-<polygon fill="yellow" stroke="yellow" points="359,-245.5 359,-281.5 413,-281.5 413,-245.5 359,-245.5"/>
-<text text-anchor="middle" x="372" y="-259.8" font-family="sans-serif" font-size="14.00">r</text>
-<polyline fill="none" stroke="yellow" points="385,-245.5 385,-281.5 "/>
-<text text-anchor="middle" x="399" y="-259.8" font-family="sans-serif" font-size="14.00">k</text>
-</g>
-<!-- rk_1_2&#45;&gt;node_1_2 -->
-<g id="edge19" class="edge">
-<title>rk_1_2&#45;&gt;node_1_2</title>
-<path fill="none" stroke="black" stroke-dasharray="1,5" d="M386,-245.31C386,-237.29 386,-227.55 386,-218.57"/>
-<polygon fill="black" stroke="black" points="389.5,-218.53 386,-208.53 382.5,-218.53 389.5,-218.53"/>
-</g>
-<!-- rk_1_1 -->
-<g id="node23" class="node">
-<title>rk_1_1</title>
-<polygon fill="yellow" stroke="yellow" points="287,-245.5 287,-281.5 341,-281.5 341,-245.5 287,-245.5"/>
-<text text-anchor="middle" x="300" y="-259.8" font-family="sans-serif" font-size="14.00">r</text>
-<polyline fill="none" stroke="yellow" points="313,-245.5 313,-281.5 "/>
-<text text-anchor="middle" x="327" y="-259.8" font-family="sans-serif" font-size="14.00">k</text>
-</g>
-<!-- rk_1_1&#45;&gt;node_1_1 -->
-<g id="edge18" class="edge">
-<title>rk_1_1&#45;&gt;node_1_1</title>
-<path fill="none" stroke="black" stroke-dasharray="1,5" d="M314,-245.31C314,-237.29 314,-227.55 314,-218.57"/>
-<polygon fill="black" stroke="black" points="317.5,-218.53 314,-208.53 310.5,-218.53 317.5,-218.53"/>
-</g>
-<!-- rk_1_0 -->
-<g id="node24" class="node">
-<title>rk_1_0</title>
-<polygon fill="yellow" stroke="yellow" points="215,-245.5 215,-281.5 269,-281.5 269,-245.5 215,-245.5"/>
-<text text-anchor="middle" x="228" y="-259.8" font-family="sans-serif" font-size="14.00">r</text>
-<polyline fill="none" stroke="yellow" points="241,-245.5 241,-281.5 "/>
-<text text-anchor="middle" x="255" y="-259.8" font-family="sans-serif" font-size="14.00">k</text>
-</g>
-<!-- rk_1_0&#45;&gt;node_1_0 -->
-<g id="edge17" class="edge">
-<title>rk_1_0&#45;&gt;node_1_0</title>
-<path fill="none" stroke="black" stroke-dasharray="1,5" d="M242,-245.31C242,-237.29 242,-227.55 242,-218.57"/>
-<polygon fill="black" stroke="black" points="245.5,-218.53 242,-208.53 238.5,-218.53 245.5,-218.53"/>
-</g>
-<!-- node_2_1 -->
-<g id="node25" class="node">
-<title>node_2_1</title>
-<polygon fill="lightblue" stroke="lightblue" points="359,-329.5 359,-365.5 413,-365.5 413,-329.5 359,-329.5"/>
-<text text-anchor="middle" x="386" y="-343.8" font-family="sans-serif" font-size="14.00">node</text>
-</g>
-<!-- node_2_1&#45;&gt;rk_1_3 -->
-<g id="edge24" class="edge">
-<title>node_2_1&#45;&gt;rk_1_3</title>
-<path fill="none" stroke="black" d="M405.69,-329.39C411.17,-324.31 416.99,-318.6 422,-313 428.33,-305.92 434.69,-297.78 440.26,-290.22"/>
-<polygon fill="black" stroke="black" points="443.39,-291.86 446.39,-281.7 437.71,-287.77 443.39,-291.86"/>
-</g>
-<!-- node_2_1&#45;&gt;rk_1_2 -->
-<g id="edge23" class="edge">
-<title>node_2_1&#45;&gt;rk_1_2</title>
-<path fill="none" stroke="black" d="M386,-329.11C386,-318.27 386,-304.1 386,-291.79"/>
-<polygon fill="black" stroke="black" points="389.5,-291.58 386,-281.58 382.5,-291.58 389.5,-291.58"/>
-</g>
-<!-- node_2_0 -->
-<g id="node26" class="node">
-<title>node_2_0</title>
-<polygon fill="lightblue" stroke="lightblue" points="287,-329.5 287,-365.5 341,-365.5 341,-329.5 287,-329.5"/>
-<text text-anchor="middle" x="314" y="-343.8" font-family="sans-serif" font-size="14.00">node</text>
-</g>
-<!-- node_2_0&#45;&gt;rk_1_1 -->
-<g id="edge22" class="edge">
-<title>node_2_0&#45;&gt;rk_1_1</title>
-<path fill="none" stroke="black" d="M314,-329.11C314,-318.27 314,-304.1 314,-291.79"/>
-<polygon fill="black" stroke="black" points="317.5,-291.58 314,-281.58 310.5,-291.58 317.5,-291.58"/>
-</g>
-<!-- node_2_0&#45;&gt;rk_1_0 -->
-<g id="edge21" class="edge">
-<title>node_2_0&#45;&gt;rk_1_0</title>
-<path fill="none" stroke="black" d="M294.31,-329.39C288.83,-324.31 283.01,-318.6 278,-313 271.67,-305.92 265.31,-297.78 259.74,-290.22"/>
-<polygon fill="black" stroke="black" points="262.29,-287.77 253.61,-281.7 256.61,-291.86 262.29,-287.77"/>
-</g>
-<!-- rk_2_1 -->
-<g id="node27" class="node">
-<title>rk_2_1</title>
-<polygon fill="yellow" stroke="yellow" points="359,-402.5 359,-438.5 413,-438.5 413,-402.5 359,-402.5"/>
-<text text-anchor="middle" x="372" y="-416.8" font-family="sans-serif" font-size="14.00">r</text>
-<polyline fill="none" stroke="yellow" points="385,-402.5 385,-438.5 "/>
-<text text-anchor="middle" x="399" y="-416.8" font-family="sans-serif" font-size="14.00">k</text>
-</g>
-<!-- rk_2_1&#45;&gt;node_2_1 -->
-<g id="edge26" class="edge">
-<title>rk_2_1&#45;&gt;node_2_1</title>
-<path fill="none" stroke="black" stroke-dasharray="1,5" d="M386,-402.31C386,-394.29 386,-384.55 386,-375.57"/>
-<polygon fill="black" stroke="black" points="389.5,-375.53 386,-365.53 382.5,-375.53 389.5,-375.53"/>
-</g>
-<!-- rk_2_0 -->
-<g id="node28" class="node">
-<title>rk_2_0</title>
-<polygon fill="yellow" stroke="yellow" points="287,-402.5 287,-438.5 341,-438.5 341,-402.5 287,-402.5"/>
-<text text-anchor="middle" x="300" y="-416.8" font-family="sans-serif" font-size="14.00">r</text>
-<polyline fill="none" stroke="yellow" points="313,-402.5 313,-438.5 "/>
-<text text-anchor="middle" x="327" y="-416.8" font-family="sans-serif" font-size="14.00">k</text>
-</g>
-<!-- rk_2_0&#45;&gt;node_2_0 -->
-<g id="edge25" class="edge">
-<title>rk_2_0&#45;&gt;node_2_0</title>
-<path fill="none" stroke="black" stroke-dasharray="1,5" d="M314,-402.31C314,-394.29 314,-384.55 314,-375.57"/>
-<polygon fill="black" stroke="black" points="317.5,-375.53 314,-365.53 310.5,-375.53 317.5,-375.53"/>
-</g>
-<!-- node_3_0 -->
-<g id="node29" class="node">
-<title>node_3_0</title>
-<polygon fill="lightblue" stroke="lightblue" points="323,-486.5 323,-522.5 377,-522.5 377,-486.5 323,-486.5"/>
-<text text-anchor="middle" x="350" y="-500.8" font-family="sans-serif" font-size="14.00">node</text>
-</g>
-<!-- node_3_0&#45;&gt;rk_2_1 -->
-<g id="edge27" class="edge">
-<title>node_3_0&#45;&gt;rk_2_1</title>
-<path fill="none" stroke="black" d="M357.63,-486.11C362.49,-475.06 368.87,-460.53 374.34,-448.05"/>
-<polygon fill="black" stroke="black" points="377.68,-449.15 378.5,-438.58 371.28,-446.33 377.68,-449.15"/>
-</g>
-<!-- node_3_0&#45;&gt;rk_2_0 -->
-<g id="edge28" class="edge">
-<title>node_3_0&#45;&gt;rk_2_0</title>
-<path fill="none" stroke="black" d="M342.37,-486.11C337.51,-475.06 331.13,-460.53 325.66,-448.05"/>
-<polygon fill="black" stroke="black" points="328.72,-446.33 321.5,-438.58 322.32,-449.15 328.72,-446.33"/>
-</g>
-<!-- rk_3_0 -->
-<g id="node30" class="node">
-<title>rk_3_0</title>
-<polygon fill="yellow" stroke="yellow" points="323,-559.5 323,-595.5 377,-595.5 377,-559.5 323,-559.5"/>
-<text text-anchor="middle" x="336" y="-573.8" font-family="sans-serif" font-size="14.00">r</text>
-<polyline fill="none" stroke="yellow" points="349,-559.5 349,-595.5 "/>
-<text text-anchor="middle" x="363" y="-573.8" font-family="sans-serif" font-size="14.00">k</text>
-</g>
-<!-- rk_3_0&#45;&gt;node_3_0 -->
-<g id="edge29" class="edge">
-<title>rk_3_0&#45;&gt;node_3_0</title>
-<path fill="none" stroke="black" stroke-dasharray="1,5" d="M350,-559.31C350,-551.29 350,-541.55 350,-532.57"/>
-<polygon fill="black" stroke="black" points="353.5,-532.53 350,-522.53 346.5,-532.53 353.5,-532.53"/>
-</g>
-</g>
-</svg>
diff --git a/doc/eris.adoc b/doc/eris.adoc
deleted file mode 100644
index 2f7d46a..0000000
--- a/doc/eris.adoc
+++ /dev/null
@@ -1,567 +0,0 @@
-= Encoding for Robust Immutable Storage (ERIS)
-pukkamustard <pukkamustard@posteo.net>
-0.3.0-draft
-:toc: left
-:xrefstyle: short
-:sectnums:
-:sectanchors:
-
-[abstract]
-This document describes the Encoding for Robust Immutable Storage (ERIS). ERIS is an encoding of arbitrary content into a set of uniformly sized, encrypted and content-addressed blocks as well as a short identifier (a URN). The content can be reassembled from the encrypted blocks only with this identifier. The encoding is defined independent of any storage and transport layer or any specific application. We illustrate how ERIS can be used as a building block for robust and decentralized applications.
-
-== Introduction
-
-Unavailability of content on computer networks is a major cause for reduced reliability of networked services <<Polleres2020>>.
-
-Availability can be increased by caching content on multiple peers. However most content on the Internet is identified by its location. Caching location-addressed content is complicated as the content receives a new location.
-
-An alternative to identifying content by its location is to identify content by its content itself. This is called content-addressing. The hash of some content is computed and used as an unique identifier for the content.
-
-Caching content-addressed content and making it available redundantly is much easier as the content is completely decoupled from any physical location. Integrity of content is automatically ensured with content-addressing (when using a cryptographic hash) as the identifier of the content can be computed to check that the content matches the requested identifier.
-
-However, naive content-addressing has certain drawbacks:
-
-- Large content is stored as a large chunk of data. In order to optimize storage and network operations it is better to split up content into smaller uniformly sized blocks and reassemble blocks when needed.
-- Confidentiality: Content is readable by all peers involved in transporting, caching and storing content.
-
-ERIS addresses these issues by splitting content into small uniformly sized and encrypted blocks. These blocks can be reassembled to the original content only with access to a short _read capability_, which can be encoded as an URN.
-
-Encodings similar to ERIS are already widely-used in applications and protocols such as GNUNet (see <<_previous_work>>), BitTorrent <<BEP52>>, Freenet <<Freenet>> and others. However, they all use slightly different encodings that are tied to the respective protocols and applications. ERIS defines an encoding independant of any specific protocol or application and decouples content from transport and storage layers. ERIS may be seen as a modest step towards Information-Centric Networking <<RFC7927>>.
-
-=== Objectives
-
-The objectives of ERIS are:
-
-Availability :: Content encoded with ERIS can be easily replicated and cached.
-Integrity :: Integrity of content can be verified efficiently.
-Confidentiality :: Encoded content can only be decoded with access to the read capability. Peers without access to the read capability can cache and transport individiual blocks without being able to read the content.
-URN reference :: ERIS encoded content can be referrenced with a single URN (the encoded read capability).
-Storage efficiency :: ERIS can be used to encode small content (< 1 kibibyte) as well as large content (> many gibibyte) with reasonable storage overhead.
-Simplicity :: The encoding should be as simple as possible in order to allow correct implementation on various platforms and in various languages.
-
-ERIS can be used to make content available robustly (against network failure or active censorship). ERIS is not suitable for encoding private, end-to-end encrypted communication. The encoding does not provide security properties required for such applications (e.g. forward secrecy). For end-to-end encryption see protocols such as https://otr.im/[OTR], OMEMO <<OMEMO>> or MLS <<MLS>> .
-
-=== Scope
-
-ERIS describes how arbitrary content (sequence of bytes) can be encoded into a set of uniformly sized blocks and an identifier with which the content can be decoded from the set of blocks.
-
-ERIS does not prescribe how the blocks should be stored or transported over network. The only requirement is that a block can be referenced and accessed (if available) by the hash value of the contents of the block. In section <<_storage_and_transport_layers>> we show how existing technology (including IPFS) can be used to store and transport blocks.
-
-There is also no support for grouping content or mutating content. In section <<_mutability_and_namespaces>> we describe how such functionality can be implemented on top of ERIS.
-
-The lack of certain functionalities is intentional. ERIS is an attempt to find a minimal common basis on which higher functionality can be built. Lacking functionality in ERIS is an acknowledgment that there are many ways of implementing such functionality at a different layer that may be optimized for certain use-cases.
-
-=== Previous work
-
-ERIS is inspired and based on the encoding used in the file-sharing application of https://gnunet.org/[GNUNet] - Encoding for Censorship-Resistant Sharing (ECRS) <<ECRS>>.
-
-ERIS differs from ECRS in following points:
-
-Cryptographic primitives :: ECRS itself does not specify any cryptographic primitives but the GNUNet implementation uses the SHA-512 hash and AES cipher. ERIS uses the Blake2b-256 cryptographic hash <<RFC7693>> and the ChaCha20 stream cipher <<RFC8439>>. This improves performance, storage efficiency (as hash references are smaller) and allows a convergence secret to be used (via Blake2b keyed hashing; see <<_convergence_secret>>).
-Block size :: ECRS uses a fixed block size of 32 KiB. This can be very inefficient when encoding many small pieces of content. ERIS allows a block size of 1 KiB or 32 KiB, allowing efficient encoding of small and large content (see <<_block_size>>).
-URN :: ECRS does not specify an URN for referring to encoded content (this is specified as part of the GNUNet file-sharing application). ERIS specifies an URN for encoded content regardless of encoding application or storage and transport layer (see <<_urn>>).
-Namespaces :: ECRS defines two mechanisms for grouping and discovering encoded content (SBlock and KBlock). ERIS does not specify any such mechanisms (see <<_mutability_and_namespaces>>).
-
-Other related projects include Tahoe-LAFS and Freenet. The reader is referred to the ECRS paper <<ECRS>> for an in-depth explanation and comparison of related projects.
-
-ERIS is being developed in close collaboration with the https://datashards.net/[Datashards] initiative.
-
-=== Terminology
-
-The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 <<RFC2119>>.
-
-We use binary prefixes for multiples of bytes, i.e: 1024 bytes is 1 kibibyte (KiB), 1024 kibibytes is 1 mebibyte (MiB) and 1024 mebibytes is 1 gigibytes (GiB).
-
-== Specification of ERIS
-
-=== Cryptographic Primitives
-
-The cryptographic primitives used by ERIS are a cryptographic hash funciton, a symmetric key cipher and a padding algorithm. The hash function and cipher are readily available in open-source libraries such as https://github.com/jedisct1/libsodium[libsodium] or https://monocypher.org/[Monocypher]. The padding algorithm can be implemented with reasonable effort.
-
-==== Cryptographic Hash Function
-
-Blake2b <<RFC7693>> with output size of 256 bit (32 byte). We use the keying feature and refer to the key used for keying Blake2b as the _hashing key_. The hashing key always has a size of 256 bit (32 byte) (see <<_convergence_secret>>).
-
-Provides the functions `Blake2b-256(INPUT, HASHING-KEY)` for keyed hashing and `Blake2b-256(INPUT)` for unkeyed hashing.
-
-==== Symmetric Key Cipher
-ChaCha20 (IETF variant) <<RFC8439>>. Provides `ChaCha20(INPUT, KEY)`, where `INPUT` is an arbirtarty length byte sequence and `KEY` is the 256 bit encryption key. The output is the encrypted byte sequence.
-
-The 32 bit initial counter as well as the 96 bit nonce are set to 0. We can safely use the zero nonce as we never reuse a key.
-
-Decryption is done with the same function where `INPUT` is the encrypted byte sequence.
-
-==== Padding Algorithm
-
-We use a byte padding scheme to ensure that input content size is a multiple of a block size. Provides following functions:
-
-`PAD(INPUT,BLOCK-SIZE)` :: For `INPUT` of size `n` adds a mandatory byte valued `0x80` (hexadecimal) to `INPUT` followed by `m < BLOCK-SIZE - 1` bytes valued `0x00` such that `n + m + 1` is a multiple of `BLOCK-SIZE`.
-`UNPAD(INPUT,BLOCK-SIZE)` :: Starts reading bytes from the end of `INPUT` until a `0x80` is read and then returns bytes of `INPUT` before the `0x80`. Throws an error if a value other than `0x00` is read before reading `0x80` or if no `0x80` is read after reading `BLOCK-SIZE - 1` bytes from the end.
-
-This is the padding algorithm implemented in https://libsodium.gitbook.io/doc/padding[libsodium]footnote:[This padding algorithm is apparently also specified in ISO/IEC 7816-4. However, the speicifcation is not openly available. So, fuck you ISO.].
-
-=== Block Size
-
-ERIS uses two block sizes: 1KiB (1024 bytes) and 32KiB (32768 bytes). The block size must be specified when encoding content.
-
-Both block sizes can be used to encode content of arbitrary size. The block size of 1KiB is an optimization towards smaller content.
-
-[TODO]
-====
-TODO: Content smaller than TODO SHOULD be encoded with block size 1KiB, content larger than TODO SHOULD be encoded with block size 32KiB.
-====
-
-The block size is encoded in the read capability and the decoding process is capable of handling both cases.
-
-[NOTE]
-====
-When using block size 32KiB to encode content smaller than 1KiB, the content will be encoded in a 32KiB block. This is a storage overhead of over 3100%. When encoding very many pieces of small content (e.g. short messages or cartographic nodes) this overhead is not acceptable.
-
-On the other hand, using small block sizes increases the number of internal nodes that must be used to encode the content (see <<_collect_reference_key_pairs_in_nodes>>). When encoding larger content it is more efficient to use a block size of 32KiB.
-====
-
-
-=== Convergence Secret
-
-Using the hash of the content as key is called _convergent encryption_.
-
-Because the hash of the content is deterministically computed from the content, the key will be the same when the same content is encoded twice. This results in de-duplication of content. Convergent encryption suffers from two known attacks: The Confirmation Of A File Attack and The Learn-The-Remaining-Information Attack <<Zooko2008>>. A defense against both attacks is to use a _convergence secret_. This results in different encoding of the same content with different convergence secret.
-
-If no convergence secret is specified a null convergence secret MUST be used (32 bytes of zeroes).
-
-The convergence secret is implemented as the keying feature of the Blake2 cryptographic hash <<RFC7693>>.
-
-[NOTE]
-====
-A group using a shared convergence secret can benefit from the advantages of convergenct encryption while being safe against the known attacks from peers that do not know the convergence secret.
-====
-
-=== Encoding
-
-Inputs to the encoding process are:
-
-`CONTENT` :: An arbitary length byte sequence of content to be encoded.
-`CONVERGENCE-SECRET` :: A 256 bit (32 byte) byte sequence (see <<_convergence_secret>>).
-`BLOCK-SIZE` :: The block size used for encoding in bytes can be either 1024 (1KiB) or 32768 (32KiB) (see <<_block_size>>).
-
-Content is encoded by first splitting into uniformly sized blocks, encrypting the blocks and computing references to the blocks. If there are multiple references to blocks they are collected in nodes that have the same size as content blocks. The nodes are encrypted and references to the nodes are computed. This process is repeated until there is a single root reference.
-
-References to nodes and blocks of content consist of a reference to an encrypted block and a key to decrypt the block - a _reference-key pair_. The process of encrypting a block and computing a reference-key pair is explained in <<_encrypt_block_and_compute_reference_key_pair>>.
-
-The encoding process constructs a tree of reference-key pairs that reference nodes that hold references to nodes of a lower level or to content.
-
-The number of reference-key pairs collected into a node is called the _arity_ of the tree and depends on the block size. For block size 1KiB the arity of the tree is 16, for block size 32KiB the arity is 512.
-
-An encoding of a content that is split into eight blocks is depicted in <<figure_merkle_tree>>. For illustration purposes the tree is of arity 2 (instead of 16 or 512).
-
-[[figure_merkle_tree]]
-.Encoding of content as tree. Solid edges are concatenations of reference-key pairs as described in <<_collect_reference_key_pairs_in_nodes>>. Dotted edges are encryption and computation of reference-key pairs as described in <<_encrypt_block_and_compute_reference_key_pair>>.
-image::eris-merkle-tree.svg[Merkle Tree,opts=inline]
-
-The block size, the level of the root reference and the root reference-key pair itself are the necessary pieces of information required to decode content. The tuple consisting of block size, level, root reference and key is called the _read capability_.
-
-The encrypted blocks and the read capability are the outputs of the encoding process.
-
-A pseudo-code implementation of the encoding process is provided in the following. Note that the pseudo-code implementation is naive and given for illustration purposes only. It is RECOMMENDED that imlementations use a streaming encoding process (as described in <<_streaming>>) which allows encoding of content larger than the available memory.
-
-[source,pseudocode]
-----
-ERIS-Encode(CONTENT, CONVERGENCE-SECRET, BLOCK-SIZE):
- // initialize empty list of blocks to be output
- BLOCKS := []
-
- // initialize level to 0
- LEVEL := 0
-
- // split the input content into uniformly sized blocks and encode
- LEVEL-0-BLOCKS, RK-PAIRS := Split-Content(CONTENT, BLOCK-SIZE)
-
- // add blocks from level 0 to blocks to be output
- BLOCKS := BLOCKS ++ LEVEL-0-BLOCKS
-
- // loop until there is a single root reference
- WHILE Length(RK-PAIRS) > 1:
- LEVEL-BLOCKS, RK-Pairs := Collect-RK-Pairs(RK-PAIRS, CONVERGENCE-SECRET, BLOCK-SIZE)
-
- // add blocks to blocks to be output and increase the level counter
- BLOCKS := BLOCKS ++ LEVEL-BLOCKS
- LEVEL := LEVEL + 1
-
- // extract the root reference-key pair
- ROOT-RK-PAIR := RK-PAIRS[0]
- ROOT-REFERENCE, ROOT-KEY := ROOT-RK-PAIR
-
- // return blocks and read-capability
- RETURN BLOCKS, BLOCK-SIZE, LEVEL, ROOT-REFERENCE, ROOT-KEY
-----
-
-The sub-process `Split-Content` and `Collect-RK-Pairs` are explained in the following sections.
-
-
-==== Splitting Input Content into Blocks
-
-Input content is split into blocks of size at most block size such that only the last content block may be smaller than block size.
-
-The last content block is always padded according to the padding algorithm to block size. If the size of the padded last block is larger than block size it is split into content blocks of block size.
-
-A pseudo code implementation:
-
-[source,pseudocode]
-----
-Split-Content(CONTENT,CONVERGENCE-SECRET,BLOCK-SIZE):
- // initialize list of blocks and reference-key pairs to output
- BLOCKS := []
- RK-PAIRS := []
-
- // read blocks of size BLOCK-SIZE from CONTENT
- WHILE CONTENT-BLOCK, LAST? := READ(CONTENT, BLOCK-SIZE):
-
- IF LAST?:
- // pad block if it is the last
- PADDED := PAD(CONTENT-BLOCK, BLOCK-SIZE)
-
- IF Length(PADDED) > BLOCK-SIZE:
- PADDED-0, PADDED-1 := SPLIT(PADDED, BLOCK-SIZE)
- ENCRYPTED-BLOCK-0, RK-PAIR-0 := Encrypt-Block(PADDED-0, CONVERGENCE-SECRET)
- ENCRYPTED-BLOCK-1, RK-PAIR-1 := Encrypt-Block(PADDED-1, CONVERGENCE-SECRET)
- BLOCKS := BLOCKS ++ [ENCRYPTED-BLOCK-0, ENCRYPTED-BLOCK-1]
- RK-PAIRS := RK-PAIRS ++ [RK-PAIR-0, RK-PAIR-1]
- ELSE:
- ENCRYPTED-BLOCK, RK-PAIR := Encrypt-Block(PADDED, CONVERGENCE-SECRET)
- BLOCKS := BLOCKS ++ [ENCRYPTED-BLOCK]
- RK-PAIRS := RK-PAIRS ++ [RK-PAIR]
-
- ELSE:
- ENCRYPTED-BLOCK, RK-PAIR := Encrypt-Block(CONTENT-BLOCK, CONVERGENCE-SECRET)
- BLOCKS := BLOCKS ++ [ENCRYPTED-BLOCK]
- RK-PAIRS := RK-PAIRS ++ [RK-PAIR]
-
- RETURN BLOCKS, RK-PAIRS
-----
-
-NOTE: If the length of the last content block is exactly block size, then padding will result in a padded block that is double the block size and must be split.
-
-==== Encrypt Block and Compute Reference-Key Pair
-
-A _reference-key pair_ is a pair consisting of a reference to an encrypted block and the key to decrypt the block. Reference and key are both 32 bytes long. The concatenation of a reference-key pair is 64 bytes long (512 bits).
-
-The `Encrypt-Block` function encrypts a block and returns the encrypted block along with the reference-key pair:
-
-[source,pseudocode]
-----
-Encrypt-Block(INPUT, CONVERGENCE-SECRET):
- KEY := Blake2b-256(INPUT,CONVERGENCE-SECRET)
- ENCRYPTED-BLOCK := ChaCha20(INPUT,KEY)
- REFERENCE := Blake2b-256(ENCRYPTED-BLOCK)
- RETURN ENCRYPTED-BLOCK, REFERENCE, KEY
-----
-
-The convergence-secret MUST NOT be used to compute the reference to the encrypted block.
-
-==== Collect Reference-Key Pairs in Nodes
-
-Reference-key pairs are collected into nodes of size block size by concatenating reference-key pair. The node is encrypted, and a reference-key pair to the node is computed. This results in a sequence of reference-key pairs that refer to nodes containing reference-key pairs at a lower level - a tree.
-
-If there are less than arity number of references-key pairs to collect in a node, then the node is filled with missing number of _null reference-key pairs_ - 64 bytes of zeros. The size of a node is always equal the block size (implemented with the `FILL-WITH-NULL-RK-PAIRS` function).
-
-A pseudo-code implementation of `Collect-RK-Pairs`:
-
-[source,pseudocode]
-----
-Collect-RK-Pairs(INPUT-RK-PAIRS, CONVERGENCE-SECRET, BLOCK-SIZE):
- // number of reference-key pairs in a node
- ARITY := BLOCK-SIZE / 64
-
- // initialize blocks and reference-key pairs to output
- BLOCKS := []
- OUTPUT-RK-PAIRS := []
-
- // take ARITY reference-key pairs from INPUT-RK-PAIRS at a time
- WHILE RK-PAIRS-FOR-NODE := TAKE(INPUT-RK-PAIRS, ARITY):
- // make sure there are exactly ARITY reference-key pairs in node
- RK-PAIRS-FOR-NODE := FILL-WITH-NULL-RK-PAIRS(RK-PAIRS-FOR-NODE, ARITY)
-
- // concat reference-key pairs to node
- NODE := CONCAT(RK-PAIRS-FOR-NODE)
-
- // encrypt node and compute reference-key pair
- BLOCK, RK-TO-NODE := Encrypt-Block(NODE, CONVERGENCE-SECRET)
-
- // add node to output
- BLOCKS := BLOCKS ++ [BLOCK]
- OUTPUT-RK-PAIRS := OUTPUT-RK-PAIRS ++ [RK-TO-NODE]
-
- RETURN BLOCKS, OUTPUT-RK-PAIRS
-----
-
-==== Streaming
-
-The encoding process can be implemented to encode a stream of content while immediately outputting encrypted blocks when ready and eagerly collecting reference-key pairs to nodes. This allows the encoding of larger-than-memory content.
-
-For an example, see https://gitlab.com/openengiadina/eris/-/raw/main/eris/encode.scm[the reference Guile implementation].
-
-=== Decoding
-
-Given an ERIS read capability and access to blocks via a block-storage the content can be decoded.
-
-[source, pseudocode]
-----
-ERIS-Decode-Recurse(LEVEL, REFERENCE, KEY):
- IF LEVEL == 0:
- ENCRYPTED-CONTENT-BLOCK := Block-Storage-Get(REFERENCE)
- RETURN ChaCha20(CONTENT-BLOCK, KEY)
- ELSE:
- ENCRYPTED-NODE := Block-Storage-Get(REFERENCE)
- NODE := ChaCha20(ENCRYPTED, KEY)
- OUTPUT := []
- WHILE SUB-REFERENCE, SUB-KEY := Read-RK-Pair-From-Node(NODE):
- OUTPUT := OUTPUT ++ [ERIS-DECODE-Recurse(LEVEL - 1, SUB-REFERENCE, SUB-KEY)]
- RETURN CONCAT(OUTPUT)
-
-ERIS-Decode(BLOCK-SIZE, LEVEL, ROOT-REFERENCE, ROOT-KEY):
- PADDED := ERIS-Decode-Recurse(LEVEL, ROOT-REFERENCE, ROOT-KEY)
- RETURN UNPAD(PADDED, BLOCK-SIZE)
-----
-
-Where the block-storage can be accessed as follows:
-
-`Block-Storage-Get(REFERENCE)` :: Returns a block such that `Blake2b-256(Block-Storage-Get(REFERENCE)) == REFERENCE` or throws an error.
-
-A streaming decoding procedure can be implemented where the content can be output block wise and does not need to be kept in memory for unpadding. For an example, see https://gitlab.com/openengiadina/eris/-/raw/main/eris/decode.scm[the reference Guile implementation].
-
-==== Random Access
-
-A decoder that allows random access to the encoded content can be implemented by decoding selected sub-trees.
-
-=== Binary Encoding of Read Capability
-
-The read-capability consisting of the block-size, level of root reference-key pair as well as the root reference-key pair form the necessary pieces of information required to decode content.
-
-We specify an binary encoding of the read-capability 66 bytes:
-
-|===
-|Byte offset | Content | Length (in bytes)
-
-| 0 | block size (`0x00` for block size 1KiB and `0x01` for block size 32KiB)| 1
-| 1 | level of root reference-key pair as unsigned integer | 1
-| 2 | root reference | 32
-| 34 | root key | 32
-|===
-
-The initial field (block size) also encodes the ERIS version. Future versions of ERIS MUST use different codes to encode block sizes.
-
-Note that using a single byte to encode the level limits the size of content that can be encoded with ERIS. However, the size of the largest encodable content is approximately 1e300 TiB, which seems to be sufficient for any conceivable practical applications (including an index of all atoms in the universe).
-
-==== CBOR Tag
-
-The CBOR tag `276` is assigned for a ERIS binary read capability (see <<_cbor_tags_registry>>). This allows efficient references to ERIS encoded content from CBOR.
-
-=== URN
-
-A read-capability can be encoded as an URN: `urn:erisx2:BASE32-READ-CAPABILITY`, where `BASE32-READ-CAPABILITY` is the unpadded Base32 <<RFC4648>> encoding of the read capability.
-
-For example the ERIS URN of the UTF-8 encoded string "Hello world!" (with block size 1KiB and null convergence secret):
-
-`urn:erisx2:AAAD77QDJMFAKZYH2DXBUZYAP3MXZ3DJZVFYQ5DFWC6T65WSFCU5S2IT4YZGJ7AC4SYQMP2DM2ANS2ZTCP3DJJIRV733CRAAHOSWIYZM3M`
-
-[NOTE]
-====
-The URN namespace `erisx2` is used for this experimental version of the encoding. Once finalized the namespace `eris` will be used (e.g. `urn:eris:AAAD77QDJMFAKZYH2DXBUZYAP3MXZ3DJZVFYQ5DFWC6T65WSFCU5S2IT4YZGJ7AC4SYQMP2DM2ANS2ZTCP3DJJIRV733CRAAHOSWIYZM3M`)
-====
-== Applications
-
-Traditionally encoding schemes similar to ERIS are used for peer-to-peer filesharing. We hope to motivate usage for a much wider scope of applications.
-
-As part of the https://openengiadina.net[openEngiadina] project we are using ERIS to encode small bits of information that constitute "local knowledge" (e.g. geogrpahic information, social and cultural events, etc.) along with the social interactions that created and curated this information (using the ActivityStreams vocabulary <<ActivityStreams>>). ERIS allows such information to be securely cached on multiple peers to increase the robustness of the system.
-
-ERIS encoded content can be used from existing web technology and RDF as the content can be referenced by an URN. At the same time more decentralized networks can be used (this will be further research as part of the https://dream.public.cat/[DREAM] project).
-
-Other possible applications include package managers such as https://guix.gnu.org/[Guix] to increase availability of software sources and built packages or decentralized and offline-first mapping applications.
-
-=== Storage and Transport Layers
-
-ERIS is defined indepenedant of any storage and transport layer for blocks. The only requireiment is that blocks can be accessed by their reference - the hash of the block content.
-
-Possible storage layers include:
-
-- in-memory hash-map
-- key-value store
-- files on a file system
-
-Transport mechanisms include:
-
-- HTTP: A simple HTTP endpoint can be used to dereference blocks
-- Sneakernet: Blocks can be transported on a physical medium such as a USB stick
-
-More interesting transport and storage layers use the fact that blocks are content-addressed. For example the peer-to-peer network https://ipfs.io/[IPFS] can be used to store and transport blocks (see the https://gitlab.com/openengiadina/eris/-/blob/main/examples/ipfs.org[example] using the reference Guile implementation). The major advantages over using IPFS directly include:
-
-- Content is encrypted and not readable to IPFS peers without the read capability.
-- Identifier of blocks and encoded content is not tied to the IPFS network. Applications can transparently use IPFS or any other storage/transport mechanism.
-
-It also seems possible to use the https://named-data.net/[Named Data Networking] infrastructure and forwarding daemons (initial support for using Blake2b as hash function is present in the https://github.com/named-data/ndn-cxx[ndn-cxx library]).
-
-=== Authenticity of Content
-
-The presented encoding ensures integrity of content. Content can not be tampered with wihtout changing the identifier (read capability) of the content. To prove authenticity of encoded content it is sufficient to cryptographically sign the read capability.
-
-We have presented a concrete proposal on how this might be done using a RDF vocabulary and the Ed25519 cryptographic signature scheme <<RDF-Signify>>.
-
-=== Mutability and Namespaces
-
-Encoded content is immutable in the sense that changing the encoded content results in a new identifier. Existing references to the old content need to be updated. This is a property that makes caching efficient and allows ERIS to be used for robust systems.
-
-Nevertheless, there are applications where one wants to reference mutable content. Examples include user profiles or dynamic collections of content. Making small changes to a user profile or adding a piece of content to a collection should preserve the identifiers.
-
-There are many ways of implementing such mutability or "namespaces". ERIS does not specify any particular mechanism. Possible mechanisms include:
-
-- Centralized servers that returns a mutable list of reference to (immutable) content. This is how most HTTP services work.
-- Append-only logs where changes are securely appended with cryptographic signatures. The state is computed from the log of changes. This is how peer-to-peer systems such as https://hypercore-protocol.org/[hypercore] or https://scuttlebutt.nz/[Secure ScuttleButt] work.
-- Petname system: A system where a dynamic local name can be mapped to a reference. Sophisticated systems that allow delegation of naming authority include https://gnunet.org/en/gns.html[the GNU Name System].
-- Commutative Replicated Data Types (CRDTs) are distributed datastructures similar to append-only logs with the advantage that the state of a mutable container can diverge and converge to consistent state eventually. Such structures seem especially suitable when control over a mutable container is shared by multiple parties. We have made a concrete proposal for such mutable containers <<DMC>>.
-
-We believe that the best suited mechanism for handling mutability depends on concrete applications and use-cases. A key value of ERIS is that it is agnostic of such mechanisms and can be used from any of them.
-
-== Test Vectors
-
-=== Machine Readable
-
-A set of test vectors are provided in the https://gitlab.com/openengiadina/eris/-/tree/main/test-vectors[ERIS repository]. Implementations of the ERIS encoding MUST be able to satisfy the test vectors.
-
-The test vectors are given as machine-readable JSON files. For example the test vector `eris-test-vector-00.json`:
-
-[source,json]
-----
-{
- "id": 0,
- "name": "short string (block size 1KiB)",
- "description": "Encode the UTF-8 encoding of the string \"Hello world!\" with block-size 1KiB and null convergence-secret.",
- "content": "JBSWY3DPEB3W64TMMQQQ",
- "convergence-secret": "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA",
- "block-size": 1024,
- "read-capability": {
- "block-size": 1024,
- "level": 0,
- "root-reference": "H77AGSYKAVTQPUHODJTQA7WZPTWGTTKLRB2GLMF5H53NEKFJ3FUQ",
- "root-key": "CPTDEZH4ALSLCBR7INTIBWLLGMJ7MNFFCGX7PMKEAA52KZDDFTNQ"
- },
- "urn": "urn:erisx2:AAAD77QDJMFAKZYH2DXBUZYAP3MXZ3DJZVFYQ5DFWC6T65WSFCU5S2IT4YZGJ7AC4SYQMP2DM2ANS2ZTCP3DJJIRV733CRAAHOSWIYZM3M",
- "blocks": {
- "H77AGSYKAVTQPUHODJTQA7WZPTWGTTKLRB2GLMF5H53NEKFJ3FUQ": "EWZKXK73236ETFGMMFORFLMNIPE5V3S3WDVFECUPI47RFJBA5ZMBHH6HMOZCNFQKOTADCPJMPHTZJNEW4VOKHBSNABYVIZWQDV5GQPECUBDAULOPR2S7ITYQSGGVPPEWJVEZNIUKUFR4XE7GQPUDY3FPFSCUYIISZX6PWLLPNPI5V3RKWQGN2L6LLE5G7TZ5FVPAYUHOES4LGHRKSXYCNQF6IR5HLKX2C2EPVKSU2T6XOSAF5VHUZ2GTQS7BLT3VYP5BYI2WR4GJEYDWLY26TK6ZQ2DYZZBIYSVUIY557FE6QOV3L5X5HCAQEWPYCUKUADOOSMNU7EEONPRMBJU4XLQ66AOOVRQ66OJLHANVLNFDXXPLH6KDVCJBVQWWWI7PA6OGKGPU7ZZPZT2DIBOAUGWM6DVZWWX3DA3GHWS3VY6RQMLAKDXHZRQ6VDVMLMFSULJYHACC7G57CZ2SG7XB24XT3SLJG56PO3Z7YJJYEVP44F44YCZ5YS4NRZKWS4OTFMXGNF25G3GIGSV5NEVVTSO6J5EKEXWTX74X27HYI4UZ45YF675423AWYUVTPVLUWOJMGANQRDWYOPFE5QH6JUINCH5NYZUHYPZP6WHC4IVOLYFDAUNOWLRVR37BLT5E44VVJ6XDQZAS2XT6G2XM3RJUUQEYD2RRFBWGPNSOJ2RUPE654GKHRDCKUX2MZ6D43LKI2DKCF7QEPYWJWJH6EI74NQNOLCHEAUFEXH5ZXUXO6JJ5PKOXGL4RBOGCP2X2RYXOJOCT55BAGCRQHID2TRO7NPZWGQNMSSWHOAXY6JFCVFXXGR4JM62HHXZTKODD7NYXO7EUS3GMY2NDQFENM3XKNAI5MFNLL7ERMPSIXHAJ44ASIDZS7RPZ542SLH7XONZ6PMCPI4V66ALJJTTXMJAEU35YPH3UD7UHBCM4OI3SDGTUL3TQQWMDIFBNECJN7FNAWRXTWCXM6CIILVYAITWSEDIDEMLBKR5KIGE5SQTW2ITIIA725SNZO3PJMQCAPJI4H3QXVPKG4OZIOTENU2VW3W3PNAYVE65YJBQGPY6M6LRQYGPYYSEFTRPW3YXGGC2ICFROUD7FXCFXVD6OWA4B6LDFDX4LPF4H7525BVRBNW2ZLMXZUXCFZSZOSSP7VKBCWIDJ72XSR43YFKTL5TADVXDF3RN2HHAGKXWOXINMJJLRE4K72H54IOROFS4FD5QYXWSJWH4ENYC4PAOJ6JELRFYC6RMXP73VR745WY4ZOFQTRQ5ZEA2C3M7JTQUVKV26XGVVHBYA7NEMRPZNVRXHCKYN3CGJSICBUFGMHSSDBTRIF3BCPVMLRBU25DFGGM4LEEL4KTIAJITYY5XPR4XDRD55PEDVOUL342IXCNEBTTPPLMPV6EJYUFJS42R4XLDOT7NOFPLTZUBLWSLL7IVZNPNI6DZ4CR7YEQP72DDUWDJJTKACT35JLFPDW3M2VUOJF3CUWN6FYN5YJJSXYMXSVDZDVIAJYF2HOPQEHLMRF3MJAXMTLMCOIARLFZKAGRSW6PWQZ7ZJLCQAPSJTPNDA2SLUA3UHH34NWEPTAVWOBDPNTMT27TK5P4VKLE2YEJHKWE6SJA3V7A3UPQS24SWDJ2BPOV7JG23ZVIA"
- }
-}
-----
-
-The fields of JSON test vectors are:
-
-`id` :: Numeric identifier of the test vector.
-`name` :: Short human readable name.
-`description` :: Human readable description of the test.
-`content` :: The binary content to be encoded as Base32 (unpadded) string.
-`convergence-secret` :: The convergence secret to be used as Base32 string.
-`block-size` :: Block size that should be used for encoding in bytes (either 1024 or 32768).
-`read-capability` :: JSON map containing the components of the read capability. This is not used in tests but is here as a help for developers.
-`urn` :: The ERIS URN of the content.
-`blocks` :: A JSON map of blocks required to decode the content given the URN. Key and field are encoded as Base32 strings.
-
-Implementations MUST verify that the content encodes to the URN given the specified block size and convergence secret and verify that given the URN and blocks the content can be decoded.
-
-=== Large content
-
-In order to verify implementations that encode content by streaming (see <<_streaming>>) URNs of large contents that are generated in a specified way are provided:
-
-|===
-|Test name | Content size | Block size | URN | Level of root reference
-| 100MiB (block size 1KiB) | 100MiB | 1KiB | `urn:erisx2:AACXPZNDNXFLO4IOMF6VIV2ZETGUJEUU7GN4AHPWNKEN6KJMCNP6YNUMVW2SCGZUJ4L3FHIXVECRZQ3QSBOTYPGXHN2WRBMB27NXDTAP24` | 5
-| 1GiB (block size 32KiB) | 1GiB | 32KiB | `urn:erisx2:AEBFG37LU5BM5N3LXNPNMGAOQPZ5QTJAV22XEMX3EMSAMTP7EWOSD2I7AGEEQCTEKDQX7WCKGM6KQ5ALY5XJC4LMOYQPB2ZAFTBNDB6FAA` | 2
-| 256GiB (block size 32KiB) | 256GiB | 32KiB | `urn:erisx2:AEBZHI55XJYINGLXWKJKZHBIXN6RSNDU233CY3ELFSTQNSVITBSVXGVGBKBCS4P4M5VSAUOZSMVAEC2VDFQTI5SEYVX4DN53FTJENWX4KU` | 3
-|===
-
-Content is the ChaCha20 stream using a null nonce and the key which is the Blake2b hash of the UTF-8 encoded test name (e.g. `KEY := Blake2b-256("100MiB (block size 1KiB)")`). The ChaCha20 stream can be computed by encoding a null byte sequence (e.g. `CHACHA20_STREAM := ChaCha20(NULL, KEY)`).
-
-== Implementations
-
-A list of known implementations that satisify the test vectors:
-
-|===
-| Name | Programming language | License | Notes | Homepage
-
-| `guile-eris` | Guile | GPL-3.0-or-later | Reference implementation | https://inqlab.net/git/eris.git/
-| `elixir-eris` | Elixir | GPL-3.0-or-later | Used in the https://gitlab.com/openengiadina/cpub[CPub] ActivityPub server | https://inqlab.net/git/elixir-eris.git/
-| `eris` | Go | BSD-3-Clause | | https://github.com/cjslep/eris
-| `eris` | Nim | ISC | | https://git.sr.ht/~ehmry/eris
-| js-eris| JavaScript | LGPL-3.0-or-later | | https://inqlab.net/git/js-eris.git/
-|===
-
-Further implementations are under development in https://hg.sr.ht/~arnebab/wisperis/[Wisp], https://gitlab.com/emacsen/pyeris[Python] and https://gitlab.com/public.dream/dromedar/ocaml-eris[OCaml].
-
-== IANA Considerations
-
-=== CBOR Tags Registry
-
-This specification requires the assignment of a CBOR tag for a binary ERIS read capability. The tag is added to the CBOR Tags Registry as defined in RFC 8949 <<RFC8949>>.
-
-|===
-| Tag | Data Item | Semantics
-| 276 | byte string | ERIS binary read capability (see <<_binary_encoding_of_read_capability>>)
-|===
-
-== Acknowledgments
-
-Thanks to Cory Slep, Arne Babenhauserheide, Serge Wroclawski, Christopher Lemmer Webber, Christian Grothoff, Natacha, Hellekin, Nemael, TG, Devan, Emery, Arie, Allen and many others for the discussions, suggestions and support.
-
-Development of ERIS has been supported by the https://nlnet.nl[NLNet Foundation] trough the https://nlnet.nl/discovery/[NGI0 Discovery Fund].
-
-:sectnums!:
-== Changelog
-
-The most recent version is published at http://purl.org/eris.
-
-[discrete]
-=== link:http://purl.org/eris[v0.3.0-DRAFT (UNRELEASED)]
-
-[discrete]
-==== Added
-
-- CBOR Tag for ERIS binary read capability
-
-[discrete]
-=== link:eris-v0.2.0.html[v0.2.0 (7. December 2020)]
-
-Major update of encoding that removes the _verification capability_ - ability to verify integrity of content without reading content.
-
-[discrete]
-=== link:eris-v0.1.html[v0.1.0 (11. June 2020)]
-
-Initial version.
-
-
-== Copyright
-
-This work is licensed under a http://creativecommons.org/licenses/by-sa/4.0/[Creative Commons Attribution-ShareAlike 4.0 International License].
-
-== References
-
-[bibliography]
-=== Normative References
-
-- [[[RFC2119]]] S. Bradner, https://tools.ietf.org/html/rfc2119[Key words for use in RFCs to Indicate Requirement Levels], 1997.
-- [[[RFC4648]]] S. Josefsson, https://tools.ietf.org/html/rfc4648[The Base16, Base32, and Base64 Data Encodings], 2006.
-- [[[RFC8949]]] C. Bormann & P. Hoffman. https://tools.ietf.org/html/rfc8949[Concise Binary Object Representation (CBOR)], 2020.
-- [[[RFC7693]]] M-J. Saarinen and J-P. Aumasson, https://tools.ietf.org/html/rfc7693[The BLAKE2 Cryptographic Hash and Message Authentication Code (MAC)], 2015.
-- [[[RFC8439]]] Nir and Langley, https://tools.ietf.org/html/rfc8439[ChaCha20 and Poly1305 for IETF Protocols], 2018.
-- [[[RFC8141]]] Saint-Andre, Filament and Klensin, https://tools.ietf.org/html/rfc8141[Uniform Resource Names (URNs)], 2017.
-
-[bibliography]
-=== Informative References
-- [[[ActivityStreams]]] Snell and Prodromou, https://www.w3.org/TR/activitystreams-core/[Activity Streams 2.0], 2017.
-- [[[BEP52]]] http://bittorrent.org/beps/bep_0052.html[The BitTorrent Protocol Specification v2], 2017.
-- [[[DMC]]] pukkamustard, http://purl.org/dmc/spec[Distributed Mutable Containers], 2020.
-- [[[ECRS]]] Grothoff, et al., https://grothoff.org/christian/ecrs.pdf[An encoding for censorship-resistant sharing], 2003.
-- [[[Freenet]]] Clarke, et al., http://bourbon.usc.edu/cs694-s09/papers/freenet.pdf[Freenet: A distributed anonymous information storage and retrieval system], 2001.
-- [[[MLS]]] Omara, et al., https://messaginglayersecurity.rocks/mls-architecture/draft-ietf-mls-architecture.html[The Messaging Layer Security (MLS) Architecture (DRAFT)], 2020.
-- [[[OMEMO]]] Straub, et al., https://xmpp.org/extensions/xep-0384.html[XEP-0384: OMEMO Encryption], 2020.
-- [[[Polleres2020]]] Polleres, et al., https://epub.wu.ac.at/6371/1/IPM_workingpaper_02_2018.pdf[A more decentralized vision for Linked Data], 2020.
-- [[[RDF-Signify]]] pukkamustard, http://purl.org/signify/spec[RDF Signify], 2020.
-- [[[RFC7927]]] Kutscher et. al. https://tools.ietf.org/html/rfc7927[Information-Centric Networking (ICN) Research Challenges], 2016.
-- [[[Zooko2008]]] Zooko Wilcox-O'Hearn. https://tahoe-lafs.org/hacktahoelafs/drew_perttula.html[Drew Perttula and Attacks on Convergent Encryption], 2008.
-
diff --git a/doc/eris.adoc.license b/doc/eris.adoc.license
deleted file mode 100644
index dc2510a..0000000
--- a/doc/eris.adoc.license
+++ /dev/null
@@ -1,3 +0,0 @@
-SPDX-FileCopyrightText: 2020 pukkamustard <pukkamustard@posteo.net>
-
-SPDX-License-Identifier: CC-BY-SA-4.0 \ No newline at end of file
diff --git a/doc/eris.org b/doc/eris.org
deleted file mode 100644
index e07d1f0..0000000
--- a/doc/eris.org
+++ /dev/null
@@ -1,728 +0,0 @@
-# SPDX-FileCopyrightText: 2020 pukkamustard <pukkamustard@posteo.net>
-#
-# SPDX-License-Identifier: CC-BY-SA-4.0
-#+TITLE: An Encoding for Robust Immutable Storage
-#+SUBTITLE: 11. June 2020 (v0.1)
-#+AUTHOR: pukkamustard
-#+KEYWORDS: Content-addressable Storage, ActivityPub, RDF, GNUNet, P2P, Datashards
-#+HTML_HEAD: <style>body {margin: 40px; font-family: sans-serif;} #content { line-height: 1.6; font-size: 16px; color: #222; max-width: 800px;margin: 40px auto;} pre.src {overflow: auto;} blockquote {text-align: right; margin-left: 30%; max-width: 70%; font-style: italic;}</style>
-#+PROPERTY: header-args:dot :cmdline -Nfontname=sans-serif -Tsvg :eval never-export :exports results
-#+PROPERTY: header-args:scheme :session *eris-repl* :eval never-export
-#+OPTIONS: toc:nil
-
-#+BEGIN_abstract
-We present an Encoding for Robust Immutable Storage (ERIS) that can be used with a content-addressable storage to encode arbitrary content into a set of uniformly sized encrypted blocks such that the content can only be reassembled to the original content given a /read capability/.
-
-Additionally, a /verification capability/ can be derived from the /read capability/ that can be used to enumerate blocks required to reassemble the content and verify the integrity of blocks without being able to read the content. This allows peers to cache the content whit plausible deniability of being able to read the content.
-
-We illustrate how ERIS can be used to build as a building block for robust, decentralized applications and demonstrate how ERIS can leverage existing peer-to-peer technology (such as IPFS).
-#+END_abstract
-
-#+TOC: headlines 3
-
-* Introduction
-
-#+BEGIN_QUOTE
-The one so like the other
-
-As could not be distinguish'd but by names.
-
---- William Shakespeare, Comedy of Errors
-#+END_QUOTE
-
-Unavailability of content on computer networks is a major cause for reduced reliability of networked services [cite:Polleres_Kamdar_Fernández_Tudorache_Musen_2020].
-
-Availability can be increased by caching content on multiple peers. However most content on the Internet is identified by its location. Caching location-addressed content is complicated as the content receives a new location.
-
-An alternative to identifying content by its location is to identify content by its content itself. This is called content-addressing. The hash of some content is computed and used as an unique identifier for the content.
-
-Content-addressed content is much easier to cache as the content is completely decoupled from any physical location. It is much easier to ensure availability of content-addressed content than it is for location-addressed content. Systems like [[https://ipfs.io/][IPFS]] use content-addressing for exactly this reason.
-
-Authenticity of content is automatically ensured with content-addressing (when using a cryptographic hash) as the identifier of the content can be computed and be checked to match the requested identifier.
-
-However, naive content-addressing has certain drawbacks:
-
-- Large content is stored as a large blob. In order to optimize storage and network operations it is better to split up content into smaller uniformly sized blocks and reassemble blocks when needed.
-- Confidentiality: Content is readable by all peers involved in transporting, caching and storing content.
-
-We propose ERIS, a scheme that addresses the issues with naive content-addressing that we hope may provide a robust foundation for storing immutable content.
-
-** Requirements
-
-The requirements for the ERIS are:
-
-- Availability of content: Content can be replicated and cached.
-- Authenticity: Authenticity of content can be verified.
-- Plausible deniability for peers: Peers that transport, store and cache data blocks can do this without being able to read the content.
-- URN reference: Content can be reference with a single URN.
-- Simplicity: The encoding should be as simple as possible in order to allow correct implementation on various platforms and in various languages.
-
-** Scope
-
-#+BEGIN_QUOTE
-A concept is tolerated inside the microkernel only if moving it outside the kernel, i.e. permitting competing implementations, would prevent the implementation of the system’s required functionality.
-
---- Jochen Liedtke, On μ-Kernel Construction [cite:liedtke1995micro]
-#+END_QUOTE
-
-ERIS describes how arbitrary content (sequence of bytes) can be encoded into a set of uniformly sized blocks and an identifier with which the content can be decoded from the set of blocks.
-
-ERIS does not prescribe how the blocks should be stored or transported over network. The only requirement is that a block can be referenced and accessed (if available) by the hash value of the contents of the block. In section [[storage-and-transport][Storage and Transport]] we show how existing technology (including IPFS) can be used to store and transport blocks.
-
-There is also no support for grouping content or mutating content. In section [[namespaces][Namespaces]] we describe how such functionality can be implemented on top of ERIS.
-
-The lack of certain functionalities is intentional. ERIS is an attempt to find a minimal common basis on which higher functionality can be built. Lacking functionality in ERIS is an acknowledgment that there are many ways of implementing such functionality at a different layer that may be optimized for certain use-cases. In section [[applications][Applications]] we illustrate how such functionality may be implemented using ERIS.
-
-* ERIS encoding
-<<eris-encoding>>
-
-The scheme we propose defines an encoding of content into uniformly sized content-addressed, encrypted data blocks and a reference (an URN) that can used to reassemble the blocks to the original content. We call the reference that can be used to reassemble the blocks the /read capability/.
-
-Given the read capability and the encrypted data blocks the original content can be decoded.
-
-From the read capability a /verification capability/ can be deterministically derived. The verification capability allows holder to enumerate all blocks required to reassemble the content and verify the integrity of the blocks. The verification capability can not be used to decode the unencrypted content. The verification capability allows plausible deniable caching of content.
-
-An optional /convergence secret/ can be specified when encoding the content. This provides (optional) protection from certain attacks (see [[convergence-secret][Convergence secret]]).
-
-#+BEGIN_SRC dot :file images/eris-overview.svg :exports results
-digraph {
- rankdir = "LR";
- content [shape=box];
-
- encode [label="encode"];
- decode [label="decode"];
-
- content -> encode;
- content -> decode [dir=back];
-
- c_secret [label="convergence secret\n(optional)", shape="box"];
-
- read_cap [shape="box",label="read capability"];
- blocks [shape="box",label="data blocks\n(encrypted)"];
-
- c_secret -> encode;
-
- encode -> read_cap;
- encode -> blocks;
-
- decode -> read_cap [dir=back];
- decode -> blocks [dir=back];
-
- verify_cap [shape="box",label="verification capability"];
- read_cap -> verify_cap [label="derive"];
-
- verify [label="verify"];
-
- verify_cap -> verify;
- blocks -> verify;
-
- list_of_blocks [label="list of references\nto data blocks"];
- verify -> list_of_blocks;
-}
-#+END_SRC
-
-#+CAPTION: Overview of ERIS
-#+ATTR_HTML: :style width: 150%; transform: translateX(-50%); margin-left: 50%;
-#+RESULTS:
-[[file:images/eris-overview.svg]]
-
-** Preliminaries
-*** Cryptographic primitives
-<<crypto>>
-
-Following cryptographic primitives are used by ERIS:
-
-- Cryptographic hash function :: BLAKE2b [cite:aumasson2013blake2,saarinen2015blake2] with output size of 256 bit (32 byte)
-- Symmetric Key Cypher :: ChaCha20 IETF variant [cite:nir2015chacha20]
-- Padding algorithm :: According to ISO/IEC 7816-4
-- Key derivation :: Using keyed and salted BLAKE2b. Derived key is ~BLAKE2b(key=key, message={}, salt=subkey_id, personal=ctx)~.
-
-The cryptographic primitives are readily available in libraries for many platforms and programming languages (e.g. [[https://doc.libsodium.org/][libsodium]]).
-
-*** Content-addressable storage
-<<cas>>
-
-For storage of blocks we rely on a content-addressable storage which provides two functions:
-
-- ~cas-put!(block)~ :: Stores a 4kB ~block~ of data and returns a reference such that ~ref = BLAKE2b(block)~.
-- ~cas-get(ref)~ :: Given a reference returns a block of data that was previously stored, such that ~ref = BLAKE2b(block)~. If there is no block stored for the reference then throw an error.
-
-A content-addressable storage can be implemented with a hash-map (in-memory), a key-value store (e.g. LevelDB), a relational database or using systems like IPFS (see [[storage-and-transport][Storage and Transport]]).
-
-** Read and verification key
-
-ERIS uses two keys to encrypt content:
-
-- read key :: The key used to encrypt the content. The read key is ~BLAKE2b(content)~. If a convergence secret is given the read key is ~BLAKE2b(content, key=covergence-secret)~ (using keyed hashing).
-- verification key :: Derived from the read key using the subkey id ~1~ and personalization context set to the UTF-8 encoding of the string ~"eris.key"~.
-
-*** Convergence Secret
-<<convergence-secret>>
-
-Using the hash of the content as key is called /convergent encryption/.
-
-Because the hash of the content is deterministically computed from the content, the key will be the same when the same content is encoded twice. This results in deduplication.
-
-However convergent encryption suffers from two known attacks: The Confirmation Of A File Attack and The Learn-The-Remaining-Information Attack [cite:Zooko2008].
-
-A defense against both attacks is to use a /convergence secret/. This results in different keys and different URNs when encoding the same content with different convergence secret.
-
-In section [[namespaces][Namespaces]] we describe how convergence secrets can be used.
-
-** Encoding
-
-The encoding process takes the content (as sequence of bytes), the read key and the verification key and returns a /root reference/ (32 bytes) and a /level/ count (positive integer with maximum value 12) which denotes the height of the Merkle tree.
-
-The encoding process is:
-
-1. Content is first padded (see [[crypto][Cryptographic Primitives]]) to a multiple of 4kB.
-2. Content is then encoded with the symmetric key cypher using the ~read key~ and nonce set to ~0~. If content is larger than 256 GB use nonce ~0~ for first 256 GB and increment nonce for successive chunks of 256 GB.
-3. Encrypted content is split into blocks of size 4kB. The blocks holding encrypted content are called /data blocks/.
-4. Store data blocks in content-addressable storage and get /data block references/.
-5. Combine the data block references in a Merkle tree and return the reference to the root node (root reference) and the height of the Merkle tree (level).
-
-The construction of the Merkle tree is described in the following section.
-
-*** Merkle tree
-
-After encrypting the content and placing the data blocks in the content-addressable storage we may have a large number of data block references. To retrieve the content we need all these references, which is impractical. Merkle trees allow us to hold a single reference that will allow us to discover all data block references.
-
-The idea is to store references to data blocks in nodes of a tree. The nodes are themselves stored in the content-addressable storage and can be referenced and accessed in the same way data blocks can be referenced and accessed.
-
-For illustration purposes we will show Merkle tree with arity two (two child references) the ERIS scheme uses arity 128.
-
-If the content fits in one single data block (content smaller than 4kB) then return the data block reference and level 0.
-
-If there are multiple data blocks combine them in a Merkle tree of arity 128. If there are less than 128 child nodes to be collected in a node the node is filled with null references (32 bytes of zeroes). The size of a node is always exactly 4kB (128 32 byte references).
-
-Nodes of the Merkle tree are encrypted using the verification key and a nonce derived from the position of the node in the tree.
-
-Encrypted nodes are stored in the content-addressable storage and references are placed in a node in the next higher level.
-
-Note that encrypted nodes are indistinguishable from encrypted data blocks. We will refer to encrypted nodes and encrypted data blocks as /blocks/.
-
-The Merkle tree is constructed until there is a single node on a level. This is the root reference. Note that the root reference is always the first of its level.
-
-#+BEGIN_SRC dot :file images/eris-merkle-1.svg :exports results
-digraph {
-
- compound=true;
-
- subgraph cluster__level_0 {
- style=dotted;
- label="level 0\n(data blocks)";
- labeljust="l";
-
- block_7 [shape=box,color=lightblue,style=filled,label="block-7"];
- block_6 [shape=box,color=lightblue,style=filled,label="block-6"];
- block_5 [shape=box,color=lightblue,style=filled,label="block-5"];
- block_4 [shape=box,color=lightblue,style=filled,label="block-4"];
- block_3 [shape=box,color=lightblue,style=filled,label="block-3"];
- block_2 [shape=box,color=lightblue,style=filled,label="block-2"];
- block_1 [shape=box,color=lightblue,style=filled,label="block-1"];
- block_0 [shape=box,color=lightblue,style=filled,label="block-0"];
- };
-
- subgraph cluster__level_1 {
- style=dotted;
- label="level 1";
- labeljust="l";
- node_1_3 [shape=box,color=yellow,style=filled,label="node-1-3"];
- node_1_2 [shape=box,color=yellow,style=filled,label="node-1-2"];
- node_1_1 [shape=box,color=yellow,style=filled,label="node-1-1"];
- node_1_0 [shape=box,color=yellow,style=filled,label="node-1-0"];
- };
-
- node_1_0 -> block_0;
- node_1_0 -> block_1;
-
- node_1_1 -> block_2;
- node_1_1 -> block_3;
-
- node_1_2 -> block_4;
- node_1_2 -> block_5;
-
- node_1_3 -> block_6;
- node_1_3 -> block_7;
-
- subgraph cluster__level_2 {
- label="level 2";
- labeljust="l";
- style=dotted;
- node_2_1 [shape=box,color=yellow,style=filled,label="node-2-1"];
- node_2_0 [shape=box,color=yellow,style=filled,label="node-2-0"];
- };
-
- node_2_0 -> node_1_0;
- node_2_0 -> node_1_1;
-
- node_2_1 -> node_1_2;
- node_2_1 -> node_1_3;
-
- subgraph cluster__level_3 {
- style=dotted;
- label="level 3";
- labeljust="l";
- node_3_0 [shape=box,color=yellow,style=filled,label="node-3-0"];
- }
-
- node_3_0 -> node_2_0;
- node_3_0 -> node_2_1;
-
-}
-#+END_SRC
-
-#+CAPTION: Merkle tree
-#+RESULTS:
-[[file:images/eris-merkle-1.svg]]
-
-*** Nonce from position
-<<nonce>>
-
-We identify the position of a node in the Merkle tree with the level and the count of nodes in the level (e.g. ~node-1-2~ is the third node from left on level one).
-
-We can encode the path from the root to a node by describing which child reference we have to follow. For example to reach ~node-1-1~ from the root node (~node-3-0~) the path is: left, right. If we use 0 for left and 1 for right: ~(0,1)~.
-
-All nodes at level 1 have a path of length two from the root: ~(0,0)~ for ~node-0-0~ or ~(1,0)~ for ~node-1-3~.
-
-Notice that the path to a leaf node is the base-2 encoding of the count in the level: ~node-1-3~ has count 3 which in binary (base-2) is ~(1,1)~ - the path to reach ~node-1-3~ from the root.
-
-For internal nodes (not at level 0) the same thing. To reach node ~node-2-1~ we take the path ~(1)~ which is the base-2 encoding of it's count in the level.
-
-However we have the problem of distinguishing ~(1)~ (~node-2-1~) from ~(0,1)~ (~node-1-1~). We solve this by introducing an additional variable ~X~ that denotes a path not taken yet. We can now encode all nodes to a fixed size:
-
-- ~node-1-1~: ~(0,1)~
-- ~node-1-3~: ~(1,1)~
-- ~node-2-1~: ~(1,X)~
-- ~node-2-0~: ~(0,X)~
-- ~node-3-0~: ~(X,X)~
-
-This "path" can be encoded into a nonce that we can use for encrypting the nodes.
-
-In ERIS there are at most 128 child references per node, the path to a node can be computed by base-128 encoding the count of a node in a level. We use the value ~255~ as ~X~ and a maximum path length of 12. This sequence of 12 integers can be directly mapped to a 12 byte nonce.
-
-For example in ERIS (with Merkle tree of arity 128):
-
-- ~node-1-1~: ~(0,0,0,0,0,0,0,0,0,0,0,1)~
-- ~node-5-3~: ~(0,0,0,0,0,0,0,3,255,255,255,255)~
-- ~node-4-3042~: ~(0,0,0,0,0,0,0,23,98,255,255,255)~
-- ~node-8-294~: ~(0,0,0,2,38,255,255,255,255,255,255,255)~
-
-The nonce directly identifies the position and is thus not reused.
-
-Note that the encoding is not efficient (values between 127 and 255 are not used) and limits the size of the Merkle tree and thus the size of the content that can be encoded with ERIS (see [[limits][Limits on size of content]]).
-
-*** Second preimage attack
-
-By encrypting the node using a nonce computed from the position of the node, we
-implicitly encode the position of the node into the hash reference of a node.
-
-This prevents a node to be reused at an unforeseen position, preventing a [[https://en.wikipedia.org/wiki/Merkle_tree#Second_preimage_attack][second preimage attack]].
-
-*** Two-pass encoding
-
-We have illustrated an algorithm that encrypts the entire content (or 256 GB chunks) in one go. This is not always possible (content may be larger than memory).
-
-ERIS can also be implemented as a two-pass streaming algorithm.
-
-In the first pass the read key is computed (using BLAKE2b).
-
-In the second pass 4 kB blocks of data are encrypted (setting the initial block counter appropriately), stored in the content-addressable storage and added to the Merkle tree.
-
-Unfortunately ERIS requires two passes over the content (as opposed to one single pass). This is a major drawback ERIS has.
-
-Two-pass encoding is implemented in the [[https://gitlab.com/openengiadina/data-model/][Guile implementation]].
-
-** URN
-
-To read and/or verify content following information is required:
-
-- The root reference (as returned by the encode process)
-- The level of the Merkle tree (as returned by the encode process)
-- The read or verify key
-
-All this information can be packed in an URN, allowing ERIS encoded content to be referenced with a single identifier. We call such an identifier a /capability/ as it gives holder capability to read or verify the content.
-
-The root reference, level and key are encoded (with some additional information) to a /binary capability/ as follows:
-
-#+CAPTION: Binary capability encoding
-| Byte offset | Content | Length (in bytes) |
-|-------------+------------------------------------------------------+-------------------|
-| 0 | version (~0x00~) | 1 |
-| 1 | capability type (~0x00~ for read, ~0x01~ for verify) | 1 |
-| 2 | level of root reference | 1 |
-| 3 | root reference | 32 |
-| 35 | read or verify key | 32 |
-
-The capability URN is:
-
-~urn:eris:X~
-
-Where ~X~ is the Base32 encoding of the binary capability encoding.
-
-For example the read capability for the string "Hail ERIS!" is:
-
-#+BEGIN_SRC scheme :exports results
-(use-modules (eris)
- (web uri)
- (eris cas)
- (eris cas null)
- (rnrs bytevectors))
-
-(uri->string
- (eris-put! (make-null-cas)
- (string->utf8 "Hail ERIS!")))
-#+END_SRC
-
-#+RESULTS:
-: urn:erisx:AAAAABM5XFVEHHR45X3YKU4ARK6MBHOZ4W22OTG5ME4NGO32H5P4SP3MCL3TK373WD53WSE6BOJACMNLBMKKFDKI25TAPP3SRY54QZ5WDX6Q
-
-
-Note that we are currently using ~urn:erisx~ instead of ~urn:eris~ to denote experimental nature of the encoding. Once encoding is stabilized we will use ~urn:eris~.
-
-*** URN for blocks
-
-Individual blocks can also be addressed with an URN.
-
-There are many ways of doing this including:
-
-- [[https://tools.ietf.org/html/rfc6920][RFC 6920: Naming Things with Hashes]]
-- [[https://multiformats.io/multihash/][Multihash]]: As used in IPFS
-- [[https://github.com/w3c-ccg/hashlink][Hashlinks]]: Work by the W3C Credentials Community Group
-- [[https://github.com/hash-uri/hash-uri][hash-uri]]: Another specification draft.
-
-ERIS does not specify a particular way of addressing blocks.
-
-Note however that the we can not reuse the specifications above as the ERIS URNs do not only hold the hash value of the content but other information necessary for decoding the content.
-
-** Decoding
-
-Given a read capability the content can be decoded by following child references of the nodes in the Merkle tree starting at the root.
-
-Note that the level (encoded in capability) is essential for decoding the content as the nonce for decrypting nodes is computed from the level and count of node in level.
-
-Integrity of content can be checked while decoding by re-computing the hash value of block and comparing them to the references.
-
-*** Random Access
-<<random-access>>
-
-By decoding sub-trees specific ranges of the content can be decoded efficiently. This allows random read access to content.
-
-** Verifying
-
-The verification capability allows everything the read capability allows except decrypting of the data blocks and thus reading of the content.
-
-In particular a list of data blocks (and Merkle tree nodes) can be enumerated. This allows peers holding the verification capability to cache the content without being able to read it (plausible deniability for caching peers).
-
-The integrity of all blocks required to decrypt the content can be verified with the verification capability.
-
-** Limits on size of content
-<<limits>>
-
-#+BEGIN_QUOTE
-640K ought to be enough for anybody.
-
---- Misattributed to Bill Gates
-#+END_QUOTE
-
-The size of content that ERIS is able to encode is limited by the maximum depth of the Merkle tree.
-
-The maximum depth of the Merkle tree is 13 levels (including data block level). This is because for every internal node maps to a unique nonce of 12 bytes (see [[nonce][Nonce from position]]).
-
-The maximum size of content that ERIS can encode is thus $128^{13} \cdot 4 \mathrm{kB}$, more than $10^{20} \mathrm{GB}$.
-
-** On block size
-
-The block size of 4kB was chosen for following reasons:
-
-- Small content: Content smaller than 4kB still requires at least 4kB of storage as data block is padded to 4kB. A larger block size would make this worse.
-- Reasonable overhead when encoding large files: The number of nodes required to combine data blocks into a single root reference is proportional to the number of references a node can hold. As nodes should be indistinguishable from data blocks they need to be the same size. Choosing 4kB (128 32 byte references) results in an overhead of less than 1% of the content size (see [[size-of-merkle-tree][Size of Merkle tree]]).
-
-Using multiple block sizes has also been considered. We believe that the additional complexity (in deterministically choosing the right block size) is not worth the storage efficiency.
-
-** Implementations and Demo
-
-Implementations of ERIS are available for following programming languages:
-
-- [[https://gitlab.com/openengiadina/data-model/][Guile]]: The initial implementation
-- [[https://gitlab.com/openengiadina/js-eris][Javascript]]
-
-We have also implemented a JavaScript web application to demonstrate ERIS: [[https://openengiadina.gitlab.io/js-eris/index.html][Encoding for Robust Immutable Storage (ERIS)]].
-
-* Applications
-<<applications>>
-** Storage and transport layers
-<<storage-and-transport>>
-
-ERIS is agnostic of storage and transport layers for blocks and only requires the ability to store uniformly stored blocks and access blocks by their hash code (see [[cas][Content-addressable storage]]).
-
-Storage layers can be implemented with:
-
-- An in-memory hash-map.
-- A key-value store (the [[https://gitlab.com/openengiadina/data-model/][Guile implementation]] uses LevelDB)
-- A relational database
-- IPFS
-
-Blocks may be transported over network via:
-
-- HTTP(S): A HTTP endpoint can be used to dereference blocks.
-- Sneakernet: Blocks can be stored on a physical medium and transferred.
-- Peer-to-Peer networks
-
-*** IPFS
-
-[[https://ipfs.io/][IPFS]] is an existing peer-to-peer network for sharing data.
-
-By default IPFS does not provide any security mechanism, in the sense that content published on the network is world-readable. Content is split up into blocks and tied together using a Merkle tree (called UnixFS).
-
-IPFS implementations also provide an interface to directly store and access blocks by their hash value - a content-addressable storage.
-
-ERIS can use the IPFS block API as a content-addressable storage and have blocks transported from peer to peer via IPFS transport mechanisms. In that sense ERIS can be used as a secure alternative to the IPFS default UnixFS encoding of content.
-
-This has been implemented and tested in the [[https://gitlab.com/openengiadina/data-model/-/blob/master/eris/cas/ipfs.scm][Guile]] and [[https://gitlab.com/openengiadina/js-eris/-/tree/master/examples/ipfs][JavaScript]] implementations of ERIS.
-
-** Metadata
-
-ERIS does not encode any metadata about the content. Metadata that references the content can be separately encoded and stored.
-
-#+CAPTION: Which animals are most like each other?
-[[./images/duck-rabbit.png]]
-
-The image above can be encoded in ERIS and be referenced with the URN:
-
-#+BEGIN_SRC scheme :exports results
-(use-modules (eris)
- (web uri)
- (eris cas)
- (eris cas hash-table)
- (rnrs bytevectors)
- (rnrs io ports))
-
-;; The underlying storage for our cas
-(define backing-hash-table (make-hash-table))
-
-;; Create a cas from the hash-table
-(define my-cas (hash-table->cas backing-hash-table))
-
-(uri->string
- (call-with-input-file "./images/duck-rabbit.png"
- (lambda (port)
- (eris-put! my-cas
- (get-bytevector-all port)))
- #:binary #t))
-
-
-#+END_SRC
-
-#+RESULTS:
-: urn:erisx:AAAADEQ445USOXW3JWYK255G4CQABSGYHAOQB7WA46APBTRBNWFAXAOPMK6OOYEN73BNFVWR6YNU6YN2SFQPRCUOHXSOPIZKCULJTR5XP5QQ
-
-Which could be referenced from encoding of metadata:
-
-#+BEGIN_SRC js
-"image": {
- "comment": "A duck.",
- "href": "urn:erisx:AAAADEQ445USOXW3JWYK255G4CQABSGYHAOQB7WA46APBTRBNWFAXAOPMK6OOYEN73BNFVWR6YNU6YN2SFQPRCUOHXSOPIZKCULJTR5XP5QQ",
- "mediaType": "image/png"
-}
-#+END_SRC
-
-#+RESULTS:
-
-Somebody might however disagree and think this is more appropriate metadata:
-
-#+BEGIN_SRC js
-"image": {
- "comment": "A rabbit.",
- "href": "urn:erisx:AAAADEQ445USOXW3JWYK255G4CQABSGYHAOQB7WA46APBTRBNWFAXAOPMK6OOYEN73BNFVWR6YNU6YN2SFQPRCUOHXSOPIZKCULJTR5XP5QQ",
- "mediaType": "image/png"
-}
-#+END_SRC
-
-Both are valid descriptions (metadata) of the image. By not supporting metadata in the content such ambiguities can be handled without duplicating the content itself.
-
-The format in which metadata is encoded is also not prescribed. We suggest using an RDF based description that is well adapted for content-addressing (see [[./content-addressable-rdf.org][Content-addressable RDF]]).
-
-** Authenticity of content
-
-ERIS can be used to ensure integrity of content. To ensure authenticity we propose using a RDF vocabulary for Ed25519 cryptographic keys and signatures: [[./rdf-signify.org][RDF signify]].
-
-** Namespaces
-<<namespaces>>
-
-Namespaces are groupings of content that themselves have an identifier. The members of a namespace may be dynamic. Namespaces are a fundamental building block for organizing content and building applications.
-
-There are many legitimate ways of implementing namespaces. ERIS does not provide a built-in mechanism.
-
-In the following we give an overview of some mechanism and illustrate how ERIS can be used.
-
-We believe that a key value of ERIS is the usability from very different namespace mechanisms. A collection of ERIS encoded content can be served from a HTTP server or be added to a Secure Scuttlebutt feed. By referencing the same content with the same identifier from different systems we can make content interoperable.
-
-*** Centralized server
-
-A dynamic namespace can be implemented with a HTTP server.
-
-A ~GET~ request to a certain URL (e.g. ~/collections/example~) returns a list of references to ERIS encoded content. The URL is the identifier of the namespace.
-
-The members of ~/collections/example~ can be modified with ~PUT~ and ~DELETE~ requests (potentially authenticated).
-
-The server maintains the list of members in a database.
-
-This is how very many HTTP services work (including ActivityPub).
-
-*** Hypercore and Scuttlebutt
-
-[[https://github.com/hypercore-protocol/hypercore][hypercore]] and [[https://scuttlebutt.nz/][Scuttlebutt]] provide a secure distributed append-only log.
-
-References to ERIS encoded content can be added to such logs.
-
-Hypercore and Scuttlebutt can also be used as storage and transport layer for blocks (add the blocks to the append-only logs).
-
-*** Commutative replicated data types
-
-Commutative replicated data types (CRDTs) are data containers where operations to modify the content naturally reach consistent states [cite:shapiro2011comprehensive].
-
-There are many different CRDTs (e.g. a set or a register) with different characteristics.
-
-Together with the [[https://p2pcollab.net/#dromedar][P2PCollab]] project we intend to do further research in how CRDTs can be used for peer-to-peer collaboration.
-
-Previous work includes Dedalus [cite:alvaro2010dedalus] and Vegvisir [cite:karlsson2018vegvisir].
-
-** Filesystem
-
-It is possible to encode an entire file system in ERIS by first packing the files and directories in an appropriate container and then encoding and storing. This would allow similar functionality to IPFS (which uses UnixFS).
-
-Individual files can be accessed efficiently as ERIS allows random read access to content (see [[random-access][Radon Access]]).
-
-Possible container formats include tar or SquashFS.
-
-* Related Work
-** An Encoding for Censorship-Resistant Sharing (ECRS)
-
-ECRS [cite:Grothoff_2003] is the encoding used in the file-sharing application of [[https://gnunet.org/][GNUNet]]. ERIS is very much inspired by ECRS.
-
-Similar to ERIS, ECRS splits up content into uniform sized blocks (32kB) and combines them to a single root reference.
-
-Unlike ERIS, ECRS encrypts using the hash code of the block as a key (instead of a signle read key). Building the Merkle tree is simpler than in ERIS as there is no distinction between data blocks and tree nodes. However in addition to the reference to the block the key needs to be stored in a parent node (content-hash key).
-
-The reason for developing ERIS in contrast to just using ECRS is the verification capability. This allows blocks that are required to reassemble some content to be cached by a peer holding the verification capability, without being able to read the content.
-
-ECRS also provides two namespace mechanisms (SBlock and KBlock). Both mechanisms can be implemented with ERIS as well.
-
-** Datashards
-<<datashards>>
-
-[[https://datashards.net/][Datashards]] is a secure storage foundation for the web. Work on ERIS was inspired by Datashards. It provides means for immutable as well as mutable storage.
-
-Datashards (immutable) splits encrypted content into uniformly sized blocks (called chunks) and combines them in a hash list. There is no verification capability for immutable storage.
-
-Mutability is implemented with an append-only log (similar to Hypercore and Scuttlebut).
-
-A key functionality ERIS shares with Datashards is the usability from the web by encoding capabilities as URNs.
-
-Datashards is still in development and in further work we hope to converge ideas and encoding.
-
-** Cryptosphere
-
-[[https://github.com/cryptosphere/cryptosphere][Cryptosphere]] was an experimental research project for securely publishing and distributing content based on Tahoe-LAFS and Freenet (among others).
-
-The key innovation in Cryptosphere is the "repair capability" which allows enumeration of all block required to reassemble content as well as verifying integrity.
-
-To enable the repair capability two (linked) Merkle trees are constructed, one allowing read capability and one allowing repair capability.
-
-The constructions of the tree is slightly more involved than in ERIS.
-
-** Other
-
-Other related projects include Tahoe-LAFS and Freenet. We refer the reader to the ECRS paper [cite:Grothoff_2003] which provides an excellent description and comparison.
-
-* Conclusion
-
-#+BEGIN_QUOTE
-This is part of my reversing entropy plan - that hopefully will clear up the mess we're in.
-
---- Joe Armstrong, [[https://joearms.github.io/published/2015-03-12-The_web_of_names.html][The web of names, hashes and UUIDs]]
-#+END_QUOTE
-
-We present a scheme for encoding content that enables content-addressing, confidentiality and robustness. The key novelty is the verification capability that allows peers to cache the entire content without being able to read the content (as opposed to peers who do not hold any capability and only see uniformly sized blocks with random content).
-
-Furthermore we hope to motivate the usage of content-addressing for applications beyond peer-to-peer filesharing. ERIS is capable of encoding large files as well as small bits of content such as messages or notes on social media. In particular ERIS is useable with existing web technology and RDF (by providing an URN). Further work details how RDF can be made content-addressable with ERIS ([[./content-addressable-rdf.org][Content-Addressable RDF]]).
-
-We intend to implement the work presented in the context of the [[https://openengiadina.net/][openEngiadina]] project in order to enable offline-first and decentralized applications.
-
-Many thanks to Serge Wroclawski and Christopher Lemmer Webber (who are working on [[datashards][Datashards]]) for inspiring this work and discussions that shaped many aspects of ERIS. Thanks as well to TG (from [[https://p2pcollab.net/][P2PCollab]]) for the many pointers in the right directions.
-
-This work has been supported by the [[https://nlnet.nl/][NLNet Foundation]] trough the [[https://nlnet.nl/discovery/][NGI0 Discovery Fund]].
-
-* Appendix
-** Size of Merkle tree
-<<size-of-merkle-tree>>
-
-How big is the Merkle tree in relation to the size of the content to be stored? This relation captures the storage overhead and the computational overhead of the Merkle tree.
-
-The parameters are:
-
-- $s_h$: size of the hash code
-- $s_b$: block size
-- $s_d$: size of the data to be stored
-
-To simplify the calculations we assume that the block size is always chosen as a multiple of $s_h$:
-
-$$ s_b = k s_h $$
-
-Nodes in the Merkle tree have size $s_b$ and can hold at most $k$ child references. $k$ is the arity of the Merkle tree (in diagrams we have $k=2$).
-
-We also assume that the size of the data to be stored is a multiple of the block size:
-
-$$ s_d = n s_b $$
-
-$n$ is the number of blocks the data is split into.
-
-For example the data we want to store is split up into 8 blocks ($n = 8$) and two child references fit into a block ($k = 2$):
-
-#+CAPTION: Merkle tree with 8 data blocks
-[[./images/eris-merkle-1.svg]]
-
-We are interested in the number of nodes in the Merkle tree (the yellow boxes) in relation to the number of data blocks (white boxes).
-
-Let us call the number of nodes in the Merkle tree $m$.
-
-We can start counting the number of nodes in the Merkle tree from the top:
-
-$$ m = 1 + k + k^2 + k^3 ... + \frac{n}{k} $$
-
-At the root level there is one node, at the level below $k$ and below $k^2$ - at every level we go down there are $k$ times more nodes. At the bottom level (level 0) there are $\frac{n}{k}$ nodes (this is also $log_k(n) - 1$).
-
-$m$ is a geometric serie and can be simplified:
-
-\begin{align*}
- m &= 1 + k + k^2 + k^3 ... + \frac{n}{k} \\
- mk &= k + k^2 + k^3 + ... + \frac{n}{k} + n \\
- mk - m &= m(k - 1) = n - 1 \\
- m &= \frac{1}{k-1}(n-1)
-\end{align*}
-
-The size of the Merkle tree is linearly proportional to $n$ with $\frac{1}{k}$. In big O notation: The size of the Merkle tree is $O(\frac{n}{k})$.
-
-If we choose a block size that fits exactly 2 child references ($k=2$), the Merkle tree will consist of at most half the number of data blocks - the storage overhead is 50%.
-
-Assuming $s_h = 32 \mathrm{B}$ ($256 \mathrm{bit}$) we have following block sizes and storage overheads:
-
-| $k$ | block size | overhead |
-|-------+------------------+-----------|
-| 2 | $64 \mathrm{B}$ | 50% |
-| 32 | $1 \mathrm{kB}$ | 3.125% |
-| 64 | $2 \mathrm{kB}$ | 1.6% |
-| 128 | $4 \mathrm{kB}$ | 0.8% |
-| 256 | $8 \mathrm{kB}$ | 0.4% |
-| 512 | $16 \mathrm{kB}$ | 0.2% |
-| 1024 | $32 \mathrm{kB}$ | 0.1% |
-| 32000 | $1 \mathrm{MB}$ | 0.003125% |
-
-bibliography:refs.bib
-
-#+BEGIN_EXPORT html
-<p>
-<a rel="license" href="http://creativecommons.org/licenses/by-sa/4.0/"><img alt="Creative Commons License" style="border-width:0" src="https://i.creativecommons.org/l/by-sa/4.0/88x31.png" /></a><br /><span xmlns:dct="http://purl.org/dc/terms/" href="http://purl.org/dc/dcmitype/Text" property="dct:title" rel="dct:type">An Encoding for Robust Immutable Storage</span> by <a xmlns:cc="http://creativecommons.org/ns#" href="https://openengiadina.net/" property="cc:attributionName" rel="cc:attributionURL">openEngiadina</a> is licensed under a <a rel="license" href="http://creativecommons.org/licenses/by-sa/4.0/">Creative Commons Attribution-ShareAlike 4.0 International License</a>.
-</p>
-#+END_EXPORT