unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
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’.




  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).