Association History Processing (Part 2)

[neekolas]

Summary

• Adds the actual association log and verifications
• Adds a bunch of tests

TODO

• More tests coming
• Verify all logic in the XIP is identical to the implementation
• Serialization and deserialization
• Actual signature types

[neekolas]

• IdentityUpdate serialization #633 : 2 dependent PRs (#642 , #647 )
• Add Identity Update Builder #632
• Add Unsigned Identity Updates #620
• Association History Processing (Part 2) #618 👈
• Association History Processing (Part 1) #617
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @neekolas and the rest of your teammates on Graphite

[insipx]

This seems good to me -- in an ideal world i'd like to see less boxing, but I like the builder-esque strategy of the IdentityAction interface for the log actions.

[insipx]

does it make sense to handle an Other(String) kind?

For instance, in the case that someone wants to implement their custom signature type, or would that break too many assumptions?

[insipx]

Are we boxing all these Signatures to make it easier for ffi?

[neekolas]

Mostly out of expedience, although I think it does make FFI easier.

If we can come up with an unboxed solution that works everywhere I'm all for it.

[neekolas]

Merge activity

• Apr 5, 8:03 PM EDT: @neekolas started a stack merge that includes this pull request via Graphite.
• Apr 5, 8:04 PM EDT: Graphite rebased this pull request as part of a merge.
• Apr 5, 8:09 PM EDT: @neekolas merged this pull request with Graphite.