Add unable-to-decrypt timeline item support

[jplatte]

Part of #1103.

[jplatte]

Does this make sense?

[poljar]

Could you expand on this? Is this about an encrypted event, that we can't decrypt, being a replacement that is an edit.

The assumption here is that edits only update timeline items but don't produce new ones, right? If that's so, then this sounds correct.

[jplatte]

Exactly. I was wondering whether we should show a UTD item for an edit that can't be decrypted. this branch also includes "annotations", i.e. reactions which are currently never encrypted so maybe that variant shouldn't exist at all 🤔

[jplatte]

We know nothing about the content that we would like to "present" to SDK users here, right?

[gnunicorn]

don't we have like the sender at least? And some other metadata like the time it was sent? That's at least what element-web shows...

[poljar]

You don't know anything about the thing that's encrypted, if you mean the content type or some other metadata.

Though you will want to show quite a bit, you'll likely want to have some "request room key functionality", what springs to mind, besides the sender and timestamp, is:

• Algorithm that the event claims to use
• Session id
• sender_key and Device id if there is one

Hmm, that's almost the whole content of the event, perhaps it makes sense to leave the whole content in.

[jplatte]

@gnunicorn Sender and time are not part of the content, they are fields of the timeline item (one level up basically).

[jplatte]

Since we store the raw event separately as well and probably need to deserialize to matrix-sdk-crypto's RoomEncryptedEventContent, I'd rather introduce a payload-free version of Ruma's RoomEncryptedEventContent to use here. The encrypted payload isn't going to be very useful outside of show-event-source, if at all.

[codecov]

Codecov Report

Base: 73.09% // Head: 72.96% // Decreases project coverage by -0.12% ⚠️

Coverage data is based on head (4dca3a4) compared to base (b5b2eaf).
Patch coverage: 11.11% of modified lines in pull request are covered.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1140      +/-   ##
==========================================
- Coverage   73.09%   72.96%   -0.13%     
==========================================
  Files         110      110              
  Lines       12302    12323      +21     
==========================================
  Hits         8992     8992              
- Misses       3310     3331      +21     

Impacted Files	Coverage Δ
crates/matrix-sdk/src/room/timeline/event_item.rs	65.71% <0.00%> (-7.31%)	⬇️
crates/matrix-sdk/src/room/timeline/mod.rs	85.96% <ø> (ø)
...ates/matrix-sdk/src/room/timeline/event_handler.rs	66.83% <15.00%> (-5.15%)	⬇️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

[jplatte]

Ready for another review.

edit: Oh, UniFFI panic ._.
Will look into it.

[zecakeh]

I don't know if it should be in this PR, or a separate item in #1103, but it would also be nice to retry to decrypt those items when new room keys are received.

[jplatte]

I think that can be a separate PR.

[jplatte]

Now using UDL since the uniffi Enum macro is broken (I intend to unbreak it soon, but don't want to block this PR on that).

[poljar]

So this works fine for new timeline items, but it produces a kind of dichotomy for local echo and perhaps even updates.

I need to handle the case of a local echo being an UTD, this is obviously unreachable and it seems to be quite pointless to force every consumer of the lib to introduce unreachable() calls.

I think the same applies to an update_at signal, can you think of a scenario where we'll want to replace a decrypted event with an UTD?

Edits come to mind, where we can decrypt the original event, but can't decrypt the edit. I think in that case we'll want to leave the original there, remember the edit, and trigger an update if and when we're able to decrypt the edit.

I'll approve this but I think that long-term we'll want to remove the problem with local echo being able to be a UTD.

[jplatte]

Hm, why would you need special-case code to replace timeline item X by timeline item Y for a specific combination of X and Y? I would expect it to be something like "create UI presentation for the new item, replace graphical presentation of the old item with it" regardless of the specific item types.

[poljar]

Hm, why would you need special-case code to replace timeline item X by timeline item Y for a specific combination of X and Y? I would expect it to be something like "create UI presentation for the new item, replace graphical presentation of the old item with it" regardless of the specific item types.

Alright, let's assume that replacements aren't problematic. Local echo does require different UI presentation, i.e. it used to be greyed out on Element as well.

[jplatte]

Right. I'll open an issue so we can potentially update the data model to make local utd's impossible.