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

FFI: Expose UserIdentity::is_verified and add a new Encryption::user_identity method. #4142

Merged
merged 3 commits into from
Oct 21, 2024

Conversation

pixlwave
Copy link
Member

Nothing exciting here, just exposing another method.

@pixlwave pixlwave requested a review from a team as a code owner October 16, 2024 16:54
@pixlwave pixlwave requested review from bnjbvr and removed request for a team October 16, 2024 16:54
Comment on lines +465 to +504
/// Is the user identity considered to be verified.
///
/// If the identity belongs to another user, our own user identity needs to
/// be verified as well for the identity to be considered to be verified.
Copy link
Member

Choose a reason for hiding this comment

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

I wonder if we should just copy paste the underlying documentation instead of rolling a new one 🤔

Copy link
Member Author

Choose a reason for hiding this comment

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

I did but removing the middle section as it seems overly technical from the perspective of an SDK user to me.

Copy link
Member

Choose a reason for hiding this comment

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

Ah, I see, I was looking at the one inside the crypto crate which seemed just perfect. I'm just worried something will change on one level or another and then the documentation will be out of date.

Copy link
Member

@bnjbvr bnjbvr left a comment

Choose a reason for hiding this comment

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

Code looks good, I'm fine with either this code comment or one copied from the SDK. Thanks.

Copy link

codecov bot commented Oct 17, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 84.83%. Comparing base (08152bd) to head (195fed7).
Report is 6 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #4142      +/-   ##
==========================================
- Coverage   84.84%   84.83%   -0.01%     
==========================================
  Files         269      269              
  Lines       28793    28788       -5     
==========================================
- Hits        24429    24423       -6     
- Misses       4364     4365       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

///
/// If the identity belongs to another user, our own user identity needs to
/// be verified as well for the identity to be considered to be verified.
pub fn is_verified(&self) -> bool {
Copy link
Contributor

Choose a reason for hiding this comment

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

I am wondering if this data should be live? Maybe not for now but in the future the app could be more reactive if we had a way to get a live UserIdentity.

Copy link
Member Author

@pixlwave pixlwave Oct 17, 2024

Choose a reason for hiding this comment

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

Yeah, I'd really like this to be a property on RoomMember that would update automatically through the room members stream if I'm honest, but I don't have a clue how to do that as the members live separately to the encryption 🫤

@BillCarsonFr
Copy link
Member

I am not sure of the full context here but if you expose is_verified() you probably want also to expose was_previously_verified() / has_verification_violation().

@pixlwave
Copy link
Member Author

pixlwave commented Oct 17, 2024

I am not sure of the full context here but if you expose is_verified() you probably want also to expose was_previously_verified() / has_verification_violation().

This is being added to show the green badge on the user profile screen (element-hq/element-meta#2569).

I'm unsure now, are you saying that it is possible for is_verified and has_verification_violation to both be true at the same time and we need to think about these together, or just that the other 2 might be useful?

@bmarty
Copy link
Contributor

bmarty commented Oct 17, 2024

(I confirm that the API works as expected on a EXA WIP branch)

@BillCarsonFr
Copy link
Member

I am not sure of the full context here but if you expose is_verified() you probably want also to expose was_previously_verified() / has_verification_violation().

This is being added to show the green badge on the user profile screen (element-hq/element-meta#2569).

I'm unsure now, are you saying that it is possible for is_verified and has_verification_violation to both be true at the same time and we need to think about these together, or just that the other 2 might be useful?

No has_verification_violation means that the user used to be verified, but is not anymore. (so should have a red badge, whereas a user that was never verified and is not should have no badge)

@pixlwave pixlwave changed the title FFI: Expose is_verified UserIdentity method. FFI: Expose is_verified UserIdentity method and request_user_identity Encryption method. Oct 18, 2024
@pixlwave
Copy link
Member Author

For now this is everything we need.

@pixlwave
Copy link
Member Author

@bnjbvr I exposed 1 more method to allow requesting identities for unknown users from the homeserver, otherwise I'm happy to have this merged if you're ok with it 🙂

Copy link
Member

@bnjbvr bnjbvr left a comment

Choose a reason for hiding this comment

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

API question below. Looks good otherwise :)

Comment on lines 419 to 420
/// To get the E2EE identity of a user even if it is not available locally
/// use `request_user_identity()`.
Copy link
Member

Choose a reason for hiding this comment

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

How does the API work overall: there's both get_user_identity() (which may return None) and request_user_identity() (which is guaranteed to return something for rooms where the two users are present). How is the caller supposed to know which one should be called? Call get_user_identity() first, and if it returns nothing, try request_user_identity()?

If so:

  • can we either document it clearly here?
  • or provide a unique method that first fetches from the local crypto store, then does the remote query if not found?

Copy link
Member Author

Choose a reason for hiding this comment

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

or provide a unique method that first fetches from the local crypto store, then does the remote query if not found?

This is what we're doing in the apps, I wasn't sure if it was crossing a boundary making the SDK use it like this too, but if you'd like this, I'd much prefer to expose a single user_identity method that does a get_ and falls back to request_ if needed.

Copy link
Member

Choose a reason for hiding this comment

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

Both work for me, but if you want to keep the current version, I'd like a comment precising this on get_user_identity() at least please :)

///
/// # Arguments
///
/// * `user_id` - The ID of the user that the identity belongs to.
///
/// * `request_if_needed` - If true, the identity will be requested from the
Copy link
Member

Choose a reason for hiding this comment

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

nit: doesn't match the parameter name 😛

Copy link
Member Author

Choose a reason for hiding this comment

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

Oops, refactor didn't get the docs.

return Ok(None);
}
}
Err(e) => {
Copy link
Member

Choose a reason for hiding this comment

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

nit: please use err or error for this variable's name, one-letter named variables are bleh :P

Copy link
Member Author

Choose a reason for hiding this comment

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

ahaha, I always thought this one-letter naming was a Rust preference. 100% happy to stop doing this 🙌

Copy link
Member Author

Choose a reason for hiding this comment

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

&self,
user_id: String,
request_from_homeserver_if_needed: bool,
Copy link
Contributor

Choose a reason for hiding this comment

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

I am wondering in which case(s) an sdk user could set the parameter request_from_homeserver_if_needed to false.

///
/// * `request_from_homeserver_if_needed` - If true, the identity will be
/// requested from the homeserver if it is not found in the crypto store.
/// When `true` the identity returned is guaranteed to be up-to-date.
Copy link
Contributor

@bmarty bmarty Oct 21, 2024

Choose a reason for hiding this comment

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

When true the identity returned is guaranteed to be up-to-date.

I would claim that if when true there is always a request sent to the server, no? I mean in case identity is known locally, and has changed without the SDK knowing (no network, etc.), this assumption will not be true.

Copy link
Member

Choose a reason for hiding this comment

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

How would the app / the SDK know whether an identity was known locally but we should trigger the request because it was updated? In that case, we might as well spawn the request all the time, since we can't really know when it's been updated, right?

Copy link
Member Author

Choose a reason for hiding this comment

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

If the user came from the room members I believe we should already have their identity in the crypto store as I understand it. But happy to remove this parameter.

Copy link
Member Author

Choose a reason for hiding this comment

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

@bnjbvr bnjbvr changed the title FFI: Expose is_verified UserIdentity method and request_user_identity Encryption method. FFI: Expose UserIdentity::is_verified and add a new Encryption::user_identity method. Oct 21, 2024
@bnjbvr bnjbvr enabled auto-merge (squash) October 21, 2024 13:26
@bnjbvr bnjbvr merged commit befcd06 into main Oct 21, 2024
40 checks passed
@bnjbvr bnjbvr deleted the doug/is-verified branch October 21, 2024 13:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants