FFI: Expose is_verified UserIdentity method and request_user_identity Encryption method.

[pixlwave]

Nothing exciting here, just exposing another method.

[stefanceriu]

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

[pixlwave]

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

[stefanceriu]

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.

[bnjbvr]

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

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 84.83%. Comparing base (08152bd) to head (afc2594).

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    24422       -7     
- Misses       4364     4366       +2     

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

[bmarty]

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.

[pixlwave]

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]

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]

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]

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

[BillCarsonFr]

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]

For now this is everything we need.

[pixlwave]

@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 🙂