Hello,

I'm very happy to announce the release of python-eris version
1.0.0. python-eris is a Python implementation of ERIS.

Source code: https://codeberg.org/eris/python-eris
Documentation: https://eris.codeberg.page/python-eris/
PyPi: https://pypi.org/project/eris/

To install python-eris with pip:

```
pip install eris

Very nice! Thank you for sharing.

I've added your Common Lisp implementation to the list of
implementations at https://eris.codeberg.page/.

Regards,
pukkamustard


ykonai <mail@ykonai.net> writes:

> Hello,
>

Hello,

On behalf of the ERIS maintainers, it it my great pleasure to announce
the release of ERIS v1.0.0:

https://codeberg.org/eris/spec/src/tag/v1.0.0

ERIS defines an encoding of arbitrary content into a set of uniformly
sized, encrypted and content-addressed blocks as well as a short
identifier that can be encoded as an URN. The content can be reassembled
from the blocks only with this identifier

The rendered specification is available at http://purl.org/eris .

Hi!

I'm a keen follower of the Irdest project and personally interested in
LoRa. Thanks for your mail!

Katharina Fey <kookie@spacekookie.de> writes:

> In the best case Lora radio environment in the case of attempting to
> transmit a standard 1KB ERIS frame over Lora using reasonable framing
> and the maximum permissible 242byte MTU, frame transmission would
> require being split over 5 Lora Messages, which must be separated by
> (at minimum) 2 seconds each. This would require at least 10 seconds to
> transmit any Ratman message regardless of actual size.

Hello ERIS,

The Guile (https://codeberg.org/eris/guile-eris/) and OCaml
(https://codeberg.org/eris/ocaml-eris/) implementations now support
random-access decoding. That means that users can read specific
bytes at given offsets from some encoded content while de-referencing
only a minimal amount of blocks.

Applications include seeking in audio/video or detecting file-type with
some magic bytes at fixed position. See also an initial draft of ERIS-FS
(https://codeberg.org/eris/eer/pulls/2) - an encoding of a file system
that is optimized for ERIS (allows de-duplication of files) which
requires such random-access.

Hello,

It is my great pleasure to announce the release of ERIS v0.4.0:

https://codeberg.org/eris/spec/src/tag/v0.4.0

The rendered version is available at http://purl.org/eris .

This version contains significant changes to the encoding itself and to
the specification document. We hope to have addressed the feedback and
issues brought up towards version 0.3.0 of the specification. In
particular we hope to have addressed the issues raised during the Quick
Security Evaluation by ROS [1].

Hi,

I managed to implement Base32Check1 as well:

https://codeberg.org/eris/guile-eris/commit/5da08fe09c89b98a0f2486957a9757c0789013b5

I'm not sure I'm doing it right and don't quite grok the Algebra.

Some thoughts:

- Implementation effort is manageable and I think we could provide
  pseudocode that would make it easy to implement (e.g. by providing
  precomputed primitive powers).

pukkamustard <pukkamustard@posteo.net> writes:

> If there are no objections by anybody else, I will make the changes to
> the spec as proposed by Emery.

Pushed changes as bf894cf12d1e28a3c8ab6f76cc3e2e4ac8fae2f7.

Rendered document and updated test-vectors are available:
http://purl.org/eris

Happy hacking,
-pukkamustard

Emery Hemingway <ehmry@posteo.net> writes:

[..]

>> Would adding a CRC32 check value to the read-capability be an
>> alternative? Or using something like Base32Check? Both seems a lot more
>> involved than what you propose...
>
>
> I think a checksum is worthwhile, this was raised in the security audit
> but we haven't addressed it. Corrupting a URN would be a denial-of-service
> attack because it could result in a search for content that will never
> exist.

Emery Hemingway <ehmry@posteo.net> writes:

[..]

> Also correct (for "node" blocks).
>
> I recently looked at the internals of BLAKE2b and keying the hash adds
> and additional compression round, for 1KiB there are 8 rounds, 256 for
> 32KiB. It's minor but any optimization in the spec is magnified in
> practice.

Another reason to adopt the change.