Volker Mische

Either layout is fine, I'd KISS and just have non-nested values. This also makes it easier if you e.g. write your own tooling and you want to convert it quickly...

> package multicodec > > const ( > Identity = 0x00 // raw binary > CIDv1 = 0x01 // CIDv1 > [...] Did you mean `package ipldcodec`? If yes, this...

@mvdan sorry, I misread the original issue. Just ignore my comment, what you say makes sense. Though I'm still not sure (as in "really not sure" and not in "don't...

> `aes-256-gcm`, `aes-128-gcm`, etc.? This is really a rabbit hole. I'm not deep enough (and hopefully won't get any deeper) to have a strong opinion about it. Though having three...

> If complexity of API is of concern it would probably be best for cid to do the extra logic at runtime for the time being. This aligns with my...

> im considering if supporting utf over 1 byte is worth it. I don't think it's worth it. Base encodings are usually ASCII, which is also often the point of...

Thanks, all this sounds good to me. > We will likely need a new `Code` enum for no_alloc encoding Is this because you need different implementations of the same functions...

I'm in favour of reducing the burden on implementers. If it turns out that there's a base encoding that isn't part of the spec yet, we can add it later...

> I think we should continue accepting any-case strings in any context where DNS or other case-insensitive-by-the-book systems are being interfaced. Yes, but wouldn't this be a level higher than...

> If anything the extra `lc()` operation introduced everywhere is an extra performance hit. You could argue that it's a performance hit doing it on the lowest level, even if...