New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suggestion: Multiple devices #843

Open
SafwatHalaby opened this Issue Apr 25, 2014 · 70 comments

Comments

Projects
None yet
@SafwatHalaby

SafwatHalaby commented Apr 25, 2014

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:

  1. 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.
  2. The linking phase is really easy and already partially implemented: It is very similar to accepting a friend request.
  3. 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)
@ameenross

This comment has been minimized.

Show comment
Hide comment
@ameenross

ameenross Apr 25, 2014

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.

ameenross commented Apr 25, 2014

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.

@SafwatHalaby

This comment has been minimized.

Show comment
Hide comment
@SafwatHalaby

SafwatHalaby Apr 25, 2014

I think I used the same terminology Tox uses. Tox Wiki refers to Venom, Toxic and the like as "clients".

SafwatHalaby commented Apr 25, 2014

I think I used the same terminology Tox uses. Tox Wiki refers to Venom, Toxic and the like as "clients".

@ameenross

This comment has been minimized.

Show comment
Hide comment
@ameenross

ameenross Apr 25, 2014

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 :)

ameenross commented Apr 25, 2014

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 :)

@SafwatHalaby

This comment has been minimized.

Show comment
Hide comment
@SafwatHalaby

SafwatHalaby Apr 25, 2014

My point was that the network protocol can be left as it is now. I will correct this. Thanks :)

SafwatHalaby commented Apr 25, 2014

My point was that the network protocol can be left as it is now. I will correct this. Thanks :)

@mightyCelu

This comment has been minimized.

Show comment
Hide comment
@mightyCelu

mightyCelu Aug 13, 2014

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.

mightyCelu commented Aug 13, 2014

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.

@weedy

This comment has been minimized.

Show comment
Hide comment
@weedy

weedy Aug 14, 2014

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 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.

weedy commented Aug 14, 2014

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 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.

@mightyCelu

This comment has been minimized.

Show comment
Hide comment
@mightyCelu

mightyCelu Aug 14, 2014

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.

mightyCelu commented Aug 14, 2014

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.

@weedy

This comment has been minimized.

Show comment
Hide comment
@weedy

weedy Aug 14, 2014

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?

weedy commented Aug 14, 2014

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?

@alpha-ninja

This comment has been minimized.

Show comment
Hide comment
@alpha-ninja

alpha-ninja Aug 15, 2014

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 commented Aug 15, 2014

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.

@weedy

This comment has been minimized.

Show comment
Hide comment
@weedy

weedy Aug 16, 2014

@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?

weedy commented Aug 16, 2014

@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?

@haasn

This comment has been minimized.

Show comment
Hide comment
@haasn

haasn Aug 16, 2014

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.

haasn commented Aug 16, 2014

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.

@weedy

This comment has been minimized.

Show comment
Hide comment
@weedy

weedy Aug 16, 2014

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.

weedy commented Aug 16, 2014

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.

@haasn

This comment has been minimized.

Show comment
Hide comment
@haasn

haasn Aug 16, 2014

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 commented Aug 16, 2014

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.

@SecUpwN

This comment has been minimized.

Show comment
Hide comment
@SecUpwN

SecUpwN Aug 17, 2014

@wiseoldman95, thanks for opening up this Issue! Following it closely now.

SecUpwN commented Aug 17, 2014

@wiseoldman95, thanks for opening up this Issue! Following it closely now.

@SafwatHalaby

This comment has been minimized.

Show comment
Hide comment
@SafwatHalaby

SafwatHalaby Aug 22, 2014

You're welcome! I'm glad it kick-started a discussion and I hope it gets implemented. I will join the discussion soon.

SafwatHalaby commented Aug 22, 2014

You're welcome! I'm glad it kick-started a discussion and I hope it gets implemented. I will join the discussion soon.

@edkek

This comment has been minimized.

Show comment
Hide comment
@edkek

edkek Aug 30, 2014

@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)

edkek commented Aug 30, 2014

@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)

@davidbenoit

This comment has been minimized.

Show comment
Hide comment
@davidbenoit

davidbenoit Nov 29, 2014

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?

davidbenoit commented Nov 29, 2014

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?

@SafwatHalaby

This comment has been minimized.

Show comment
Hide comment
@SafwatHalaby

SafwatHalaby Dec 2, 2014

@davidbenoit No progress has been done as far as I know.

SafwatHalaby commented Dec 2, 2014

@davidbenoit No progress has been done as far as I know.

@SafwatHalaby

This comment has been minimized.

Show comment
Hide comment
@SafwatHalaby

SafwatHalaby Dec 2, 2014

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.

SafwatHalaby commented Dec 2, 2014

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.

@drequivalent

This comment has been minimized.

Show comment
Hide comment
@drequivalent

drequivalent Dec 20, 2014

wiseoldman95, but that would already be a server, won't it. Ant we don't want no servers here, do we.

drequivalent commented Dec 20, 2014

wiseoldman95, but that would already be a server, won't it. Ant we don't want no servers here, do we.

@mightyCelu

This comment has been minimized.

Show comment
Hide comment
@mightyCelu

mightyCelu Dec 20, 2014

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 commented Dec 20, 2014

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.

@drequivalent

This comment has been minimized.

Show comment
Hide comment
@drequivalent

drequivalent Dec 20, 2014

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.

drequivalent commented Dec 20, 2014

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.

@mightyCelu

This comment has been minimized.

Show comment
Hide comment
@mightyCelu

mightyCelu Dec 20, 2014

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.

mightyCelu commented Dec 20, 2014

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.

@drequivalent

This comment has been minimized.

Show comment
Hide comment
@drequivalent

drequivalent Dec 20, 2014

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.

drequivalent commented Dec 20, 2014

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.

@Oddwarg

This comment has been minimized.

Show comment
Hide comment
@Oddwarg

Oddwarg Oct 12, 2015

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 commented Oct 12, 2015

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?

@GrayHatter

This comment has been minimized.

Show comment
Hide comment
@GrayHatter

GrayHatter Oct 12, 2015

Collaborator

@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.

Collaborator

GrayHatter commented Oct 12, 2015

@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.

@ProMcTagonist

This comment has been minimized.

Show comment
Hide comment
@ProMcTagonist

ProMcTagonist Oct 12, 2015

Contributor

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?

Contributor

ProMcTagonist commented Oct 12, 2015

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?

@ProMcTagonist

This comment has been minimized.

Show comment
Hide comment
@ProMcTagonist

ProMcTagonist Oct 14, 2015

Contributor

@hypereddie Yes, of course multiple device IDs would be transparent to end users. It's a bandwidth/cycles problem.

Contributor

ProMcTagonist commented Oct 14, 2015

@hypereddie Yes, of course multiple device IDs would be transparent to end users. It's a bandwidth/cycles problem.

@edkek

This comment has been minimized.

Show comment
Hide comment
@edkek

edkek Oct 14, 2015

It's a bandwidth/cycles problem.

Maybe I'm missing the concern..but you're gonna have to spend bandwidth somewhere to get the messages to each device ¯_(ツ)_/¯

edkek commented Oct 14, 2015

It's a bandwidth/cycles problem.

Maybe I'm missing the concern..but you're gonna have to spend bandwidth somewhere to get the messages to each device ¯_(ツ)_/¯

@ProMcTagonist

This comment has been minimized.

Show comment
Hide comment
@ProMcTagonist

ProMcTagonist Oct 14, 2015

Contributor

@hypereddie

ameenross commented a day ago

Then if that one goes offline friends won't know about other devices. Not acceptable user experience.

I didn't mean that clients shouldn't know about the various devices of friends, rather the contrary. But it should select one of the online devices to send messages to. The receiver has to do message synching anyway, it's inevitable. And I don't think people would be happy if they have to send that PDF/jpg/whatever 5 times just because their contact is online on 5 devices.

Contributor

ProMcTagonist commented Oct 14, 2015

@hypereddie

ameenross commented a day ago

Then if that one goes offline friends won't know about other devices. Not acceptable user experience.

I didn't mean that clients shouldn't know about the various devices of friends, rather the contrary. But it should select one of the online devices to send messages to. The receiver has to do message synching anyway, it's inevitable. And I don't think people would be happy if they have to send that PDF/jpg/whatever 5 times just because their contact is online on 5 devices.

@JacobHenner

This comment has been minimized.

Show comment
Hide comment
@JacobHenner

JacobHenner Oct 14, 2015

Contributor

For the second, could some sort of revocable signature be stored in the DHT? A client can sign other identities as theirs (just as they specify these identities, see above), and when an identity is requested, the DHT returns all associated? This would require all linked identities to have signed each other. A revocation from any associated client would void the connection, and messages would only be sent the the identity of the original friend request.
Alternatively, the signing can occur, and then the linked clients can send the signatures to all contacts on the friends list. Revocation would work similarly. Of course, there would be a bit more lag here than if the info was simply maintained in the DHT somehow.

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...

Contributor

JacobHenner commented Oct 14, 2015

For the second, could some sort of revocable signature be stored in the DHT? A client can sign other identities as theirs (just as they specify these identities, see above), and when an identity is requested, the DHT returns all associated? This would require all linked identities to have signed each other. A revocation from any associated client would void the connection, and messages would only be sent the the identity of the original friend request.
Alternatively, the signing can occur, and then the linked clients can send the signatures to all contacts on the friends list. Revocation would work similarly. Of course, there would be a bit more lag here than if the info was simply maintained in the DHT somehow.

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...

@mightyCelu

This comment has been minimized.

Show comment
Hide comment
@mightyCelu

mightyCelu Oct 17, 2015

Okay, I think the idea of a primary device is not the best.
Regarding the signed multiple device IDs: How exactly would the revocation work? If every device have to sign each other's ID there are lots of opportunity to have a corrupted, maybe even fragmenting fragmenting the devices so that the friends are connected to different fragments.

mightyCelu commented Oct 17, 2015

Okay, I think the idea of a primary device is not the best.
Regarding the signed multiple device IDs: How exactly would the revocation work? If every device have to sign each other's ID there are lots of opportunity to have a corrupted, maybe even fragmenting fragmenting the devices so that the friends are connected to different fragments.

@tge12345

This comment has been minimized.

Show comment
Hide comment
@tge12345

tge12345 Dec 21, 2015

Another newbie contribution (didn't follow the discussion from the beginning, limited technical knowledge about tox):
What about having TWO tox IDs - one per user and one per device, so I personally am 12345 and my two devices are 23456 and 34567. When I log on, I register the current user/device ID pair(s). My friends only need to know 12345, their clients have to show only my user ID if there is at least one of my devices.
The user ID just identifies me, the device IDs are used the same way as the ID today for communication.

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).
No idea yet about key exchange etc, but maybe this yields some inspiration ... if this is complete bullshit, please just silently ignore it ... :-)
Ahh, possibly a duplicate (still reading) of #1100 ...
BTW: That frequently referenced wiki page seems not to exist anywhere anymore?

tge12345 commented Dec 21, 2015

Another newbie contribution (didn't follow the discussion from the beginning, limited technical knowledge about tox):
What about having TWO tox IDs - one per user and one per device, so I personally am 12345 and my two devices are 23456 and 34567. When I log on, I register the current user/device ID pair(s). My friends only need to know 12345, their clients have to show only my user ID if there is at least one of my devices.
The user ID just identifies me, the device IDs are used the same way as the ID today for communication.

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).
No idea yet about key exchange etc, but maybe this yields some inspiration ... if this is complete bullshit, please just silently ignore it ... :-)
Ahh, possibly a duplicate (still reading) of #1100 ...
BTW: That frequently referenced wiki page seems not to exist anywhere anymore?

@GrayHatter

This comment has been minimized.

Show comment
Hide comment
@GrayHatter

GrayHatter Dec 21, 2015

Collaborator

@tge12345 it's not a bad idea, we've talked about that style already. The problem with this one that no one's come up with a good solution to, is how to transfer around the private keys needed to decrypt all the messages.

Collaborator

GrayHatter commented Dec 21, 2015

@tge12345 it's not a bad idea, we've talked about that style already. The problem with this one that no one's come up with a good solution to, is how to transfer around the private keys needed to decrypt all the messages.

@tge12345

This comment has been minimized.

Show comment
Hide comment
@tge12345

tge12345 Dec 21, 2015

After reading #1100 and brain being close to overflow ...
@GrayHatter Somewhere there was a proposal that sounded quite logical to me, something like this (if understood correctly):
The only key to exchange would be the one of my user ID, and between my devices, and only once. And, the devices sit right in front of me while doing that. No such thing as master/slave or primary/secondary.
Device 23456 is already in use, let's call it initial, same as single-device. Now I want to add device 34567, perform a regular set-up on 34567, then I have two entirely independent devices in front of me (the new one has a new user ID too, 11111). Now I can securely communicate between both, because I'm both users and have both devices. From the initial device I send the profile data of 12345, on the new device I "accept and replace". Done.
Again, humble disclaimer: Of course it cannot be that simple, or somebody else would have come up with it already ...

tge12345 commented Dec 21, 2015

After reading #1100 and brain being close to overflow ...
@GrayHatter Somewhere there was a proposal that sounded quite logical to me, something like this (if understood correctly):
The only key to exchange would be the one of my user ID, and between my devices, and only once. And, the devices sit right in front of me while doing that. No such thing as master/slave or primary/secondary.
Device 23456 is already in use, let's call it initial, same as single-device. Now I want to add device 34567, perform a regular set-up on 34567, then I have two entirely independent devices in front of me (the new one has a new user ID too, 11111). Now I can securely communicate between both, because I'm both users and have both devices. From the initial device I send the profile data of 12345, on the new device I "accept and replace". Done.
Again, humble disclaimer: Of course it cannot be that simple, or somebody else would have come up with it already ...

@GrayHatter

This comment has been minimized.

Show comment
Hide comment
@GrayHatter

GrayHatter Dec 21, 2015

Collaborator

@tge12345 no, that wouldn't work, to decrypt packets you'd need the private key on every device you want to use. Forget anything about user_id. Think only of private and public keys. To read data you need the private key.

Collaborator

GrayHatter commented Dec 21, 2015

@tge12345 no, that wouldn't work, to decrypt packets you'd need the private key on every device you want to use. Forget anything about user_id. Think only of private and public keys. To read data you need the private key.

@tge12345

This comment has been minimized.

Show comment
Hide comment
@tge12345

tge12345 Dec 21, 2015

@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?
Ah, found the NaCl doc ... reading ...

tge12345 commented Dec 21, 2015

@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?
Ah, found the NaCl doc ... reading ...

@tge12345

This comment has been minimized.

Show comment
Hide comment
@tge12345

tge12345 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.
Now I have two aspects:

  1. is there something like a structured requirement spec, something like:
  • what do we (and supposedly users) actually want when talking about
    multi-device-support? Probably broken down into sub-requirements,
    considering all perspectives, like end-user experience perspective
    (usability), security, ...
  • for each such requirement, what are the solution options (pros,
    cons, effort, ...)
  • all of that in a textual form and some summary table rating all
    options, ultimately yielding the best solution

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 :-)
I think that the wiki would be a good place to do this and everybody can nicely contribute.

  1. Technically, I'm still pondering about that idea of separate user and device IDs, particularly (again, disclaimer: still limited knowledge):
  • today there is a group chat function which allows to talk to set of
    remote tox IDs
  • keeping this very concept but replace "tox ID" by "device ID" would
    not change anything so far - applicable to all communication and
    encryption aspects
  • Now linking the device IDs of a user together could be done on client
    level (as described in https://github.com/GrayHatter/uTox/issues/97). I never tried it but imagine
    it fairly close to what I have in mind - the only disadvantage I see
    is that all my peer friends have to group my devices individually
    (assuming, I have multiple devices).
    If there were something like a "directory level" on top of the
    device IDs in the DHT, e.g. "userID -> deviceID" (created whenever a
    device starts up, the device must know the user ID) used purely as a
    "name service" -> no need to transfer keys around (a user is just an
    ID or even a textual name like "tge12345", no need to
    worry about collisions as this is in the scope of my devices only).
    The userID could be part of the encrypted DHT entry of the device,
    so it is not visible anywhere -> nobody else would be able to
    claim to be me (and even if - see below).
    The device-DHT-entry could even contain the list of
    other devices belonging to a user, just for detecting imposters
    (however that might be more complicated and not necessary)
  • As a user I continue to give my friends all my device IDs, their
    clients starts up, looks through their friends (now devices) to see
    who is online and collect the userIDs
  • The whole procedure would be completely optional - if I have only one
    device, I register no userID and everything behaves as-is
  • If I add a second device, I imagine something as posted earlier:
    regular install new device (generates new keys and device ID), I
    manually "send user data" from initial to new device and "accept" it
    there (or just manually configure the "user ID" in the new client ...). The new device updates it's DHT entry with the new user ID.
  • How to prevent that somebody else claims to be user "tge12345"? Not
    needed at all, as long as my friends don't add any unknown device IDs
    (as they are not supposed to today either), they will never see any
    false tge12345 devices. As stated above, there is even nothing wrong
    with multiple users with the same name/ID (only the clients have to
    deal with that when displaying/grouping)

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).
In theory clients would/should even be able to expose the user/device relationship and for example, allow sending data explicitly to specific devices (I tell my friend before: "please send that large image to my laptop only")

tge12345 commented 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.
Now I have two aspects:

  1. is there something like a structured requirement spec, something like:
  • what do we (and supposedly users) actually want when talking about
    multi-device-support? Probably broken down into sub-requirements,
    considering all perspectives, like end-user experience perspective
    (usability), security, ...
  • for each such requirement, what are the solution options (pros,
    cons, effort, ...)
  • all of that in a textual form and some summary table rating all
    options, ultimately yielding the best solution

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 :-)
I think that the wiki would be a good place to do this and everybody can nicely contribute.

  1. Technically, I'm still pondering about that idea of separate user and device IDs, particularly (again, disclaimer: still limited knowledge):
  • today there is a group chat function which allows to talk to set of
    remote tox IDs
  • keeping this very concept but replace "tox ID" by "device ID" would
    not change anything so far - applicable to all communication and
    encryption aspects
  • Now linking the device IDs of a user together could be done on client
    level (as described in https://github.com/GrayHatter/uTox/issues/97). I never tried it but imagine
    it fairly close to what I have in mind - the only disadvantage I see
    is that all my peer friends have to group my devices individually
    (assuming, I have multiple devices).
    If there were something like a "directory level" on top of the
    device IDs in the DHT, e.g. "userID -> deviceID" (created whenever a
    device starts up, the device must know the user ID) used purely as a
    "name service" -> no need to transfer keys around (a user is just an
    ID or even a textual name like "tge12345", no need to
    worry about collisions as this is in the scope of my devices only).
    The userID could be part of the encrypted DHT entry of the device,
    so it is not visible anywhere -> nobody else would be able to
    claim to be me (and even if - see below).
    The device-DHT-entry could even contain the list of
    other devices belonging to a user, just for detecting imposters
    (however that might be more complicated and not necessary)
  • As a user I continue to give my friends all my device IDs, their
    clients starts up, looks through their friends (now devices) to see
    who is online and collect the userIDs
  • The whole procedure would be completely optional - if I have only one
    device, I register no userID and everything behaves as-is
  • If I add a second device, I imagine something as posted earlier:
    regular install new device (generates new keys and device ID), I
    manually "send user data" from initial to new device and "accept" it
    there (or just manually configure the "user ID" in the new client ...). The new device updates it's DHT entry with the new user ID.
  • How to prevent that somebody else claims to be user "tge12345"? Not
    needed at all, as long as my friends don't add any unknown device IDs
    (as they are not supposed to today either), they will never see any
    false tge12345 devices. As stated above, there is even nothing wrong
    with multiple users with the same name/ID (only the clients have to
    deal with that when displaying/grouping)

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).
In theory clients would/should even be able to expose the user/device relationship and for example, allow sending data explicitly to specific devices (I tell my friend before: "please send that large image to my laptop only")

@drequivalent

This comment has been minimized.

Show comment
Hide comment
@drequivalent

drequivalent Feb 28, 2016

It's been a year already. Any progress on that?

drequivalent commented Feb 28, 2016

It's been a year already. Any progress on that?

@GrayHatter

This comment has been minimized.

Show comment
Hide comment
@SkyzohKey

This comment has been minimized.

Show comment
Hide comment
@SkyzohKey

SkyzohKey Mar 10, 2016

I came to a (maybe stupid) idea for multi devices.
Why not having 2 keypair. I mean, when the user create it's profile toxcore would generate an account_keypair and a profile_keypair. Then the profile would add the account via it's public_key. Another client could link to the "account" by adding it via the account_pubkey. When linked, the account would send it's private_key to the other device in order for it to also have a copy of the account (friends, etc). Of course, this would need to be secure.

ie. profiles[pn]accountfriends[fn]
Where fn is the friends_number and pn the profiles_number.
Basically friends would add you using the account_pubkey. The the account part would send the request to all the connected and linked profiles. The same would apply for other actions (messages, audio, etc).

Well, this is just an idea i got and i think that it could works if well implemented. :)

SkyzohKey commented Mar 10, 2016

I came to a (maybe stupid) idea for multi devices.
Why not having 2 keypair. I mean, when the user create it's profile toxcore would generate an account_keypair and a profile_keypair. Then the profile would add the account via it's public_key. Another client could link to the "account" by adding it via the account_pubkey. When linked, the account would send it's private_key to the other device in order for it to also have a copy of the account (friends, etc). Of course, this would need to be secure.

ie. profiles[pn]accountfriends[fn]
Where fn is the friends_number and pn the profiles_number.
Basically friends would add you using the account_pubkey. The the account part would send the request to all the connected and linked profiles. The same would apply for other actions (messages, audio, etc).

Well, this is just an idea i got and i think that it could works if well implemented. :)

@ProMcTagonist

This comment has been minimized.

Show comment
Hide comment
@ProMcTagonist

ProMcTagonist Mar 11, 2016

Contributor

the account would send it's private_key to the other device

pls no

Contributor

ProMcTagonist commented Mar 11, 2016

the account would send it's private_key to the other device

pls no

@GrayHatter

This comment has been minimized.

Show comment
Hide comment
@GrayHatter

GrayHatter Mar 11, 2016

Collaborator

@SkyzohKey come talk with is in #tox-dev on freenode, that's a much better place for ideas, and comments

Collaborator

GrayHatter commented Mar 11, 2016

@SkyzohKey come talk with is in #tox-dev on freenode, that's a much better place for ideas, and comments

@wxyangf

This comment has been minimized.

Show comment
Hide comment
@wxyangf

wxyangf Mar 25, 2016

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.

wxyangf commented Mar 25, 2016

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.

@naught101

This comment has been minimized.

Show comment
Hide comment
@naught101

naught101 Mar 25, 2016

Definitely do not use majority based profile merging.

For example:

  • my grandmother creates a tox, so she can communicate securely with my family.
  • evil cracker creates 3 tox accounts, merges them, and then claims that my grandmother's account is part of the same profile.
  • my dad sends my grandmother his credit card details, thinking the line is secure, but the message actually goes to the evil cracker as well.

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 notifications@github.com wrote:

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.


You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
#843 (comment)

Sent from my Android device with K-9 Mail. Please excuse my brevity.

naught101 commented Mar 25, 2016

Definitely do not use majority based profile merging.

For example:

  • my grandmother creates a tox, so she can communicate securely with my family.
  • evil cracker creates 3 tox accounts, merges them, and then claims that my grandmother's account is part of the same profile.
  • my dad sends my grandmother his credit card details, thinking the line is secure, but the message actually goes to the evil cracker as well.

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 notifications@github.com wrote:

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.


You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
#843 (comment)

Sent from my Android device with K-9 Mail. Please excuse my brevity.

@SkyzohKey

This comment has been minimized.

Show comment
Hide comment
@SkyzohKey

SkyzohKey Mar 26, 2016

The multidevice pairing should be done with a QR Code or a temporary generated key from the "main" profile, this would avoid any possibility an evil guy could know the key and avoid the user having to click yes/no ;)

SkyzohKey commented Mar 26, 2016

The multidevice pairing should be done with a QR Code or a temporary generated key from the "main" profile, this would avoid any possibility an evil guy could know the key and avoid the user having to click yes/no ;)

@wxyangf

This comment has been minimized.

Show comment
Hide comment
@wxyangf

wxyangf Mar 26, 2016

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:
* A List of other profiles in the meta profile
* Each profile in this list should contain a list of the profiles that trust this profile

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.

@naught101

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

wxyangf commented Mar 26, 2016

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:
* A List of other profiles in the meta profile
* Each profile in this list should contain a list of the profiles that trust this profile

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.

@naught101

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

@ewtoombs

This comment has been minimized.

Show comment
Hide comment
@ewtoombs

ewtoombs Apr 22, 2017

Has any progress been made here? This is a huge gaping hole in tox's feature set.

ewtoombs commented Apr 22, 2017

Has any progress been made here? This is a huge gaping hole in tox's feature set.

@GrayHatter

This comment has been minimized.

Show comment
Hide comment
@GrayHatter

GrayHatter Apr 22, 2017

Collaborator

yes, I've merged v0.1.4 into my multidevice branch. And I'm working on hammering out all the remaining bugs.

I'll release something once it can create working save files again; right now, that's the only reason uTox doesn't support mdevice.

Collaborator

GrayHatter commented Apr 22, 2017

yes, I've merged v0.1.4 into my multidevice branch. And I'm working on hammering out all the remaining bugs.

I'll release something once it can create working save files again; right now, that's the only reason uTox doesn't support mdevice.

@heyakyra

This comment has been minimized.

Show comment
Hide comment
@heyakyra

heyakyra Jan 26, 2018

Can this report be officially closed then?

heyakyra commented Jan 26, 2018

Can this report be officially closed then?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment