feat(registers): expose MerkleReg and add register_inspect example

[happybeing]

Description

Exposes the MerkleReg of RegisterCrdt in all Safe Register types to allow examination of the structure and history of changes to a register.

Adds a register_inspect example which displays nodes and their children for a register in a live network.

reviewpad:summary

[joshuef]

Thanks for this @happybeing! 🙇

This makesme wonder if merkle_reg is the best way to be exposing this. Do we want a clearer history API? perhaps? (merkle_reg feels a bit obscure.)

That said, maybe we want to still expose this at some level.

Hmm, I'm not sure. If you were approaching this task with no knowledge, what APIs might you have been looking for here? What were your first Qs before you got down to the merkle reg?

[happybeing]

I changed the example from register_history which was my intention, to register_structure because having scratched my head over how to get a history I began to think that you can't do this easily, and that it probably requires work in the application logic. Or at least that you need to know what the structure of the data is and include some history feature in that.

I have since looked at @bochaco's new folders PR (using register with pointers to chunks) to see what he's doing because I'm still intellectually challenged by the register stuff.

Following that I came up with a design that would allow me to modify his approach and include a history, by adding a root node with the current folder entries as it's children, on every change. Accessing the history would then involve traversing back from the riot node (singular) to the previous one and do on, and when you find the one you want, getting the state of its children.

I think that works (and BTW I think Gabriel's design can be made to support hard and soft links now that directories are first class objects - but that's an aside).

I may still just not understand how to use Registers to get history but maybe Gabriel can explain how he would implement a history function for his new PR? If that's different to my approach I'd be very interested to learn.

[joshuef]

riot node

I assume you mean root, but i love this.

---

Thanks for the background!

Yes registers are tough on the brainbox. I also am not super au fait with it either, which is what gives me pause about what APIs we want to expose (and with the merkle reg I think largely being an implementation detail?). So it's useful to dig into the practical use case...

So (if I attempt to paraphrase), an ideal API is one that can return the history of a given folder, at the moment?

Or: the history of a given entry ? Perhaps? Assuming that there could well be a fork in the register's entries that's as-yet unresolved?

Orr: something else?

[happybeing]

Yes 'root' 😂

And yes, history could be any of those, and if my understand is correct, that's partly why it will be hard to hide the APIs on the MerkleReg without restricting valid options.

Another reason is different use cases. As I understand it, there's no way to pop out a history without a) knowing how the app structures is data in the register and probably also b) without the app implementing the structure in a way that enables the history to be accessed in a sensible form (if at all).

If I'm wrong we can easily take the lower level APIs out as higher level ones make them obsolete.

Until my approach is validated or contradicted I'm reluctant to push forward to implement it. So I'm hoping for some feedback about that.

[joshuef]

Hmm, aye you're right, it probably is all more app layer and open to interpretation than I imagined. 🤔

In which case pulling out the merkle reg might be the only way to actually get into the details (including conflict resolution at the CRDT layer.. thats really app centric).

[joshuef]

I think we can get this in for now.

But @happybeing we'll probably want to get some other APIs built out for this down the line (as we figure out how folk are going to use this), perhaps in place of exposing the full merkle-dag allowing some simple functionality atop it.

So if you're agreed can we document that this is an unstable API (at all layers), probably noting that intention to develop some more ergonomic APIS for common use cases to (probably) avoid exposing this down the line?

[happybeing]

I was going to suggest that so 👍

When you say "we" do I need to modify the PR in some way?

[joshuef]

When you say "we" do I need to modify the PR in some way?

Ahh, yes sorry, it twas the royal we as in The Project :D

So only change I'd look for is a note on the merkle_dag APIs to note that they are unstable. If you can get that in, then we can get this in 👍

[happybeing]

@joshuef Is there a way to mark APIs as unstable?

So to use this you'd have to use --feature=unstable or something. If so, would you prefer the latter?

[joshuef]

I'd just note in the docs on the function at the moment. Nothing more than that

[happybeing]

@joshuef all done but the CI tests are broken I think.

[joshuef]

Aye, seems like the chocolaty repo is down at the moment :(

[joshuef]

changes look great, thanks @happybeing ! 🙇

[happybeing]

The only failure now seems to be a bug in the tests:

error: test failed, to rerun pass `-p sn-node-manager --test upgrades`
test upgrade_to_latest_version ... FAILED

failures:

failures:
    upgrade_to_latest_version

test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 3 filtered out; finished in 3.73s

[happybeing]

@joshuef phew, all done!

[joshuef]

Excellent! 🙇