1) At registration time, a client generates a random ID and
transmits to the the server.
2) The server provides that registration ID to any client
that requests a prekey.
3) Clients include that registration ID in any
PreKeyWhisperMessage.
4) Clients include that registration ID in their sendMessage
API call to the server.
5) The server verifies that the registration ID included in
an API call is the same as the current registration ID
for the destination device. Otherwise, it notifies the
sender that their session is stale.
1) In addition to the Recipient interface, there is now
RecipientDevice. A Recipient can have multiple corresponding
RecipientDevices. All addressing is done to a Recipient, but
crypto sessions and transport delivery are done to
RecipientDevice.
2) The Push transport handles the discovery and session setup
of additional Recipient devices.
3) Some internal rejiggering of Groups.
1) Move the attachment structures into the encrypted message body.
2) Encrypt attachments with symmetric keys transmitted in the
encryptd attachment pointer structure.
3) Correctly handle asynchronous decryption and categorization of
encrypted push messages.
TODO: Correct notification process and network/interruption
retries.
1) Add encryption support for the transport layer. This obscures
metadata from the push messaging provider.
2) Better support the direction multiple destination messages is
headed (one unique message per recipient).
