[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Encoding for Robust Immutable Storage (ERIS)
From: |
Cy |
Subject: |
Re: Encoding for Robust Immutable Storage (ERIS) |
Date: |
Sat, 11 Jul 2020 06:39:01 +0000 |
On Fri, 10 Jul 2020 08:59:17 +0200
pukkamustard <pukkamustard@posteo.net> wrote:
> Hello GNUNet,
>
> I'd like to request feedback, questions and comments on an
Okay, but you asked for it! (Disclaimer: I'm not any big smartie in GNUnet,
just some
layabout in the peanut gallery who's been here forever)
> for Robust Immutable Storage (ERIS)
Oh. I see what you did there...
> ** Verification capability
An intriguing and very tricky and dangerous idea. We want intermediates to be
able to
analyze our content, so that they can do things like ensure the entire hash
tree is
cached, rather than just a few scattered messages in it. We want them to be
able to tell
where to route messages, for optimal network performance.
But the "privacy/complexity/availability trade-off" is very real, and must be
carefully
considered. If a malicious node were capable of verifying all blocks belonged
to a
certain hash tree, what kind of mischief could they get up to?
* Assuming it's publically distributed, they can already spy on entire hash
trees in ECRS,
just by downloading the hash tree, and listing all the encrypted hashes it's
composed of. So that wouldn't be a greater risk.
* Privately distributed hashes only shared with friends can't be analyzed in
ECRS, but
enabling that analysis, surveillors would only be able to tell how big it
was, not
the content of the data.
Not sure what other implications there might be. It doesn't double the size of
each entry
in a hash tree block, does it?
> ** Block size
>
> Block size is chosen to be 4kB. This an optimization towards small
> content (short messages and social interactions).
Keep in mind block size is MAXIMUM block size. So if you set your block size to
0xFFFF
(66K) then you send around a bunch of 4kb blocks, it'll be just as optimized as
if you
set the limit to 4K. Block size should be set to what the network is capable of
handling,
rather than average message size. Multiple messages could be packed into a
single block
too.
Oh also keep in mind that microblogging is cancer.
> ** URN
>
> Encoded content can be referred to by a URN making it usable from
> existing Web (and RDF) settings. This could be added to ECRS.
Have you heard of the gnunet schema?
gnunet://fs/sks/[identity key]/keyword
gnunet://fs/chk/[content hash] (/arbitrary_filename.jpg if I had anything to
say about it)
gnunet://fs/ksk/[keyword]
> There are currently no SBlock or KBlock like features.
Some people think CADET would be better, where you could only perform searches
over a low
latency connection with computers that are provably online. But either way,
those things
are absolutely vital, and cannot be requested by content hash. So be careful.
> We have a little JavaScript demo:
> https://openengiadina.gitlab.io/js-eris/ . As well as
> implementation in Guile [2].
Isn't guile that byte compiled scheme that has no tail recursion? At any rate,
I wish you
luck, no matter what language you write it in.