Skip to content
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

Define String representation of IntervalDigest #21

Closed
Wondertan opened this issue Mar 10, 2021 · 1 comment · Fixed by #48
Closed

Define String representation of IntervalDigest #21

Wondertan opened this issue Mar 10, 2021 · 1 comment · Fixed by #48

Comments

@Wondertan
Copy link
Member

@liamsi suggested printing IntervalDigest as CID in a private discussion, however that may require additional go-cid dependency for the lib. Anyway, we should define a concrete representation to ensure proper test coverage in the parent repo.

@liamsi
Copy link
Member

liamsi commented Mar 10, 2021

For context where this is coming from: the DA header will be part of the proposal soon (with celestiaorg/celestia-core#181), for debugging purposes the proposal can be logged out and a String() method will be called by the logger. My suggestion was mostly about adding a String representation for the DA header roots (row and col roots) as CIDs. This might be useful for debugging purposes, e.g. if we wanted the query a CID via an ipfs binary.

That said, this could also be achieved without modifying the NMT library: we can simply transform the hashes into a Cid in LL core.
Although nothing really speaks against making the NMT lib directly spit out CIDs I'm a bit hesitant as the concept of a Namespaced Merkle tree might be useful independent of LL and certainly independent of IPFS (Cids). I haven't seen any other project using it yet though. If we decide to make the library less general-purpose and more tied to LL-core, we can certainly make the NMT depend on CIDs as they already have a nice string representation for instance.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants