re: 0006: Is `prevData` redundant information?

[DavidBuchanan314]

To make it possible to validate individual #commit messages in isolation, the previous data CID is included in the new prevData field on the message. This field is not authenticated (signed), and still needs to be verified against the actual previously seen data value.

If you need to verify it against your last-seen value, why does it need to be sent in the first place, rather than having the consumer just use its last-seen value?

I can imagine you want to detect desyncs, but shouldn't the since field (referencing the previous commit's rev) also achieve this?

[bnewbold]

It is a bit redundant! We are including and effectively requiring it because we want it to be easy to untangle two distinct failure modes:

1. the operations do not invert successfully against the included MST blocks, based on the prevData included in the commit itself. We think these will not be uncommon as sync 1.1 rolls out and folks do their own PDS and MST implementations; it is an implementation error. It is nice to have clear self-contained error cases: "this commit failed to validate" without any other state.
2. the prevData does not match the actual previous commit's data CID. while this could conceivably be an implementation error, we expect this to result from operational mistakes: power outage without full filesystem data sync, dropped/corrupted packets, weird migration cases, etc

[devinivy]

And notably, the sync 1.1 responds to those cases quite differently:

• implementation error: drop these events on the floor.
• operational error: sync with the new state of the repo.

The "operational error" condition would still need to pass other checks, e.g. processing an old event would not cause the consumer to sync with the past state of the repo—it would be dropped since the rev would have appeared to move backwards.