On Fri, 10 Jul 2020 08:59:17 +0200 pukkamustard <[email protected]> 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.
