Mikeal Rogers

> Maybe you can add a security guidelines section though, for example never reuse keys, only use secure algorithms etc.? We captured some of this in exploration reports but we...

This is primarily in response to @aschmahmann but it’s a little broader than the scope of the thread it’s in so I’m doing a top level post about it. In...

Big spec update to bring it inline with my last comment. Collapsed into a single block format that describes the cipher and iv length in the block format.

Languages typically have easier, and faster, conversions from lists to sets than maps to sets, so I’m not sure representing them as a map is better/easier. I’m -1 on adding...

We may have compressed our notes a few times on this but we are still lacking a written resource other than “read these threads.” We definitely need a clearer and...

I already have to force a consistent key ordering in `dag-json` in JavaScript. It sucks but it’s necessary.

> While currently a side effect of bitswap/libp2p, the main reason for introducing the concept of blocks is that they have a known finite size. An ipld library should be...

> So the bitswap protocol should specify the max block size? It's an important thing that needs to be specified somewhere. I agree completely. From most of the usage I’ve...

Whenever we’ve tried to come up with generic recommendations for block size we end up with a lot of “it depends 🤷‍♂️“ because we can all imagine situations where even...

I’m fine w/ 1m as the recommendation, but I don’t think we should enforce it in any of the codecs like we once did in ‘js-dag-cbor’. -Mikeal ________________________________ From: Steven...