feat(2631): Encrypt all message contents and reduce size of encryption

[islathehut]

Decrypted Message

export interface ChannelMessage {
  id: string
  type: number
  message: string
  createdAt: number
  channelId: string
  signature: string
  encSignature?: EncryptionSignature
  pubKey: string
  media?: FileMetadata
}

Encrypted Message

export interface EncryptedMessage {
  id: string
  contents: EncryptedPayload
  createdAt: number
  channelId: string
  encSignature: TruncatedSignedEnvelope
}

Fields From Message that are Encrypted

export interface EncryptableMessageComponents {
  type: number
  message: string
  signature: string
  pubKey: string
  media?: FileMetadata
}

Pull Request Checklist

• I have linked this PR to a related GitHub issue.
• I have added a description of the change (and Github issue number, if any) to the root CHANGELOG.md.

(Optional) Mobile checklist

Please ensure you completed the following checks if you did any changes to the mobile package:

• I have run e2e tests for mobile
• I have updated base screenshots for visual regression tests

[adrastaea]

TruncatedSignedEnvelope is sort of a mouthful, and not really descriptive to what this object is. We might as well just call this object Signature, but also, I don't think I really agree with this object existing independently at all. For one, just having the SignedEnvelope type makes more sense because it ensures the signature and the contents it is signing stay together reducing the chance of somehow later creating a mismatched pair of signature and contents. Also, these types are all sort of just recreating the LFA native types with new types. Why not just use the types that the library provides/returns?

[islathehut]

Changed name to Signature.

[adrastaea]

See, here we're just recomposing the type we broke apart earlier in order to fit the verifyMessage typing. We could just maintain the shape throughout.

[islathehut]

I updated this because using the types that LFA uses means we have the encrypted contents written twice to orbitdb. It's fine when we're just passing it around in memory but since the encrypted contents are usually the largest part of the object it's a pretty big increase in storage space/network bandwidth.

[islathehut]

A possible alternative is to combine the two types so we end up with

{
  "contents": <encrypted data array>,
  "recipient": <info on which key data was encrypted with>,
  "signature": <signature string>,
  "author": <info on which user's key was used to sign>
}

We probably wouldn't even need to decompose into the original LFA types since this would have the requisite fields for both the signature and the encrypted payload.

[islathehut]

Actually, thinking more about this, we should be signing the raw message instead of the encrypted which changes things a bit.

[islathehut]

Alright, I kept the same decomposed type but now its the raw message that's signed.