Message IDs in Push Notifications

Messenger
1

While finishing up the Fix PN metadata leak PR, I realized that eventually we’ll want to pass some form of data that will allow us to tie back a Push Notification to the originating Whisper message. Some examples of future issues that will require this data to be sent in the PN:

  • Having the action of tapping the PN not only open up the correct chat, but scroll up to the correct point in the conversation, so that the user doesn’t get lost;
  • Notifications about previous messages should disappear when chat is opened #3487;
  • Push notification is shown but no message received #3467;
  • Fetch messages in background when Push Notification is received #3451;
  • And basically any other functionality which requires matching a PN with a chat message.

It seems that there’s no reason why we couldn’t start passing this data ASAP, so that we start having a wide installed base so that when these features do get rolled out, the old clients will supply updated clients with the necessary data and things will work seamlessly out of the gate.

Assuming we want to get this rolling, we need to decide what to send as a message ID in the PN payload. Ideally, it won’t compromise privacy/darkness, since PNs already contain sender/receiver pubkeys (something to be fixed soon) and transit through Firebase servers. We also really just need something that helps us locate a message in a certain chat within a certain time window (bi-directional match). With that in mind, we certainly don’t need to send the full message ID, but instead something which still provides a good degree of plausible deniability, even if it requires a small amount of computation/lookup on the receiving device. Some thoughts of what we could use:

  • Last 4 bytes of message ID
  • Hash of message ID
  • <<Your suggestion here>>

Thoughts and suggestions welcome. cc @petty, @dustin

2

I’d love some more context and knowledge about how the current system works. Can we set up a chat to get me up to speed?

3

Sure @petty, I’ll DM you in Status to set up a call.

4

After a short conversation, the decision was to send the first 4 bytes of the sha3 of the pubkeys, while at the same time provide support for versioning. Likewise, for messages we’ll send the first 4 bytes of the existing message-id, also with support for versioning. That should be more than enough to prevent collisions while still allowing a good degree of plausible deniability and decent performance in the lookups.

Thanks again for going through the rationale with me, Corey.

1 Like