Custom Entry verification function

[fazo96]

Hello, like last time I need this for my current use case:

Everybody can write to my log through orbit-db, and I see that in the code there is an async validation function for each Entry.

How about exposing a way to add custom validation to each Entry? I need a way to make sure that my nodes don't end up replicating entries with malformed information: even though anyone can write to my db I have a few rules about what kind of data is valid. This could also be used, if anyone wants to do so, to implement for example a proof-of-work required to write to the DB.

Thoughts?

[haadcode]

@fazo96 in short: yes! :) This is something we've been wanting to implement for quite some time and will do so at some point. However, this is a bit more complex topic that effects various parts of the system so doing it correctly will take some time.

But to get started and as a first implementation, passing a "onVerify" or smth function to the log which then gets called upon verifying the entry would be a good solution as you propose. Would you want to work on it and submit a PR?

Is proof-of-work based data addition your specific use case for this? Is every update to the DB required to have a corresponding entry in a ledger or are you thinking that there's one entry in the ledger against which all writes to the DB get verified against?

[fazo96]

I am working on the Chlu implementation and as part of that, we are using orbit db to keep track of the list of review records that customers submit to the network as well as their updates.

IPFS is immutable but review records can be updated, so I wrote a custom orbit-db store that accepts two operations:

• ADD_REVIEW_RECORD with a multihash for the RR
• UPDATE_REVIEW_RECORD with a multihash for the new RR and a multihash for the previous version

Then the store at the moment uses an array for the list of original review records and an object to keep pointers from old version to next, so that the latest version can be resolved using an old one.

This is working great, but the problem is making sure the review records are valid. There is no proof of work involved but the process of validating a RR is quite complex and it includes binary deserialization, checking various signatures, fetching multiple IPFS objects, calculating hashes etc.

I also need to check that the "new version" field in the update is actually an update of the "old version" and not something different.

We have it already implemented, but it needs to be called during the updateIndex to make sure the operations contain valid data.

I'll try to look at this today and see if I can pass the onVerify function somehow :)

Another question, is there the possibility of refusing (not joining and not advertising) a log if it has invalid entries?