toxcore
toxcore copied to clipboard
irungentoo
Suggestion: Multiple devices
The optimal location for this suggestion is the Wiki. But I do not have access to that, so I decided to post this here. Feel free to move it and close this issue.
This is an alternative proposal for the one at http://wiki.tox.im/Multiple_Devices. A key feature is the fact that it does not require a change to the Tox network protocol and a client (such as Venom) can implement this.
_Summary:_ Instead of creating 2 identities and linking them, the same identity is shared over the 2 devices transparently. This reduces the technical complexity a lot, and reduces user confusion: Each user will have only one public key to share with his friends.
_How it works_:
Linking the devices (Sharing the identity): Alice already has an identity - which is a public/private key pair - on her PC, Alice decides to use her smartphone with Tox. Alice clicks a "Add an existing identity" button on the smartphone. Alice then inputs her public key. In the background, Alice's smartphone creates a temporarily identity and contacts Alice's PC via DHT. It then sends a "linking request", Alice accepts that request on her PC (We could make her type a secret phrase on both ends for security). Once the request is accepted, the Private/Public key pair is transferred - securely, either via DHT or p2p - from Alice's PC to Alice's smartphone. Alice's smartphone discards the temporarily identity and adopts the newly received one. Alice's smartphone then "goes online", see next section.
When a device goes online - Cooperation between devices sharing the same key: When a devices starts up / finishes the step above, it checks if another device is already online with the same public key (Scanning the DHT possibly requires a temporarily identity, correct me here). 2 Things can occur:
A: There is a device already online with that same public key: We'll call the device which is already online the "master" (the PC in Alice's case). We'll call the newly connecting device a "slave" (the smartphone in Alice's case).
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: In that case, the newly connecting devices connects normally using the normal Tox procedure, no science here. The devices then becomes the "master".
Some remarks:
- This also works with multiple slaves. The master should randomly choose a "top slave" among all the connected slaves, in case the master disconnects, the "top slave" becomes the master and the remaining slaves reconnect to their new master.
- The linking phase is really easy and already partially implemented: It is very similar to accepting a friend request.
- The entire procedure can be implemented via a client and does not require changes to the Tox network protocol. (But it's best to implement in Tox Core)
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.
I think I used the same terminology Tox uses. Tox Wiki refers to Venom, Toxic and the like as "clients".
I dunno but it depends on the context. A client consists of Toxcore plus a GUI. So when you say "only requires changes to clients and not to toxcore" then presumably you mean the GUI part of clients and not the Toxcore part :)
My point was that the network protocol can be left as it is now. I will correct this. Thanks :)
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. Id prefer a solution where for every device a user is online on that device place its address in the DHT with the UUID as key, that way a UUID would point to 0..n devices instead of 0..1. Small bandwith stuff as textmessages would be sent to all clients of a user and highbandwidth stuff like filetransfers etc would have to be accepted on every device individually. This would avoid most problems with a user going online/offline and devices which dont have a stable connection (mobile) as there is no synchronization. This looks like the most straight forward approach to me (on an abstract level), I dont know how much the protocol would need to be changed for this.
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.
- I have a home server (maybe you have one too, or a customizable NAS).
- I want all my logging to be on centralized
- My phone or other portable device might be broken/lost/stolen, I don't want to lose my stuff.
- If it is lost/stolen I could deauth the client from the Master and maybe the slave client has options to nuke it's cache.
- I want to minimize bandwidth usage, my carrier is shit and caps my data.
- DHT is still expensive, you guys made it a lot better lately. It's still shit on battery powered devices.
- Maybe I don't want to accept that audio/image/video file on my device at this time. 3g? public wifi?
- Until we get offline messages, I don't want to miss messages.
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. Now a lot of what I want is going to come down to client UIs. I'll need a good CLI/headless client that will centralize logging and media downloading. It will need options for creating a "supernode" that my clients sync with. I'll need a good droid/desktop client that allows me to set slave mode. Mobile clients will need options for polling and selective media download, scaling cache size etc etc. Desktop clients could care less about power and storage requirements. But the core is going to need some ground work done to enable these kinds of client UIs to be made.
I want a personal version of hangeouts with gmail history sync. Being able to sign in on
This is where I hope Tox goes.
I would like to see support for both solutions A "supernode" mode which one can use as a proxy to the tox network and full nodes with the same UUID on multiple devices.
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. What are you trying to argue?
If someone wants to use this to share their messages across devices, although it would be not very secure, they could create a custom client and server, the server acting like a standard Tox client to connect to the network. Thus, I consider this not a core issue.
@alpha-ninja So if you have multiple clients you don't think being able to continue a conversation on any of your devices is a welcome feature?
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:
- Bob has only device A running when Alice sends a new message or friend request.
- Bob has only device B running when Alice sends a new message or friend request.
- Bob has device A running, connects device B and afterwards shuts off device A. Alice sends a message immediately before device A is shut off.
- Bob has both device A and B running and sends messages to Alice using both, alternating.
- Bob has both device A and device B running when Alice attempts to call him.
- Bob calls Alice using device A, and while the call is active switches to device B.
And, if offline messaging is ever implemented:
- Bob exchanges messages with Alice using device A before shutting it off. Alice leaves Bob an offline message and turns off her device. Bob turns on device B, reads the message, and turns off device B. Bob then turns on device A.
The following symptoms undoubtedly imply non-solutions:
- Bob does not see one of Alice's messages, friend requests or calls.
- Bob sees one of Alice's messages duplicated on a single device.
- Bob sees one of Alice's messages, friend requests or calls on one device but not another.
- Bob accepts Alice's call on one device but receives audio/video data sent to the other.
- Bob accepts Alice's call on one device but cannot continue the discussion on another device.
- Bob can only synchronize messages or calls between devices if they are using the same client software.
The end-user experience I propose is as follows:
- Messages should silently and transparently synchronize between devices belonging to the same user[1] without that user's explicit interaction.
- Offline messages (if they are implemented) should ideally be delivered to all devices even if some other device (that is now offline) already read them, perhaps within a reasonable time-frame.
- Calls should connect between individual devices but should be allowed to “transfer” between devices - if you pick up device A while having an active call on device B, you will see that you're in a call on device A and have the ability to “transfer” the call there, transparent to Alice. (Aside from differences in audio characteristics, of course)
- Synchronization should be transparent across Tox clients - perhaps I am using a mobile client on my phone, a curses client on Linux and a GUI client when dual booted to Windows.
Due to these constraints, I believe that it is very much a core protocol issue.
[1] 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.
- Bob's phone goes offline (phone dies? cuts off 3g?)
- Alice sends a message soon after and it goes to Bob's PC instead.
- some hours pass and Bob's PC goes to sleep
- Bob's phone comes back online and he says "Hey alice"
- Alice's client knows the last few messages went to another client and it asks the current client what it got last
- Bob's phone replies with a time stamp that is older since his PC picked up a few messages Then Alice and Bob could resend the missing messages and later Bob's clients could sync between themselves.
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.
You're welcome! I'm glad it kick-started a discussion and I hope it gets implemented. I will join the discussion soon.
@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?
Just a note: For people running a central machine, the protocol could be replaced with something super simple: Just a single tox client which offers an interface to the other devices.
wiseoldman95, but that would already be a server, won't it. Ant we don't want no servers here, do we.
It would be an alternate client. If you will, the standard clients are also servers and the clients are the users themselves. I do not see how this would change things because it does not impact the tox network, it only affects the client side.
mightyCelu, I don't really see a difference from XMPP-ish or E-mail-ish server that way. Central node fails and ruins all the clients connected to it, although the network is unaffected. That's the problem.
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). I still think tox should support multiple devices with syncing contacts and messages but it does not need a solution where one client is the "leader" becasue this can be done on the client side without changing the protocol.
Maybe not, if the clients belonging to one person know each other. I think, it might work this way then: Here, we have Alice. She has a PC with Tox client installed. She buys a new phone, installs a Tox client on it, and somehow tells a client on PC that the phone is her other device. And even gives the name (which is visible) to go with it. "OK", says the PC client. Now, if message arrives to the phone, the phone tells the PC "Here, there was a message to me, you should see it too." Then, Alice buys, I don't know, a tablet. And tells the phone that the tablet is her other device. "OK", says the phone. Then, it goes to tell other clients about new device, which in this case will be a PC. So, if one client gets a message it broadcasts it to all the others. If one more device is added (I don't know, a Tamogochi), the knowledge about this client propogates to all others, and all clients store a list of other clients belonging to the same person.
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?
@Oddwarg because no one has a solution that doesn't pose a security risk. Every workable solution I've seen either requires you trust some central authority, or allows for impersonation. Both of which negates the point of Tox existing.
What's the problem with adding a new device as a friend, specifying that you want to connect the profile, putting in some PIN from one device on the other, and then updating your friends to send messages to all your devices?
Alice uses Tox Profile A to talk to Dan.
Alice gets a phone and installs Antox on it, generating Tox Profile B.
Alice goes into her settings on Tox Profile A and puts B's ID into the Add Device field.
A sends a special friend request to B, and A displays a 4-digit PIN.
B receives the request and pops up a dialog asking for the PIN.
When the PIN is correctly entered, A and B are connected and begin syncing message history, friends, etc using file transfers. A broadcasts to all contacts that it is also reachable at B now. Contacts' clients store this information however the multidevice spec says to.
Now when Dan sends a message to Alice it goes to both of her devices, which may themselves negotiate when each should alert or be silent (the way iMessage is supposed to be silenced on a phone when you're near your laptop).
Now tell me all the problems.
@GrayHatter @ProMcTagonist idea is very similar to what firefox sync uses or bluetooth for device paring.
