resolver.put allows you to create invalid blocks about js-ipld HOT 11 CLOSED

@diasdavid okie! test added

from js-ipld.

@vmx just getting this on your radar :)

from js-ipld.

Thanks for reporting this bug. It is a fun one indeed!

A simple (and I believe to be the wisest) solution would be to make a copy at the beginning of put, however, that would force us to add a copy function to the interface-ipld-format so that we know how to make a 1:1 copy of any format.

Mind submitting a PR with a test?

from js-ipld.

Hmm do we need a ipldXResolver.clone method?

from js-ipld.

@kumavis if we go with that solution, then yes

from js-ipld.

Hmm do we need a ipldXResolver.clone method?

i think i would argue against it since we have serialize. Which is copying in a sense. If we serialized once then hashed the serialized data instead of serializing twice then invalid blocks coudn't be generated

from js-ipld.

@wanderer it would work for this case, yes, but getting .copy would prevent other weird scenarios int he future. We can: a) solve this by taking in your proposal -- ipld/interface-ipld-format#7 -- and b) keep considering adding .copy to interface-ipld-format.

from js-ipld.

@diasdavid in which case would this not work? I can't think of anything off the top of my head. But if there are things that mutate the serialized version somehow then i guess we could aslo specify that serialize does a copy

from js-ipld.

It will work 👍

from js-ipld.

ipld/interface-ipld-format#32 will resolve this. cid will take the serialised output not the dagNode.

from js-ipld.

As cid() is now taking the serialized version of a node, that's not an issue anymore.

from js-ipld.