From: "Ludovic Courtès" <ludo@gnu.org>
To: guile-user@gnu.org
Subject: Re: Encoding for Robust Immutable Storage (ERIS) and Guile
Date: Wed, 09 Dec 2020 17:50:39 +0100 [thread overview]
Message-ID: <878sa6c49s.fsf@gnu.org> (raw)
In-Reply-To: 86ft4hg4qu.fsf@posteo.net
Hi!
pukkamustard <pukkamustard@posteo.net> skribis:
> I'm happy to announce guile-eris 0.2.0. This is a Guile implementation
> of "Encoding for Robust Immutable Storage (ERIS)" [1].
Yay, congrats!
> ERIS defines how an arbirtary sequence of bytes can be encoded into a
> set
> of uniformly sized blocks and an identifier (read capability). The
> blocks are encrypted such that the original content can only be
> decoded
> given the read capability. ERIS is a scheme for content-addressing in
> the sense that the read capability is deterministically computed from
> the content itself.
>
> This is done by splitting content into blocks, encrypting them and
> collecting references to blocks in a higher-level node (i.e. building
> a
> Merkle Tree). See the specification [1] for a detailed description of
> the encoding.
AIUI, this is exclusively convergent encryption, which is probably the
right choice for most applications anyway.
Block size is fixed; did you consider content-defined block boundaries
and such? Perhaps it doesn’t bring much though.
> Encodings like ERIS are common in protocols such as Bittorrent,
> GNUNet,
> IPFS, et. al. ERIS decouples the encoding from any particular protocol
> or application, allowing content to be referenced regardless of
> storage
> and transport layer. For example ERIS encoded content can be stored
> and
> transported over IPFS [2], but also over HTTP or via an USB stick.
The IPFS example is nice! There are bindings to the IPFS HTTP interface
floating around for Guix; would be nice to converge on these bits.
> ERIS is still "experimental". This release is intended to initiate
> discussion and collect feedback from a wider circle. In particular I'd
> be interested in your thoughts on applications and the Guile API.
Do I get it right that the encoder currently keeps blocks in memory?
Do you have plans to provide an interface to the storage backend so one
can easily switch between in-memory, Datashards, IPFS, etc.?
Thanks for the great work!
Ludo’.
next prev parent reply other threads:[~2020-12-09 16:50 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-07 12:50 Encoding for Robust Immutable Storage (ERIS) and Guile pukkamustard
2020-12-09 16:50 ` Ludovic Courtès [this message]
2020-12-10 8:27 ` pukkamustard
2020-12-11 8:10 ` Ludovic Courtès
2020-12-09 20:01 ` Christopher Lemmer Webber
2020-12-10 9:02 ` pukkamustard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=878sa6c49s.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=guile-user@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).