The existing `multimediaMessageCreationResponder` accepts:
- `threadID: string`
- `localID: string`
- `mediaIDs: string[]`
This information is sufficient to create `IMAGES` messages (type 14), but not `MULTIMEDIA` messages (type 15). In order to properly represent the relationship between primary media and thumbnail media we need to replace the list of strings with a list of something like the following:
```lang=javascript
export type MediaMessageContent =
| {
+type: 'video',
+mediaID: string,
+thumbnailID: string,
}
| {
+type: 'photo',
+mediaID: string,
};
```
We could change the `create_multimedia_message` endpoint to handle a `$ReadOnlyArray<MediaMessageContent>`... but that would break existing clients.
We could also create a seperate `create_multimedia_message_v2` endpoint, but that would lead to a lot of branching (and changes that need to be made elsewhere eg `endpoints.js`).
The simplest/cleanest approach in my mind is:
1. Extract the existing functionality out of `multimediaMessageCreationResponder` into `legacyMultimediaMessageCreationResponder` (to support old clients).
2. Modify `sendMultimediaMessageRequestInputValidator` to optionally accept a list of `MediaMessageContent`
3. If a request includes `mediaIDs`, send it over to `legacyMultimediaMessageCreationResponder`
4. If a request includes `mediaMessageContent`, it'll be handled within `multimediaMessageCreationResponder`.
5. Implement `multimediaMessageCreationResponder` to handle `MULTIMEDIA` messages (will likely require some new queries, etc)
6. Modify `native` (`message-actions: sendMultimediaMessage(...)`) to hit the updated `multimediaMessageCreationResponder` endpoint with `mediaMessageContent` instead of `mediaIDs`.
{F152995}
7. Make sure that old clients continue to work with these changes.
8. etc...
In the long run (outside of the scope of our current video work), I think it makes sense for both photos and videos to use the more flexible `MULTIMEDIA: 15` message type.
---
Depends on D4981