-
Notifications
You must be signed in to change notification settings - Fork 269
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
Conversation
/// 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. |
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.
I wonder if we should just copy paste the underlying documentation instead of rolling a new one 🤔
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.
I did but removing the middle section as it seems overly technical from the perspective of an SDK user to me.
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.
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.
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.
Code looks good, I'm fine with either this code comment or one copied from the SDK. Thanks.
Codecov ReportAll modified and coverable lines are covered by tests ✅
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. |
/// | ||
/// 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 { |
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.
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
.
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.
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 🫤
I am not sure of the full context here but if you expose |
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 |
(I confirm that the API works as expected on a EXA WIP branch) |
No |
3b5b20b
to
afc2594
Compare
For now this is everything we need. |
@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 🙂 |
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.
API question below. Looks good otherwise :)
/// To get the E2EE identity of a user even if it is not available locally | ||
/// use `request_user_identity()`. |
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.
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?
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.
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.
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.
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 |
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.
nit: doesn't match the parameter name 😛
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.
Oops, refactor didn't get the docs.
return Ok(None); | ||
} | ||
} | ||
Err(e) => { |
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.
nit: please use err
or error
for this variable's name, one-letter named variables are bleh :P
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.
ahaha, I always thought this one-letter naming was a Rust preference. 100% happy to stop doing this 🙌
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.
6e63406
to
dce7297
Compare
&self, | ||
user_id: String, | ||
request_from_homeserver_if_needed: bool, |
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.
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. |
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.
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.
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.
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?
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.
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.
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.
dce7297
to
195fed7
Compare
UserIdentity::is_verified
and add a new Encryption::user_identity
method.
Nothing exciting here, just exposing another method.