tupelo:next

[tobowers]

We have a breaking data change coming for tupelo in form of supporting Conditions. Other breaking changes I'd like to explore:

• transactionID on the CurrentState (to become TreeState) to be the CID of the cbor serialized AddBlockRequest
• support conditions (CurrentState => TreeState, etc)
  ** perhaps add a version field to TreeState
• EXPLORE: keep tupelo currentState in a hamt

Hamt:

• HAMT back to being cbor and using the new fastpath that whyrusleeping has added (and my own change in go-ipld-cbor) fastpath CBOR ipfs/go-ipld-cbor#64 https://github.com/ipfs/go-hamt-ipld/pull/29
• HAMT only storing CIDs in the HAMT itself (not the actual objects)
• FastPath CBOR for all the types we know about ( https://github.com/whyrusleeping/cbor-gen )
• keep AddBlockRequest out of the hamt and rely on bitswapper (requires current state to refer to a CID)

[zonotope]

Another one: moving the Token and related structs to protobufs in the messages repo

• Token type
• TokenMint type
• TokenSend type
• TokenReceive type

[tobowers]

oh and adding custom tags to the generated protobufs to omit empty in cbor

[brandonwestcott]

adding the chain height index

[tobowers]

adding the chain height index

at which point we should consider "auto indexes"

[zonotope]

• HAMT back to being cbor and using the new fastpath that whyrusleeping has added (and my own change in go-ipld-cbor) ipfs/go-ipld-cbor#64 ipfs/go-hamt-ipld#29

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?

[tobowers]

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)

[tobowers]

this is pretty out of date by this point.