(Question) Drop Invalid Entries?

[zaptrem]

If I want to create a database that stores signed Ethereum messages, is there a way I can make my web application ignore/refuse to store or propagate messages that it finds to be invalid from updates from other IPFS nodes/web clients? I want to prevent spam attacks while still allowing anyone to post signed Ethereum messages to the database.

[fazo96]

I'm not a contributor, but it looks like the only check performed is the validity of the signature (every entry is signed by who wrote it) and also whether the key that signed the entry is allowed to write.

The code is here: https://github.com/orbitdb/ipfs-log/blob/master/src/log.js#L235

It runs every time two logs are joined (when you are merging data from another peer) and in case one of the entry is not valid it just does not join the logs, which is good because it means the invalid content should be thrown away.

However I can't find any hook for custom validation logic. Also it's important that whatever custom logic would be used stays deterministic, there would probably be bad consequences to ending up with a different state than other peers

To implement this feature we would need to update ipfs-log to allow custom validation logic per entry, and then update the dependants all the way up to orbitDb so that the custom validation logic can be passed down

[thiagodelgado111]

As a sidenote, there are wallets (e.g hardware wallets, metamask) that won't give you access to pub/private keys so that would probably mean a change to the keystore API too (orbitdb-archive/orbit-db-keystore#3) as well as ipfs-log.

[aphelionz]

Moving to Field Manual for more discussion

[zaptrem]

What’s field manual?

[aphelionz]

A work in progress book about OrbitDB: https://github.com/orbitdb/field-manual

[zaptrem]

Cool. Can you paste the link to the new discussion here?

[aphelionz]

This is the new discussion :) I simply transferred the issue

[zaptrem]

Nice, thanks.

[kronosapiens]

I'm having a similar question when reading about authentication -- seems like authentication doesn't occur when a user updates their local version of the db, but rather occurs redundantly whenever two peers connect (i.e. the db doesn't authenticate me, but I authenticate all of my peers). That could be emphasized a bit more in the field manual IMO.