Feature Request: Add a pre-merge validation hook to CRDT data

[cryi]

Hi there,

I'd like to propose adding a way to validate CRDT deltas before they are applied. For our use case, we need to ensure state integrity by checking signatures that are included in the protected data blobs - not all the data, but some of them. Currently, it seems there isn't a straightforward way to register a custom validator to do this.

I've looked into the code, and it seems like the ideal place for this check would be in the crdtNodeGetter in ipld.go#L48. The main challenge is that crdtNodeGetter is private, and there's no way to inject a validation function into it.

I considered a workaround by wrapping ipfslite.Peer and its GetMany method, but that doesn't feel like the right approach.

My proposed solution is to add a new option to the CRDT that accepts a delta validator similar to the PutHook. This validator would then be passed into the crdtNodeGetter and executed after a delta is fetched, but before it's applied, possibly returning validation error.

What are your thoughts on this approach? If this sounds like a good direction, I'd be happy to put together a PR.

Thanks!

Edit: It may be useful to be able to ban/blacklist nodes providing invalid deltas but I am not sure whether it is possible from position of ipfslite.Peer.

[hsanjuan]

I have some code to allow plugging in custom Deltas. In which case you could do whatever when Unmarshaling them, including having deltas with additional fields etc. Would that work for you?

[hsanjuan]

Looks a bit like:

// Delta represent a CRDT changeset, it carries new or updated elements and new or updated tombstones. The priority value allows comparing this update with others, to determine which elements take precedence.
type Delta interface {
	GetElements() []*pb.Element
	GetTombstones() []*pb.Element
	GetPriority() uint64
	SetElements(elems []*pb.Element)
	SetTombstones(tombs []*pb.Element)
	SetPriority(p uint64)
	Size() int
	Unmarshal([]byte) error
	Marshal() ([]byte, error)
}

[cryi]

Yes, that would likely work. However, after some research, I've realized our immediate need is for a state-based CRDT, not a DAG. I'm currently exploring the available options.

We can revisit this approach later when more advanced tracking is required, preferably once issue #249 has been resolved too.

Feel free to close this issue for now.