Action signature hashes (anti-tampering) about redux-scuttlebutt HOT 3 CLOSED

Add verifyAsync option

• expose option verifyAsync: function (action, cb)
  • cb(true): verified message
  • cb(false): invalid message, remove it from _updates.
• expose option verifyStrict: bool to withhold unverified messages from replaying to peers
  • it will probably still have to influence the logical clock. we can't roll it back.
• [wish] allow dispatching before validation, even when verifyStrict is false
  • we'll have to increment the logical clock, even for invalid actions; or play the message with a made-up logical timestamp
  • if we're strictly validating actions, they shouldn't ever increment the logical clock

questions

• on cb(true), do we replay that action with meta.@@signature/VERIFIED: true
  • orderedHistory says yes: keeps all history states in line with the latest reality
• on cb(false), pretend like that action never happened.
  • if verifyStrict, simply drop it from _updates
  • if not verifyStrict, remove it from history
  • seems like this gets in the way of the _updates/orderedHistory merge work

from redux-scuttlebutt.

Related discussion, "Why syncing actions instead of data model?"

There's also a bit of talk about CRDTs which don't really require the time travel functionality we've implemented, but they're not hurt by it. Currently, an action like ADD_MESSAGE can simply return state.concat(message) (that is, push it onto the state array) and even outdated/old actions from remote peers will be inserted at the correct position in the array.

from redux-scuttlebutt.

With dispatcher options verifyAsync and signAsync added, message signing and validation can be enabled by other modules (such as the in-progress redux-signatures)

from redux-scuttlebutt.