Page MenuHomePhabricator

[lib] add `IdentityDeviceListUpdated` P2P message type
ClosedPublic

Authored by kamil on Jun 10 2024, 4:43 AM.
Tags
None
Referenced Files
Unknown Object (File)
Fri, Nov 1, 11:48 PM
Unknown Object (File)
Fri, Nov 1, 11:47 PM
Unknown Object (File)
Fri, Nov 1, 11:43 PM
Unknown Object (File)
Fri, Nov 1, 11:27 PM
Unknown Object (File)
Tue, Oct 22, 1:15 PM
Unknown Object (File)
Tue, Oct 22, 9:04 AM
Unknown Object (File)
Tue, Oct 22, 8:34 AM
Unknown Object (File)
Tue, Oct 22, 8:34 AM
Subscribers

Details

Summary

Part of ENG-7837.

This is different than client DeviceListUpdated because:

  1. Indicating that this message was sent by Identity.
  2. In this case we also want the receiving device to re-send this to all other peers.
Test Plan

Tested in D12378.

Diff Detail

Repository
rCOMM Comm
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

kamil held this revision as a draft.
kamil edited the test plan for this revision. (Show Details)
kamil published this revision for review.Jun 10 2024, 9:50 AM

In this case we also want the receiving device to re-send this to all other peers.

Some questions:

  1. When you say re-send, do you mean that the receiving device will send the same message type (IdentityDeviceListUpdated) to peers? Or a different message type? (I assume different, since you indicated this message is always sent directly by Identity.)
  2. Which devices will receive this message from identity?

In this case we also want the receiving device to re-send this to all other peers.

Some questions:

  1. When you say re-send, do you mean that the receiving device will send the same message type (IdentityDeviceListUpdated) to peers? Or a different message type? (I assume different, since you indicated this message is always sent directly by Identity.)

Yes, if a device receives IdentityDeviceListUpdated, it must broadcast standardized DeviceListUpdated to all its peers because only the receiving device knows the peer list.

  1. Which devices will receive this message from identity?

The message will be received by all devices left on the device list - we can update this to send this message to only the primary device, I am open to suggestions.

For more context see the comment here.

This revision is now accepted and ready to land.Jun 13 2024, 2:39 AM

Yes, if a device receives IdentityDeviceListUpdated, it must broadcast standardized DeviceListUpdated to all its peers because only the receiving device knows the peer list.

What happens if the devices are offline? Wondering if there will be an issues in the interim period, between when identity has updated the device list, and when the peers will receive the message to update their device lists for that user.

The message will be received by all devices left on the device list - we can update this to send this message to only the primary device, I am open to suggestions.

It sounds like each receiving peer device will receive a message from each of the sending user's devices. On the receiving side, do we have a way to debounce these messages? Something like D11376

Yes, if a device receives IdentityDeviceListUpdated, it must broadcast standardized DeviceListUpdated to all its peers because only the receiving device knows the peer list.

What happens if the devices are offline? Wondering if there will be an issues in the interim period, between when identity has updated the device list, and when the peers will receive the message to update their device lists for that user.

In the worst-case scenario, other peers will still think that this device is still available and can send messages to it in this time period. But in the future, we'll have to wait for the primary to be online to sign the updates device list so this case is not worse anyway.

The message will be received by all devices left on the device list - we can update this to send this message to only the primary device, I am open to suggestions.

It sounds like each receiving peer device will receive a message from each of the sending user's devices. On the receiving side, do we have a way to debounce these messages? Something like D11376

We don't have a mechanism to debounce this, as a follow-up I can:

  1. Implement debouncing - this is not that easy because of how the client socket handles Tunnelbroker messages.
  2. Update Identity to send this message only to primary device.

But keep in mind that this is only temporary to ensure peer lists are up to date with legacy Identity auth, in the future, this code should be removed.

Sorry for the response after landing.