[native] Add support for saving encrypted media
ClosedPublic
Actions

Authored by bartek on Jan 28 2024, 7:40 AM.

Details

Reviewers

atul
ashoat

Commits

Summary

Passed through encryptionKey and blobURI down to the saveRemoteMediaToDisk() function
In that function, added a separate flow for encrypted media. Basically, it has two steps:
1. Download and decrypt media (decryptMedia()).
2. Fetch MIME type

Depends on D10853

Test Plan

Repository

rCOMM Comm

Branch

barthap/media-save

Lint

No Lint Coverage

Unit

No Test Coverage

bartek held this revision as a draft.

bartek published this revision for review.Jan 28 2024, 11:44 PM

Looks good to me, but I'd like @atul to take a look as well

native/media/image-modal.react.js
45–51 ↗	(On Diff #36222)	Should we just remove the `invariant`? It wasn't needed prior to D7168. I think the typesystem should protect us if somebody adds a new type
53 ↗	(On Diff #36222)	Nit: since we're only assigning one variable now, I think this is more readable
native/media/save-media.js
70 ↗	(On Diff #36222)	Can you explain why all three of these need to be checked? I guess `mediaURI` is the URI in the old system, before we had encryption `blobURI` is the URI in the blob-service hosted system I have some vague memory that `holder` is necessary because we changed names but never completed a full client migration of the types. Is that right?

This revision is now accepted and ready to land.Jan 29 2024, 9:55 PM

native/media/save-media.js
70 ↗	(On Diff #36222)	Yes, basically you're all right: `mediaURI` is a URI for non-encrypted media `blobURI` is a URI for encrypted media `holder` is an old name for `blobURI`. We did a rename some time ago but there can be some old multimedia messages that still use this field