path: root/doc
diff options
Diffstat (limited to 'doc')
1 files changed, 57 insertions, 8 deletions
diff --git a/doc/eris.adoc b/doc/eris.adoc
index ebe6e80..b8f5a2a 100644
--- a/doc/eris.adoc
+++ b/doc/eris.adoc
@@ -45,7 +45,7 @@ ERIS describes how arbitrary content (sequence of bytes) can be encoded into a s
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 <<_namespaces>> we describe how such functionality can be implemented on top of ERIS.
+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.
@@ -58,7 +58,7 @@ 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 <<_namespaces>>).
+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.
@@ -343,19 +343,68 @@ Note that using a single byte to encode the level limits the size of content tha
=== URN
-A read-capability can be encoded as an URN: `urn:eris:BASE32-READ-CAPABILITY`, where `BASE32-READ-CAPABILITY` is the unpadded Base32 <<RFC4648>> encoding of the read capability.
+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):
+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
-=== Namespaces
+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/eris/block-storage/ipfs.scm[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
@@ -459,14 +508,14 @@ This work is licensed under a http://creativecommons.org/licenses/by-sa/4.0/[Cre
=== 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.
- [[[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, https://openengiadina.net/papers/rdf-signify.html[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.
-- [[[content-addressable-rdf]]] openEngiadina. https://openengiadina.net/papers/content-addressable-rdf.html[Content-addressable RDF], 2020.
-- [[[rdf-signify]]] openEngiadina. https://openengiadina.net/papers/rdf-signify.html[RDF Signify], 2020.
-- [[[RFC7049]]] C. Bormann & P. Hoffman. https://tools.ietf.org/html/rfc7049[Concise Binary Object Representation (CBOR)], 2013.
+// - [[[RFC7049]]] C. Bormann & P. Hoffman. https://tools.ietf.org/html/rfc7049[Concise Binary Object Representation (CBOR)], 2013.