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 D12375#351687, @ashoat wrote:

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.

2. 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.

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

In D12375#352658, @ashoat wrote:

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.