Join GitHub today
Suggestion: Multiple devices #843
The optimal location for this suggestion is the Wiki.
This is an alternative proposal for the one at http://wiki.tox.im/Multiple_Devices.
_How it works_:
Linking the devices (Sharing the identity):
When a device goes online - Cooperation between devices sharing the same key:
A: There is a device already online with that same public key:
The slave contacts the master via DHT (via a temporarily identity), and asks to be synced. The slave can easily prove it has possession of the same private key as the master by completing a challenge. Once this is proven, the master and the slave sync up: The slave(Smartphone) initiates a peer-to-peer connection to the master(PC), it then opts out of the DHT. Now, the phone is merely a "remote interface" to the PC, which is the actual Tox peer: Any action Alice performs on the slave(smartphone) is sent to the master (PC), only the master contacts the DHT and/or Alice's friends. Any action the PC receives from the DHT/from alice's friends is sent to the smartphone.
To sum it up, the slave is a "remote session" of the master.
B: There is no device already online with that same public key:
I'm not a Tox developer, but I think you're conflating "client" with "GUI". I also think this should probably be implemented by Toxcore and GUI's should only have to implement a UI where they can add other devices (clients), because you need to get the clients to comply with the method employed.
Sorry if Im not using the correct terminology, I`ll refer to the Users Public Key (used for friendrequests) as UUID and for a devices DHT-ID as ID.
I've been meaning to make a post about mobile clients for a while on the antox issue tracker. This proposal is pretty much exactly what I want from a mobile client.
There are probably a few more things that I'm not remembering right now. But this Master <-> Slave relationship is exactly what I was thinking about. Polling time could be set to ridiculously high if I want to save power, or shorter if I need messages NOW. I could choose if I want load media now or later. etc etc.
I want a personal version of hangeouts with gmail history sync. Being able to sign in on and have my full searchable history and media archive. But on some clients maybe I only want the past 30days of history saved to local storage.
This is where I hope Tox goes.
Last I checked Tox aims to be a secure transport for instant messages with options for real time audio/video and media sharing. How does this have any effect on syncing mechanisms?
The models presented on that wiki page seem to assume space and bandwidth have no limits except the models that sound like the Master <-> Slave relationship presented here.
I believe the most important point to realize here is that a messaging platform should not connect devices, it should connect people.
People use multiple devices. For example, say I'm talking to a person who owns a phone, a tablet and a laptop; running some combination of either at each time. Maybe she's using her phone to check for replies when she's out for a walk, or her laptop when sitting at her desk.
While I don't know the relevance to the protocols discussed above, I believe there is no guarantee that every user will always have a sort of “central” server or device with 24/7 uptime to rely on being a master consistently, and that devices should be allowed to enable/disable themselves spontaneously without noticing the transition.
Alice should, without noticing the difference, be able to reliably communicate with Bob in all of these scenarios:
And, if offline messaging is ever implemented:
The following symptoms undoubtedly imply non-solutions:
The end-user experience I propose is as follows:
Due to these constraints, I believe that it is very much a core protocol issue.
 The criteria for determining or establishing this is left open; perhaps by importing the same ID into both.
In my scenario I was selecting or forcing one of my clients to be the master just because I can, and it makes the most sense for me. In my life there is never a time where I want my phone or tablet to assume the Archival/Master role and try to hold all history and media.
The Samba file server has a option to do the same. You can force your install to become or have a better chance to become Master. Or you let all clients on the network hold a vote for who becomes Master. I don't see why the syncing infrastructure can't be changed from auto selection to Master/Slave preferred.
A large part of this ticket is going to come down to client implementations but the Tox core needs to figure out what sync messages will look like. And then we probably need to agree on some way of ordering out of order messages (mostly when syncing past history). Something like UTC time stamping messages + some kind of pad.
That would also partially fix offline messages.
This is all in my perfect imaginary world where I have global history on all my clients.
The way I would personally approach this problem is by keeping something like a hash chain of the history - every message is part of a “block” of messages, each being X messages in length (some reasonable burst transfer limit) and hashed up as a unit (together with the previous block's hash).
When initiating a chat, hashes of the the entire “history” are compared and if they're different (any message is missing somewhere), the two clients will compare their hash chains until a common basis is found - then, the oldest diverging block is transferred in both directions and both clients will apply a consistent merge strategy to merge the two together. The same procedure is repeated, always starting at the oldest block that diverges, until both have the same history.
In the simple case, where one device's history is a proper prefix of another device's history (device was simply turned off for a while) this would effectively allow for a fast-forward like git.
There are probably some kinks that have to be worked out (how to merge? How to determine which messages from my next block coincide with the other client's messages from a previous block? What happens to new messages sent while the clients are synchronizing, perhaps even many days worth of messages?)
A “simpler” approach, if the numbers/overhead allows it, would be to include a hash in every single message, which uniquely identifies it based on previous messages, effectively equal to setting the block size = 1 message.
The unfortunate downside of both these approaches is that synchronization becomes computationally quite expensive due to computing hashes of many messages, but with modern hardware that may be a reasonable constraint (phones? battery lifetime?).
I'd love to hear alternative approaches. One thing to keep in mind is that message sequencing and so forth should be as independent as possible of timezones and clock errors - clients should agree on which order messages belong in a consistent way, even if their system clocks are off by seconds or even minutes.
@haasn I thought of another way to go about it..
Let's call Bob client A and Sarah client B. And all devices owned by A and B A1, B1, A2 ect.. (Bob's computer is client A1 and Bob's cellphone is A2)
When A1 sends a new message to B, A1 attemps to start a 'Chat Session'. If both clients agree that no 'Chat Session' is taking place, then they both start a 'Chat Session' and start counting up from 0 (either incriminating every millisecond or second..). This number is attached to every message A sends to B and vice-versa, and is used to sort the history.
When A switches from A1 to A2 and sends a new message, A2 attempts to start a new 'Chat Session' (since A2 is not aware one has already started). However, B1 disagrees, and informs A2 that a 'Chat Session' is already taking place. It then gives A2 the number it should start counting up from. A2 will then try to get chat history from A1 using X method. If A1 is not available, then it asks B1 for the chat history.
If B has not received any messages from A after X amount of time (maybe 10 minutes or so..?), then the 'Chat Session' is terminated.
In this approach, chat history is kept in sync during 'Chat Sessions' without having to rely on the current time or hashes.
In the edge case that both A and B switch devices (and turned off or disconnected there old devices) at the same exact time, then the worst that happens is a new 'Chat Session' starts and history is lost, which may or may not be all that important to the end-user.
I can see some flaws with this idea, but most of the flaws have a solution (ex; the counter on A gets out of sync with B. This can be solved by a periodic check of the each client's counter using a packet, using the highest value when re-syncing)
I will drop Skype in a second if this is implemented. I absolutely require multiple devices to be active. My team is geographically distributed and uses IM 24/7 to keep in touch on operational issues, dev design, etc. I really like tox and am excited to switch, but can't unless I can have it on my debian machine, windows laptop, and android phone... keeping in touch with colleagues who run on iPhones and Macs or whatever.
Chat and call history are vital to us.
The ability to receive calls on any of the devices is also vital. Seamless switching of devices mid-call would bring parity with Skype.
Is this on the roadmap somewhere?
I think the difference is, that in contrast to XMPP and E-Mail every user runs a server instead of his provider (you can do that with the other services, too, but few users do).
Maybe not, if the clients belonging to one person know each other.
Tox is the most promising Skype alternative I have found to date, but this issue is the deal breaker. Casual users will continue to refuse to switch to Tox until it becomes easy to share some kind of identity across multiple devices. Why is there still no development on this front?
Wouldn't this solve the issue of getting messages to the user? And since the rest of the burden would be on the synchronization side (which has some reasonable solutions), this should work...
Okay, I think the idea of a primary device is not the best.
Another newbie contribution (didn't follow the discussion from the beginning, limited technical knowledge about tox):
Then, in theory, afterwards the whole thing is just another group chat ... of course meaning, that contents has to be transmitted over the network <n> times, but with any kind of sync model this is necessary too (actually I think the whole discussion about saving network traffic is pointless - either my friend's client sends data <n> times, or my devices sync among them - in the end about the same, I'd guess).
After reading #1100 and brain being close to overflow ...
@GrayHatter In general I believe I understand public key encryption, however I only have some rough idea how it is used in tox. Is there some doc (besides looking into the sources) anywhere explaining which keys are used where and how?
referenced this issue
Dec 22, 2015
Me again ... I looked through the docs that appeared relevant to me and into the sources. I'm far from understanding everything, but feel better now.
I believe that this reduces misunderstandings what we are actually talking about and hopefully provides some consensus (right now there is a set of lengthy discussion threads - hard to comprehend to newcomers like me :-)
From the usability perspective this is slightly more cumbersome than today but appears to me acceptable - think of "adding a trusted device belonging to my friend" instead of just "adding a friend" (and once I have done that, I don't need to worry about multiple devices anymore).
Disadvantage: Clients must be able to handle that user/device grouping, but does not sound too complicated to me (and if they don't, they would see multiple devices not linked together -> no major harm).
I came to a (maybe stupid) idea for multi devices.
Well, this is just an idea i got and i think that it could works if well implemented. :)
How about a WOT model
First profile-a would mark profile-b as being part of the same meta-profile
Profile-b then must do the same to profile-a.
If we want to add profile-c to this meta profile and vise versa.
profile-a and profile-b would both need to mark profile-c as being part of the meta profile
So on and so forth for the trivial implementation.
We could also make it so it only requires a majority of profiles to have marked another profile as part of the meta profile for it to be part of the meta profile.
Additionally profiles could have weights that influence how much their mark of a profile influences their acceptance into the meta-profile.
Finally if a profile is no longer marked by enough other profiles as being part of the meta-profile it should be removed from the profile.
I feel like this is a good structure because it seems theoretically more secure the more profiles you add because as you add devices it requires a greater amount of other profile to be authorized as part of the meta-profile.
Definitely do not use majority based profile merging.
Merging should be explicitly requested from all parties. I think it would be good to have an "account X has claimed identity with your account." notice, and the ability to deny that claim, or to manually reciprocate. But I don't think it'd even be a good idea to have an "ok, reciprocate" button on the notice, because users often just press the yes/ok button without actually reading the message...
On 26 March 2016 6:49:34 am AEDT, William-Shadowruby email@example.com wrote:
Sent from my Android device with K-9 Mail. Please excuse my brevity.
I've though about it a bit more and wrote a bit up
Each profile shall contain a meta-profile database.
This meta-profile database shall contain:
For a profile (hereby referred to as profile-b) to be added to the meta-profile database the following shall occur
First it shall send a request a preliminary acceptance to the meta-profile to a profile (hereby refered to as profile-a) already within the meta-profile.
Then profile-a shall respond with a preliminary accept or preliminary deny.
Profile-b then will generate a n-length random non-unicode character string to be displayed to the user and send an acceptance confirmation to profile-a.
Then the user shall enter the same string into the device with profile-a which shall send it to profile-b.
Profile-b then compares the received string from profile-a to the generated string.
If the strings are identical profile-b sends a confirm response to proflile-a.
Then profile-a shall also preform this process.
Then profile-a shall update its local meta-profile database with profile-b and broadcast to the other profiles that are part of the meta-profile that it now preliminarily-trusts profile-b.
This process is repeated for each other profile that is part of the meta-profile.
Once each profile that is part of the meta profile preliminary trust profile-b, profile-b becomes part of the meta-profile.
To remove a profile from a meta-profile each other profile shall first remove that profile from its list of trusted profiles then broadcast to the other profiles that are part of the meta-profile that it no longer trust that profile.
There should be a better process for dropping a meta-profile but I'm not sure exactly how.
The requirement of a input at both ends to confirm that a profile is part of a meta-profile containing a step that is impossible to complete unintentionally, should help migrate this issue of malicious meta-profile expanding.
But I will admit I didn't see that issue when I was initially thinking about the problem because I'm type of person who assumes user competence when I really shouldn't.
Additionally clients might implement an expected number of profiles in the meta-profile filter automatically ignoring requests that would exceed this number, with the default being 1 or the loopback.
I'm just trying to throw stuff at the wall here that seems like it would theoretically work