-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
tupelo:next #344
Comments
Another one: moving the |
oh and adding custom tags to the generated protobufs to omit empty in cbor |
adding the chain height index |
at which point we should consider "auto indexes" |
Would the plan here be to work out the other compatibility issues (including the slight error mismatch of your open pr + the cid change you mentioned) and then work towards pushing those changes upstream to eventually use upstream instead of the fork, or do you think we'd still maintain the fork going forward? |
Would the plan here be to work out the other compatibility issues
(including the slight error mismatch of your open pr + the cid change you
mentioned) and then work towards pushing those changes upstream to
eventually use upstream instead of the fork, or do you think we'd still
maintain the fork going forward?
I think the fast path here doesn’t need the error stuff and we can get full
performance by changing out the merkledag dagservice in the go-sdk (as shown in my loom video: https://www.loom.com/share/3e1e308b5c094e86861dfa6790838d8e)
|
this is pretty out of date by this point. |
We have a breaking data change coming for tupelo in form of supporting Conditions. Other breaking changes I'd like to explore:
** perhaps add a
version
field to TreeStateHamt:
The text was updated successfully, but these errors were encountered: