Steven Allen
Steven Allen
First off, I completely agree that this is a massive pain-point and we need to clearly define what users can and can't do. > No hard size limitations anywhere. I'm...
Ah. I see what you're getting at. Yes, the *serializers* and *deserializers* should work with arbitrary objects. As far as I know, we *don't* have any limits in go-ipld-*, right?...
We should probably make registering codecs easier but there's a bit of a tradeoff here: We *don't* want users abusing codecs as "types". I'd rather have a user come and...
Note: this is *slightly* better than the multiaddr case. There are a ton of existing and new network protocols that we want to be compatible with.
> But my biggest concern is just having older versions of things not blow up on totally valid new codecs that just aren't in the older version. So, we shouldn't...
> Also, I want to be clear that I'm talking about the block level API, not the dag level API. It may be appropriate to fail when asking the DAG...
The usual way to do this is to just create a new DAG and point to the old DAG. This will duplicate _some_ data but only in the changed IPLD...
That significantly harms discoverability, I quite frequently go to one of our orgs wondering " do we have an implementation of X in Y language?". Can we not just put...
@warpfork does refmt canonicalize the number types?
Yeah, it looks like python is using the canonical encoding and we aren't. We really need to make a decision here.