If the NSE receives an Olm to-device message to set up an Olm session with the client, then it will presumably go and claim an OTK from the server and handshake to set up the Olm session. However, the NSE crypto state is ephemeral and gets regularly regularly. Therefore this Olm session will subsequently wedge and have to be recovered by the app when it's next used. This /may/ paper over this failure mode, but relying on unwedging logic for Olm sessions is not great (it adds latency to fix the session).
If the NSE and App try to /sync at the same time from the same since token, they will race and could end up with toDevice messsages received on one side but not the other. If the App thinks it has caught up, it will discard any queued up sync responses collected by the NSE, and so potentially discard toDevice messages which were only received on that path. It might even discard sync responses in general received by the NSE.
ara4n
commented
2 years ago
Writing them down before I forget them:
If the NSE receives an Olm to-device message to set up an Olm session with the client, then it will presumably go and claim an OTK from the server and handshake to set up the Olm session. However, the NSE crypto state is ephemeral and gets regularly regularly. Therefore this Olm session will subsequently wedge and have to be recovered by the app when it's next used. This /may/ paper over this failure mode, but relying on unwedging logic for Olm sessions is not great (it adds latency to fix the session).
If the NSE and App try to /sync at the same time from the same since token, they will race and could end up with toDevice messsages received on one side but not the other. If the App thinks it has caught up, it will discard any queued up sync responses collected by the NSE, and so potentially discard toDevice messages which were only received on that path. It might even discard sync responses in general received by the NSE.