Aladar has 3 devices. A phone (p), a deskop (d), a tablet (t). All of these devices have a unique Tox ID.
There is a fourth Tox ID (A), which is the ID of Aladar, regardless which device is he using. All of his contacts know only this ID.
p, d, t and A have each other on their contact list.
Here's how it looks like when Aladar talks to Boglarka (B) using his phone:
t --- sync
\ <=> conversation
\
\
d ----- A <===> B
In this case, the phone is on the Tox network using the A ID. Let's call this active mode. The two other clients are using their own. A synchronizes it's chat logs in real time to t and d. If Aladar adds a new contact, that's also forwarded to the other nodes (passive mode).
The nodes using t and d display the chat logs just like Aladar had an ongoing conversation.
Aladar gets home, and opens the desktop client. He starts typing to Boglarka, which indicates that he wants to transfer the conversation there.
The t node sends a BACKOFF message to A. A flushes all remaining sync messages, goes offline, reconnects using the p ID, and goes to passive mode.
t acknowledges that A has disconnected, so it disconnects, and reconnects with the A ID, and sends B the message Aladar has probably finished typing. It also forwards the message to d, and after p comes online, it starts syncing with it as well.
A <===> B --- sync
/ \ <=> conversation
/ \
/ \
d p
If t losts connection to A, without being in a transition from passive to active mode, there are three possible scenarios:
- A got disconnected
- t got disconnected
- Both of them got disconnected
t --- sync
\ <=> conversation
X
\
d --x-- A <=x=> B
When t detects that it has lost its connection to A, it tries to connect to d. If the connection attempt is successful, it asks d if A is still online.
If the answer is positive, it waits patiently for A to reconnect and continue syncing.
Otherwise it rolls dice, and sends the result to d. d also rolls and sends back the result to t. Whoever has the higher number, goes into active mode. Alternatively, Aladar could assign priorities to the passive IDs, which would override the gambling.
t --- sync
\ <=> conversation
X
\
d ----- A <===> B
t tries to reconnect to d and A simultaneously. If A connects, it resumes syncing, and everyone's happy. If d connects, see case #1.
Directly connecting every node would cause too much outgoing traffic on A. Aladar should have the option to limit the maximum number of passive nodes.
Two examples for having only one sync connection, in contrast to many (phone vs. desktop):
active phone active desktop
t t
/ /
/ /
/ /
d ----- A <===> B B <===> A ----- p
\ \
\ \
\ \
d' d'
If the phone's maximum number sync connections are set to 1, it asks other nodes about their maximum, and asks the largest (d) to forward to the others. If d doesn't have enough sync slots, it can delegate to other nodes, creating a mesh network for syncing.