Add Identity Update Builder

[neekolas]

tl;dr

• Adds IdentityUpdateBuilder and SignatureRequest structs, used to create batched Identity Updates

Design decisions

There were a few constraints on the design that made this a tricky one to implement.

• These are batch signatures. An IdentityUpdate may contain several actions, each requiring one or two signatures. But each of those signatures are against a signature text derived from the entire batch. So, we need to gather an outline of all the updates before we can start collecting signatures.
• Passing signers over the FFI barrier has proven complicated in the past. Some signers are synchronous, some are asynchronous. The caller doesn't necessarily have all the signers available every time they use libxmtp, so they may have to prompt the user before they can get a signature. The most versatile solution is to have a "signature request" that goes over the FFI barrier to platform SDKs, and have the SDKs return the serialized bytes.

Usage

        let account_address = "0x1234".to_string();
        let nonce = 0;
        let inbox_id = generate_inbox_id(&account_address, &nonce);

        let mut signature_request = IdentityUpdateBuilder::new(inbox_id)
            .create_inbox(account_address.into(), nonce)
            .add_association("0x5678".to_string().into(), account_address.into())
            .to_signature_request();

        for missing_signature in signature_request.missing_signatures() {
            signature_request.add_signature(somehow_get_signature_maybe_this_happens_over_ffi()).expect("should succeed")?;
        }

        let identity_update = signature_request.build_identity_update()?;

[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

[neekolas]

Merge activity

• Apr 8, 12:10 PM EDT: Graphite rebased this pull request after merging its parent, because this pull request is set to merge when ready.
• Apr 8, 6:57 PM EDT: @neekolas merged this pull request with Graphite.

[insipx]

Can we consume self here, or is there a benefit to keeping the intermediate builder around?

[neekolas]

Good call. I don't think you'll want the builder once this is done, so might as well consume self.

[insipx]

Would it make sense to rename this SignatureRequestBuilder

Right now it looks like

let x = IdentityUpdateBuilder::new()

let x = x.to_signature_request()

x.build_identity_update()

---

But to me it makes more sense to build a SignatureRequest from a SignatureRequestBuilder which then resolves into a IdentityUpdate

like

let x = SignatureRequestBuilder::new()
let x = x.build()
/* platform SDK magic */
let identity_update = x.resolve()

[neekolas]

I think that's a good suggestion. I'll rename.

[insipx]

The SignatureField enum here is a little confusing --

in IdentityUpdateBuilder we assign a PendingSignature with a SignatureField so that later in build_action we can retrieve the correct PendingSignature address/identity to compare it with the recovered signer from the given Signature.

I guess I'm ok with this, although i wish there was a more clear way to express/organize that code-wise. Will keep thinking about it, would be nice to have some docs explaining it on SignatureField though

[neekolas]

Agree it's not the most intuitive. Batch signatures in general are a little confusing.

At the very least, I'll add some clarifying comments. And if we find a better way to structure the code we can refactor later.

[richardhuaaa]

This is a really elegant way to implement batch signatures. Seconding @insipx's comments to make it easier for others to understand.

Also, from the example code:

        for missing_signature in signature_request.missing_signatures() {
            signature_request.add_signature(somehow_get_signature_maybe_this_happens_over_ffi()).expect("should succeed")?;
        }

I think we can build higher-level API's over this before exposing to FFI. Rough sketch:

register_inbox_and_installation_key(Option<RecoveryAddress>): TextToSign; // installation key signature handled internally. Does not register inbox if inbox already exists
associate_external_wallet(): TextToSign; // installation key signature handled internally
... etc.

[richardhuaaa]

Oof, didn't realize it was auto-merge @neekolas