Action signature hashes (anti-tampering)

[grrowl]

I've released a Component-based userland solution. It generates an ed25519 privateKey on mount, and passes down the functions signMessage, verifyMessage and generateKey to its children as props.

• [pro] Totally userland, enables flexibility in signing, validating, etc.
• [con] Can't invalidate actions which fail validation at the scuttlebutt level.
  • Which means invalid actions may fail at a reducer level, but still be communicated to peers
  • We'd either introduce latency to communicating actions to peers, or replay potentially invalid messages ASAP.
• [fact] It takes about 1ms to sign a message, but about 6ms to verify the signature.
  • That's too slow for synchronous validation. Might be within the realm for redux-scuttlebutt to async validate
  • How far do we take this? on start we may receive 1000s of actions.
  • We could play the action immediately, and asynchronously validate actions from a queue, remove the invalid actions from history
  • ...and only replay validated actions?

What would be the perfect API for this feature? Does it belong in redux-scuttlebutt or does it make sense as an auxiliary module?

[grrowl]

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

[grrowl]

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.

[grrowl]

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