Change Details

The existing `multimediaMessageCreationResponder` accepts: - `threadID: string` - `localID: string` - `mediaIDs: string[]` This information is sufficient to create `IMAGES` messages (type 14), but for `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`. {image https://blob.sh/9232dc.png} 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.

The existing `multimediaMessageCreationResponder` accepts: - `threadID: string` - `localID: string` - `mediaIDs: string[]` This information is sufficient to create `IMAGES` messages (type 14), but for `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.

The existing `multimediaMessageCreationResponder` accepts: - `threadID: string` - `localID: string` - `mediaIDs: string[]` This information is sufficient to create `IMAGES` messages (type 14), but for `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`. {image https://blob.sh/9232dc.png} {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.