Add legacy credential type (#425)

This adds the legacy credential type. Support for generating these credentials will be added in the next PR.

- Apply the changes from xmtp/proto#131
- Add ValidatedLegacySignedPublicKey type and tests
- Add LegacyCreateIdentityAssociation - cannot add tests until I have support for serializing into proto, will add in next PR
- Significant refactoring. We use separate classes in separate files for different associations. The strong typing ensures we can't mix them up (for example confusing grant messaging access with revoke messaging access).

Because the protos have changed, some steps are required to avoid errors for those who already have libxmtp running:
- Run `./dev/down && ./dev/up` from `libxmtp`. This rebuilds the validation service, and clears out any data stored on the server.
- Remove any existing databases, for example from the CLI and Android/iOS/flutter/RN

mls_validation_service/src/handlers.rs

@@ -135,7 +135,7 @@ mod tests {
     use openmls_basic_credential::SignatureKeyPair;
     use openmls_rust_crypto::OpenMlsRustCrypto;
     use prost::Message;
-    use xmtp_mls::{association::Credential, InboxOwner};
+    use xmtp_mls::{credential::Credential, InboxOwner};
     use xmtp_proto::xmtp::{
         mls::message_contents::MlsCredential as CredentialProto,
         mls_validation::v1::validate_key_packages_request::KeyPackage as KeyPackageProtoWrapper,
@@ -152,8 +152,8 @@ mod tests {
         let _pub_key = signature_key_pair.public();
         let account_address = wallet.get_address();
 
-        let credential = Credential::create_eip191(&signature_key_pair, &wallet)
-            .expect("failed to create credential");
+        let credential =
+            Credential::create(&signature_key_pair, &wallet).expect("failed to create credential");
         let credential_proto: CredentialProto = credential.into();
 
         (

xmtp_mls/Cargo.toml

@@ -48,6 +48,7 @@ toml = "0.7.4"
 tracing = "0.1.37"
 xmtp_cryptography = { path = "../xmtp_cryptography" }
 xmtp_proto = { path = "../xmtp_proto", features = ["proto_full"] }
+xmtp_v2 = { path = "../xmtp_v2" }
 
 [dev-dependencies]
 ctor = "0.2"

xmtp_mls/IDENTITY.md

@@ -51,11 +51,13 @@ XMTP installations consist of a long-lived Ed25519 key-pair (the 'installation k
 2. The app prompts the user to sign the public key with their Ethereum wallet. The user is expected to inspect the text and reject the signing request if the data is invalid, for example if the account address is not the one they intended. The format for version 1 of the association text is as follows:
 
    ```
-   XMTP: Grant Messaging Access
+   XMTP : Grant Messaging Access
 
    Current Time: <ISO 8601 date and time in UTC>
    Account Address: <ethereum address>
    Installation ID: <hex(last_20_bytes(keccak256(Ed25519PublicKey)))>
+
+   For more info: https://xmtp.org/signatures/
    ```
 
 3. The signature and related data is then protobuf-serialized to form the MLS Credential:
@@ -64,14 +66,14 @@ XMTP installations consist of a long-lived Ed25519 key-pair (the 'installation k
    struct {
         association_text_version: i32,
         signature: bytes,
-        iso8601_time: string,
+        created_ns: u64,
         account_address: string,
-   } Eip191Association;
+   } GrantMessagingAccessAssociation;
 
 
    struct {
        installation_public_key: bytes,
-       eip191_association: Eip191Association
+       association: GrantMessagingAccessAssociation
    } MlsCredential;
    ```
 
@@ -100,19 +102,28 @@ Users may revoke an installation as follows:
 1. The app prompts the user to sign the revocation with their Ethereum wallet. The user is expected to inspect the text and reject the signing request if the data is invalid, for example if the account address is not the one they intended. The format for version 1 of the association text is as follows:
 
    ```
-   XMTP: Revoke Messaging Access
+   XMTP : Revoke Messaging Access
 
    Current Time: <ISO 8601 date and time in UTC>
    Account Address: <ethereum address>
    Installation ID: <hex(last_20_bytes(keccak256(Ed25519PublicKey)))>
+
+   For more info: https://xmtp.org/signatures/
    ```
 
 1. The signature and related data is then protobuf-serialized to form the revocation:
 
    ```
+   struct {
+        association_text_version: i32,
+        signature: bytes,
+        created_ns: u64,
+        account_address: string,
+   } RevokeMessagingAccessAssociation;
+
    struct {
        installation_public_key: bytes,
-       eip191_association: Eip191Association
+       association: RevokeMessagingAccessAssociation
    } InstallationRevocation;
    ```