After reviewing step 2 here, it feels like a lot of it is duplicated with the second half of InputStateContainer::uploadBlob (starting on line 1236). The only differences are:

1. url
2. parameters
3. Behavior on resolve (InputStateContainer::uploadBlob does JSON.parse)

The first two can be inputs into a shared async function, and the third can be handled by InputStateContainer::uploadBlob directly after awaiting the shared async function.

@bartek, what do you think of "factoring out" part 2 here?

For blob service, only the / matters, however, base64url here is a great idea.

Found the base64url library which implements it with simple regex replaces. The library is Node-only though (uses Buffer) so I'll create a function somewhere in lib/

I think it's worth doing, but this is work for a separate diff or two.
My idea is to factor out the whole blobServiceUpload() function - we can create a counterpart for lib/utils/upload-blob.js and follow similar logic as we have in lib/actions/upload-actions with the uploadBlob callback.

Anyway, I'd prefer doing this as a follow-up at the top of the stack - I can create a task for this

Your suggestion is much simpler than my idea, I'll see how much code it saves

Btw, the naming for the existing uploadBlobintroduces some confusion as it refers to "keyserver" upload, while we also have "blob" service uploads

Might be overly verbose, but more clear to have uploadBlobToKeyserver and uploadBlobToBlobService?

Ah yes, missed that

I responded in https://phab.comm.dev/D7617?id=25933#inline-50542 and created a ENG-3841 as this is a more complex task

Type definitions inside class don't work. Will leave it as is, this will be refactored during de-duplication anyway