Update type imports

Simplify logic in chat-selectors.js and add parentThreadInfo to NotificationTextsParam

1. Renamed parseSourceMessageIDFromPendingThreadID to parseSourceMessageIDFromPendingSidebarID
2. Update the check in change-role-message-spec.js (I’d rather not throw an invariant here since we cover the unexpected case of roleName just simply being undefined in constructChangeRoleEntityText
3. Pass in parentThreadInfo to robotextForMessageInfo from getMessageTitle
4. Pass in parentThreadInfo to robotextForMessageInfo from notifRobotextForMessageInfo. Drill it from sendPushNotif —> notifTextsForMessageInfo —> fullNotifTextsForMessageInfo —>

messageSpec.notificationTexts —> notifRobotextForMessageInfo

Pass in null parameter from non-problematic call sites
(notifRobotextForMessageInfo and getMessageTitle)

Sorry, could you actually rebase and use the renamed function getContentSigningKey (I just updated D9220)?

Rename getContentPublicKey -> getContentSigningKey and
contentPublicKey -> contentSigningKey

Consolidate retrieving device id logic into a helper function & use that in:

Use rawAESKey and aesKeyAsHexString

As discussed, landing as is and will address feedback / de-duping while working on the major changes

Nice to see the code a lot simpler!

If the performance isn't impacted much one way or the other, is the memory usage of memoizing this not noticeable as well?

Accepting since it seems reasonable to me, but not super familiar with why we introduced it here in the first place so letting others take a look

In D9194#270776, @ginsu wrote:

Seems reasonable, does it make sense to preemptively just put this in lib as well though like useIsCurrentUserStaff

I thought about that but native has it's own version of the useStaffCanSee hook that is slightly different. The native version of useStaffCanSee also considers if the user is using a staff release as well that web does not need to consider. I thought it would make more sense/be less confusing for other devs that use this in the future if the different versions of each hook lived in their own respective platform folders, but if others disagree happy to make the necessary changes

Seems reasonable, does it make sense to preemptively just put this in lib as well though like useIsCurrentUserStaff

In D9181#270238, @ashoat wrote:

Can we use any random string as an AES-256 key? Or are there some additional requirements?

Rebase

Attempt rebase

Changes look good, thanks for fixing this!

Rebase stack

Use React.useCallback

Rebase

Rename all instances of '...Url' with '...URL'

Use getContentSigningKey

Attempt to fix COCOAPODS upgrade

Not sure if we actually need to add the dependency, planning changes to confirm before requesting review

I spent some time walking through the logic and it makes sense to me. Extracting out messageThread.community, mentionedThread.community and genesis.id to variables and using those instead of accessing the object each time would read better to me, but that may just be personal preference

Thanks for doing this!! Tests look great. I think outside of this file the pattern is to typically use it('should...), but I don't think it's a big deal

Didn't review this super closely, seems like just a move

Address CI failures

Cool find, wouldn't have expected this!