HomePhabricator
Diffusion Comm a76684f64008

[keyserver] Introduce `legacyMultimediaMessageCreationResponder`

Tags
None
Referenced Files
F152995: 9232dc.png
Aug 31 2022, 1:10 PM
File Not Attached
Subscribers
None

Description

[keyserver] Introduce legacyMultimediaMessageCreationResponder

Summary:
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:

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.

9232dc.png (1×1 px, 704 KB)

  1. Make sure that old clients continue to work with these changes.
  2. 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 D4980

Test Plan:

  1. Send image message on native.
  2. Send video message on native.
  3. Set breakpoints in legacyMultimediaMessageCreationResponder and log key values to ensure that things continue to work as expected.

Reviewers: abosh, jacek, tomek, ashoat

Reviewed By: abosh, tomek

Differential Revision: https://phab.comm.dev/D4982

Details

Provenance
atulAuthored on Aug 31 2022, 12:58 PM
Reviewer
abosh
Differential Revision
D4982: [keyserver] Introduce `legacyMultimediaMessageCreationResponder`
Parents
rCOMM8c6cd24f7823: [lib] Introduce tests for `tMediaMessage[Photo/Video/Media]`
Branches
Unknown
Tags
Unknown