Details
- Reviewers
atul ashoat - Commits
- rCOMM60d79428dc29: [keyserver] Use blob hash to create blob URIs
With D8206 applied, and blob service messages enabled in input-state-container, I was able to upload multimedia and then view it. Used redux-devtools and console.log to ensure that messages contain the correct format in the holder/thumbnailHolder field.
Tested both web and native, both image and video
Diff Detail
- Repository
- rCOMM Comm
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
This change is breaking, but I think nobody except me had any blob-service stored multimedia.
Should we add team members who might have blob-services stored multimedia as blocking?
We need to modify blob URI format to be blob-service://BLOB_HASH
Might be an ignorant question, but...
If two pieces of identical media are uploaded to the blob service, will they have the same blob hash?
It looks like blobHash comes from sha256Hash which is computed by commUtilsModule.sha256 which wraps olm_sha256.
It looks like that function is deterministic, are we including a counter or something in the bytes that we hash?
I'm guessing this is accounted for somewhere, just wondering where/how
Or I guess eg the image bytes are already "encrypted" before being hashed so two images wouldn't lead to the same hash?
Two identical files will have the same SHA-256 hash (the same way as CRC checksums / MD5 works). If the blob with given sha256 hash already exists, the media wouldn't be re-uploaded, but only another holder will be assigned to existing blob.
However, in context of encrypted media, it isn't the case because each time a media is uploaded, a different encryption key is generated and thus the file's checksum also changes.