TECH TASK: eliminate `sdMessage` from "incoming" call stack
STUB
context
- right now we parse an outgoing
sdMessage
as the first step ofdispatcher.relay
- this is outdated. we used to do this because we assumed that in mose cases we'd just pass this along through the broadcast happy path and insert some recipietns into it.however, now we construct our own
sdMessages
for every conceivable outgoing message (including broadcast messages) - so having this lying around is unnecesary. but it is also confusing (it necessitates us treating what is essentially incoming information as outgoing-formatted stuff... and notably: constructing a
sender: channelPhoneNumber
k/v pair at a part of the stack where the sender is still most logically still a person and the channel is still the recipient. (the channel will become the sender only after the execute layer)
proposed change
- to mirror what is true, we should just eliminate
sdMessage
s altogether until we construct them in execute - instead of parsing outbound sdmessages in
dispatcher.relay
, we should simply extract the message body and attachments array - it is unclear whether we should go ahead and transform inbound attachments to outbound attachments at this step, or defer doing that until constructing
sdMessage
s in tehexecute
layer. the most likely thing to sway that decision is how it effects the logic of parsing attachments from signald rate limit errors for resending. (in which the outbound/inbound distinction is already a bit troubled). figuring that out will be the main substance of playing this card.