-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add legacy V2 identity key association #97
Conversation
8bab3b6
to
5b0e803
Compare
…nstallation key (#230) An association proves that a given XMTP installation key is acting on behalf of a given blockchain account address, typically using a signature of some kind. There can be multiple different types of associations, one of which is an [EIP191 association](https://eips.ethereum.org/EIPS/eip-191). I'm adding [another association type](xmtp/proto#97) shortly. We haven't settled on consistent terminology until recently. To avoid confusion, this renames: - Association.addr -> Association.blockchain_address - Association.account_public_key -> Association.installation_public_key - Association -> Eip191Association Also fix some lints/unused imports. **Note: This PR will break any existing databases used by the CLI. Please re-register any installations after this lands.**
// Legacy - all of the information needed to construct the Create Identity | ||
// association text used in XMTP v2 | ||
message CreateIdentityAssociationData { | ||
string wallet_address = 1; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is confusing to me, since the Create Identity association text is actually the encoded protobuf of the public key, not the wallet address.
// EIP191Association is used for all EIP 191 compliant wallet signatures | ||
message Eip191Association { | ||
AssociationTextVersion association_text_version = 1; | ||
reserved 1; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we care about reserving fields if we aren't yet worried about interoperability between existing versions. Think we can just throw away all our existing v3 keys and start fresh
Needed to test out v3 in current SDK's without introducing breaking changes. Publishing now to avoid conflict with Daria's ramp-up task.