PublicKey vs SignedPublicKey

[Martin Kobetic]

PublicKey signature is I think the only case where we don't capture the signed bytes. Consequently signature verification requires remarshaling the key contents (without the signature), which we know can be fraught with non-determinism in protobuf. We may want to consider replacing the current PublicKey definition

message PublicKey {
    // The key bytes
    message Secp256k1Uncompressed {
        // uncompressed point with prefix (0x04) [ P || X || Y ], 65 bytes
        bytes bytes = 1; 
    }
    uint64 timestamp = 1;
    optional Signature signature = 2;
    oneof union {
        Secp256k1Uncompressed secp256k1_uncompressed = 3;
    }
}

With something like this

message PublicKey {
    // The key bytes
    message Secp256k1Uncompressed {
        // uncompressed point with prefix (0x04) [ P || X || Y ], 65 bytes
        bytes bytes = 1; 
    }
    uint64 timestamp = 1;
    oneof union {
        Secp256k1Uncompressed secp256k1_uncompressed = 3;
    }
}

message SignedPublicKey {
    bytes key_bytes = 1;  // embeds a PublicKey
    Signature signature = 2;
}

Upside:

• safe from protobuf issues
• removes the optional field which seems to be a hassle
• saves remarshaling for the verifier

Downside:

• this would be a major breaking change,
  • all the contact bundles would need to be re-exported
  • all the message headers would be broken too

Thoughts?

[Martin Kobetic]

Also, we should create a proper type for ethers.signMessage signatures instead of conflating them with general ECDSA signatures and eliminate special code for processing wallet signatures. See https://xmtp-labs.slack.com/archives/C02BABHFZG9/p1660836072452479

[github-actions]

🎉 This issue has been resolved in version 3.0.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀