Page MenuHomePhabricator

[keyserver] Return blob hash and holder from upload endpoint
AbandonedPublic

Authored by bartek on Jun 20 2023, 5:20 AM.
Tags
None
Referenced Files
F3351314: D8257.diff
Sat, Nov 23, 12:57 AM
Unknown Object (File)
Fri, Nov 15, 8:23 PM
Unknown Object (File)
Wed, Nov 13, 2:28 AM
Unknown Object (File)
Sun, Nov 10, 12:33 PM
Unknown Object (File)
Sat, Nov 9, 4:04 AM
Unknown Object (File)
Fri, Nov 8, 8:03 AM
Unknown Object (File)
Fri, Nov 8, 8:03 AM
Unknown Object (File)
Fri, Nov 8, 7:53 AM
Subscribers

Details

Reviewers
atul
ashoat
michal
Summary

Until now, the blob service upload endpoint (upload-media-metadata) returned the same result as the upload-multimedia endpoint.
However, it turns out to be convenient to have the blob hash and holder returned as well to avoid hacks (by passing them some other way) - it will be used in web client later (for blob deletion).

Depends on D8256

Test Plan

Called the upload-media-metadata endpoint from web input-state-container. Received the following output:

Screenshot 2023-06-20 at 13.44.14.png (290×1 px, 115 KB)

Diff Detail

Repository
rCOMM Comm
Lint
No Lint Coverage
Unit
No Test Coverage

Event Timeline

bartek held this revision as a draft.

Get rid of Flow workaround

bartek published this revision for review.Jun 20 2023, 6:23 AM

However, it turns out to be convenient to have the blob hash and holder returned as well to avoid hacks (by passing them some other way) - it will be used in web client later (for blob deletion).

Isn't this data already available on the client? If the data comes from the client, then I'm a little confused why we're returning it from the endpoint

However, it turns out to be convenient to have the blob hash and holder returned as well to avoid hacks (by passing them some other way) - it will be used in web client later (for blob deletion).

Isn't this data already available on the client? If the data comes from the client, then I'm a little confused why we're returning it from the endpoint

Yes, it is. I don't know the beginnings of this convention, but we're doing the same with other values like loop, dimensions etc (probably the media could be processed on keyserver and these values could change).

Either way, I need to return UploadMediaMetadataResult from blobServiceUpload() in web/input-state-container. Alternatively, I can do it directly from there, just thought it would be cleaner to do it the same way other params are passed

Yes, it is. I don't know the beginnings of this convention, but we're doing the same with other values like loop, dimensions etc (probably the media could be processed on keyserver and these values could change).

I suspect that these other parameters either can be changed by the keyserver, or (perhaps more likely) at some point we thought we would want to be able to change them on the keyserver.

Either way, I need to return UploadMediaMetadataResult from blobServiceUpload() in web/input-state-container. Alternatively, I can do it directly from there, just thought it would be cleaner to do it the same way other params are passed

If we are confident that the keyserver will not change this parameter, then I think we should avoid wasting network traffic on it. My impression is that the keyserver won't be downloading the whole blob anyways, so there's no way to confirm the blob hash (or generate a new one).

If we are confident that the keyserver will not change this parameter, then I think we should avoid wasting network traffic on it. My impression is that the keyserver won't be downloading the whole blob anyways, so there's no way to confirm the blob hash (or generate a new one).

Blob hash won't be changed on keyserver, and regarding the holder: it's not gonna be changed too, unless we'd like to introduce some holder-manipulation logic in the future (rather unlikely in this case) so I'll do the other approach

Decided to go with a client-side approach in D8320 so abandoning this for now. We can always return additional data in the future without breaking if needed.