Skip to content
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

Identity E2E integration #755

Merged
merged 28 commits into from
May 21, 2024
Merged

Conversation

neekolas
Copy link
Contributor

@neekolas neekolas commented May 20, 2024

tl;dr

  • Gets identity working end to end, with tests (pretty much) all uncommented
  • Updates bindings to have all required methods
  • Removes a bunch of TODOs in the code

Follow-ups

There are a few changes I had to make to get everything passing that need some follow-up.

There are also many places that need better test coverage.

// get current number of users in group
let member_count = self.members()?.len();
if member_count + inbox_id_map.len() > MAX_GROUP_SIZE as usize {
return Err(GroupError::UserLimitExceeded);
}

if inbox_id_map.len() != account_addresses.len() {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The way I am doing this validation is not very good. I have to jump through some hoops to get the actual list of missing addresses.

@@ -490,6 +501,13 @@ impl MlsGroup {
.get_membership_update_intent(client, &provider, inbox_ids, vec![])
.await?;

// TODO:nm this isn't the best test for whether the request is valid
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will fix this to do a more thorough check. This is the wrong way to do it.

@neekolas neekolas changed the title [WIP] Identity E2E integration Identity E2E integration May 21, 2024
@neekolas neekolas marked this pull request as ready for review May 21, 2024 15:58
@neekolas neekolas requested a review from a team as a code owner May 21, 2024 15:58
@neekolas neekolas requested review from richardhuaaa and insipx May 21, 2024 16:01
@@ -1144,6 +1144,8 @@ mod tests {
}

#[tokio::test(flavor = "multi_thread", worker_threads = 5)]
// This one is flaky for me. Passes reliably locally and fails on CI
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah this is the one that fails because of the timeout (found during the refactor). It passes locally since CI is just slower. using async_barrier for sync points instead of tokio::sleep should fix it.

not sure if a ticket yet but should be, will make it if not

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this one has a ticket. You mind making one

Copy link
Contributor

@37ng 37ng left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is looking great! Left a few questions

Comment on lines +892 to +898
.add_ecdsa_signature(
inbox_owner
.sign(signature_request.signature_text().await.unwrap())
.unwrap(),
)
.await
.unwrap();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In this case, does platform SDK need to prompt user to sign the signature text with their wallet App, and pass in signature instead of inbox_owner signing it there?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, that's right.

Hopefully in most cases we can just use the legacy keys and so there would be no signature_request

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about new users, do they have to sign signature_request?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At launch, the platform SDKs are going to create a V2 identity before creating the V3 SDK. So even new users will have a legacy key.

Once we completely kill V2, new users will have to sign a signature_request. But they won't have the 2 V2 signatures, so it's actually one less signature than today.

xmtp_mls/src/client.rs Show resolved Hide resolved
@neekolas neekolas merged commit 76010ba into identity-release May 21, 2024
6 checks passed
@neekolas neekolas deleted the nm/end-to-end-integration branch May 21, 2024 19:35
@bwcDvorak bwcDvorak added the inbox-id Support for Inbox ID label May 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
inbox-id Support for Inbox ID
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants