Change Details

This is just a simple rename. > Why are we doing this? We've modified `multimediaMessageCreationResponder` in the last diff (D5058) to accept a `t.list(tMediaMessageMedia)` while continuing to support `t.list(t.String)` (via `legacyMultimediaMessageCreationResponder`). We needed to make this change so the client could communicate to the `keyserver` the relationship between each piece of media (photo or video) and corresponding uploads for video messages. We want to update `native` to use the updated payload when hitting the `create_multimedia_message` endpoint. However, we don't want to break `web` while we're doing that. So, keeping the existing `sendMultimediaMessage` around and renaming to `legacy...` so everything continues to work. Then 1. Introducing a new version of `sendMultimediaMessage` to be consumed by `native` that sends over the new payload 2. Implementing "new" `multimediaMessageCreationResponder` to handle the new payload 3-?: Making whatever changes on `native` needed to get video messages working end-to-end ?+1: Updating `input-state-container` on `web` to use the new `sendMultimediaMessage` ?+2: Removing `legacySendMultimediaMessage` altogether Basically this lets us defer updating `input-state-container` on `web` while we're figuring things out on `native`.

This is just a simple rename. > Why are we doing this? We've modified `multimediaMessageCreationResponder` in the last diff (D5058) to accept a `t.list(tMediaMessageMedia)` while continuing to support `t.list(t.String)` (via `legacyMultimediaMessageCreationResponder`). We needed to make this change so the client could communicate to the `keyserver` the relationship between each piece of media (photo or video) and corresponding uploads for video messages. We want to update `native` to use the updated payload when hitting the `create_multimedia_message` endpoint. However, we don't want to break `web` while we're doing that. So, we're keeping the existing `sendMultimediaMessage` around and renaming to `legacy...` so everything continues to work. Then 1. Introducing a new version of `sendMultimediaMessage` to be consumed by `native` that sends over the new payload 2. Implementing "new" `multimediaMessageCreationResponder` to handle the new payload 3-?: Making whatever changes on `native` needed to get video messages working end-to-end ?+1: Updating `input-state-container` on `web` to use the new `sendMultimediaMessage` ?+2: Removing `legacySendMultimediaMessage` altogether Basically this lets us defer updating `input-state-container` on `web` while we're figuring things out on `native`.

This is just a simple rename. > Why are we doing this? We've modified `multimediaMessageCreationResponder` in the last diff (D5058) to accept a `t.list(tMediaMessageMedia)` while continuing to support `t.list(t.String)` (via `legacyMultimediaMessageCreationResponder`). We needed to make this change so the client could communicate to the `keyserver` the relationship between each piece of media (photo or video) and corresponding uploads for video messages. We want to update `native` to use the updated payload when hitting the `create_multimedia_message` endpoint. However, we don't want to break `web` while we're doing that. So, we're keeping the existing `sendMultimediaMessage` around and renaming to `legacy...` so everything continues to work. Then 1. Introducing a new version of `sendMultimediaMessage` to be consumed by `native` that sends over the new payload 2. Implementing "new" `multimediaMessageCreationResponder` to handle the new payload 3-?: Making whatever changes on `native` needed to get video messages working end-to-end ?+1: Updating `input-state-container` on `web` to use the new `sendMultimediaMessage` ?+2: Removing `legacySendMultimediaMessage` altogether Basically this lets us defer updating `input-state-container` on `web` while we're figuring things out on `native`.