Multidevice and more: Call management

[drequivalent]

I've left this proposal on the Tox blog and I will just copypaste it here because I'm lazy and cheap like that:

Say, I’m walking home, toxing on my phone. Then, when I come home, I want
to continue talking from my PC. It would be awesome to pass the call to my
other device seamlessly, without having to re-dial that person I’m talking to.

Guess, that wouldn’t be too hard to implement as long as all devices know
about all other devices: you just give user a list, and then he decides what
device to pass the call to.

Also, I thought a little bit further and realized, that this function shouldn't really stop at devices belonging to one person. There also should be possibility to redirect a call to another person entirely. The mechanism is basically the same, it only should differ visually.
Say, I get a call from a customer. I run into issue or a question, that I can't solve and answer, but my friend on the other desk can. Telling him to come over here is lame. Giving the customer his Tox ID and hoping that they call back is also lame. I just throw this call to my friend via menu.

So basically, it works like PBX without actually having a PBX.

May be this is a bit too much, but that's just a proposal, make of it what you will.

[nurupo]

Say, I get a call from a customer. I run into issue or a question, that I can't solve and answer, but my friend on the other desk can. Telling him to come over here is lame. Giving the customer his Tox ID and hoping that they call back is also lame. I just throw this call to my friend via menu.

The thing is that your friend must be in customer's friend list before the friend and the customer can communicate. They need a direct ip:port <-> ip:port connection between their computers, and you get ip:port of a person by friending them.

You can route friend's and the customer's call through your tox client in the middle, but then it would be possible for you to eavesdrop on their conversation, since the friend would encrypt the audio/video packets for you, and you would decrypt them and encrypt for the customer, and same the other way -- customer would encrypt their audio/video packets for you, and you would decrypt them and re-encrypt for the friend. This will consume your cpu, ram and bandwidth. This also would add latency to the audio/video call, since you are in the middle now. This is something you can do right now, there is no need to change something in toxcore, it just requires client support.

You could do something similar to the last paragraph -- route friend's and customer's traffic through you, but ask the friend to encrypt it for the customer instead of encrypting it for you and ask the customer for encrypting it for the friend instead of you. Essentially, you would need to give to the friend customer's public key and to the customer friend's public key (public key is Tox Id). In this case you won't be able to eavesdrop on the conversation, but your cpu/ram/bandwidth would still be used for routing and there would be some latency in the call introduced by you.

[drequivalent]

That's fair, and I guess automating the process of adding a person to a friend list while switching would introduce security risks.
So, leave it at call switching between devices of one person then.

[aaannndddyyy]

You can leverage a future a/v-groupchat for this use case.

Benefits:
No relaying over your node
No eavesdropping - though this is actually a moot point if the key your client gets is given him by you.

Your client sends a custom message to your colleague's client, instructing it to create a 2-peer "public" group which is protected by a secret key.
It replies to you with the chat I'd and the secret key, which you forward to your customer.

As it is a "public"* chat, he can connect to it without befriending your colleague.
This will be done automatically by the customer's client, customer will be notified and can abort.
It connects to your colleague's group chat providing the secret as credential.
Now your colleague and your customer are directly communicating with each other, not relayed by you, and yet never became friends.

Note: I don't like the terminology very much. There are " public" group chats that are not public ally joinable.
I prefer:

• public: anyone can join using chat id or by being invited
• private: only holders of an secret key / passfrase can join (via chat I'd or invite)
• hidden: not in dht, therefore no chat id to join with, only invites

[tox-user]

Currently two profiles with the same Tox ID can't be online at the same time. For this proposal to work, this would have to be changed, because currently Tox will just freak out. What if they could be online at the same time? Which one should be the active one that receives and responds to messages? Maybe both? But then when our private key gets stolen, it would be harder to notice. Or maybe let the user decide? Then the last device that opened the profile would be the active one and the user would be able to switch it at any time. The client would show the user if the current device is the active one or not.