Hi Andrew,

It was me that forked codeberg.org/eris/eris-go from Cory Slep and
I'm happy to see another Go implementation. My version is bloated,
I wont deny that. I'd like to do a performance comparision and look
at what it would take for my implementation to use yours as its
core. I think seperating the core and the outer parts that depend
on external libraries would be better engineering.

I agree that writing again but more constrained is fun and should
be reason enough. I think everyone who was involved with the spec
is glad to know that people are still eager to write their own
even if they have implementations available.

Hello followers,

The eris-go implementation has been updated to support the latest version
of ERIS-FS. This includes creating ERIS-FS capablities, extracting the
contents of ERIS-FS, and a transparent FUSE interface.

There is also a proper manpage for the command-line utility:
https://codeberg.org/eris/eris-go/src/branch/trunk/eris-go.1.md

Hail ERIS,
E.

Support the QOI lossless image format by lifting a header from the
reference implementation.

https://qoiformat.org/
---
 AUTHORS           |   1 +
 README.md         |   1 +
 meson.build       |   1 +
 src/backend_qoi.c |  84 ++++++++++++++
 src/backend_qoi.h | 272 ++++++++++++++++++++++++++++++++++++++++++++++
 src/main.c        |   3 +
 6 files changed, 362 insertions(+)
 create mode 100644 src/backend_qoi.c
 create mode 100644 src/backend_qoi.h
[message trimmed]

Dear list,

I have made a proposal for encoding ERIS read capabilities in small files that are easily
stored on a file-system or exchanged across email or chat messaging channels[0]. The intention
is to create a format that is easy to handle with typical "user-level" software and should
be designed for a plurality of integrations, free-software or otherwise.

There is a working prototype in the Nim implemention of ERIS[1] that supports creation of
link files[2] as well as opening [3] files as HTTP streams in locally configured applications.

If there are any comments or suggestions please let them be known on the EER issue tracker.

Hail Eris,
Emery

Dear list,

We now have an ERIS server that we consider "industrial-grade" and ready to use. It supports
CoAP/CoAP+TCP[0] as well as well as fetching blocks and URN decoding over HTTP[1].

The server is written in conservative Go and is available here: https://codeberg.org/eris/eris-go
We have a package available in Nixpkgs and in our ERIS flake we have NixOS module for hosting the
server[2].

Any effort in packaging for other distributions is appreciated.

The server uses a simple LMDB-like database to store blocks. It also supports storing and retrieving
blocks over CoAP connections and can act as a proxy in this regard. Experience in using the server in
a meshed mode is limited, and we welcome a discussion on how to efficiently cache and replicate

Excerpts from pukkamustard's message of April 25, 2022 2:14 am:

> What you propose is to only use the convergence secret at level 0 - at
> leaf content blocks:
> 
> ENCRYPTION_KEY := Blake2b(CONTENT, key = CONVERGENCE_SECRET)
> ENCRYPTED_CONTENT_BLOCK := ChaCha20(CONTENT, ENCRYPTION_KEY, NONCE)
> 
> And for intermediary node blocks the unkeyed Blake2b function is used
> (convergence secret is not used):
> 
> ENCRYPTION_KEY := Blake2b(CONTENT)
> ENCRYPTED_NODE_BLOCK := ChaCha20(CONTENT, ENCRYPTION_KEY, NONCE)
> 

Hello list

I have a proposal to consider for the erisx3 encoding standard. Before
noticing the problem with decoding trees at the incorrect depth our reviewer
raised an issue that URNs are un-verifiable. Corruption of URNs during
copy-pasting or by an attacker is undetectable without concluding that a
block reference cannot be retrieved. I believe there is a fix that would
solve this problem.

In the current standard there are two essentially different hash functions:
- BLAKE2b with an 128-bit output size and a 128-bit salt. The output of this
  function is a block *key*. Anyone with the key can encrypt or decrypt the
  block, but the key can only be generated by having both the block content
  and the salt. Keys cannot be reliably verify a block, because there is

Hail Eris,

The ERIS spec has recently gone through a security review (more details
on that later) and as a result we have some good and bad news. The bad
news is there is a flaw in the ERIS spec that can lead to a leak of
plaintext data. The good news is we think we have a migation and we can
still make breaking changes to the spec without affecting anyone.

To understand the flaw, imagine an ERIS implementation is dereferencing
a URN. The URN refers to a tree of zero depth, that is a single content
block. Imagine that the block depth byte of that URN suffers a bit
flip, it could be a malicous flip, a programing error, or a rogue
high-energy particle. It doesn't matter which bit was flipped, but the
depth is now higher than it should be. The implementation fetches the

On Sunday 10 October 2021 18:18:43 CEST, pukkamustard wrote:
> What was the use-case you had in mind? And could the problem you
> describe solved in other ways?

My use-case would be some application or system service that produces or
consumes data optimized for ERIS, such as file-system archives or
memory snapshots.

I think you are right that what I've suggested is ambiguous and
unnecessarily complex. What I want is to be create and access blocks
without any padding, which would be possible if an application has
access to a raw block interface. I think this would be reasonable in a
few cases, but these "raw" blocks would not be representable with URNs.

As a systems programmer I am a little bothered by the use of padding
blocks for data that is aligned to an ERIS block size. In the worst
case, a 32KiB blob would be encoded using 96KiB, one block of data,
one block of padding, and one block of Merkle tree.

I propose that a blob of data with a length aligned to its encoding block
size should omit padding if the last byte of the blob is not '0x80'. If
the last byte of the last block is '0x80', then this final byte is
treated as padding. If the final byte of the blob is '0x80', then a block
with byte '0x80' followed by zeros is appended as padding (as usual).

Would this be sufficiently unambiguous?
Emery