emdee/tox_profile
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Update 'MultiDevice Announcements POC'

emdee 2022-10-07 09:10:01 +02:00
parent d5911a0ed7
commit 1a2b5f8755
1 changed files with 16 additions and 18 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

34
MultiDevice-Announcements-POC.md

@ -32,18 +32,15 @@ so that when we start up a client, the mapping table is filled with last good va
Lets say we have a friend, and we know his ToxPk. We initially derive his PersonaID by setting it to the friend's public key. We want to watch the DHT announcements for a blob of information that will update our PersonaID mapping to his active ToxID.
Or we could have a univeral group which includes all of my Friends automatically, that has a steady stream of this update information: the contents of the blob are sent to the group along with a NaCl signature of the contents. The public signing key could be put into the status message field of each user, and if each user put the same signature public key as the status message on each of his devices, then that signature pk can become the PersonaID. The mapping table can be automatically scanned and any entries for which the PersonaID == ToxPk could be automatically updated to use the signing key as the PersonaId.
Or we could have a automatically created NGC group which includes all of my Friends automatically, that has a steady stream of this update information: the contents of the blob are sent to the group along with a NaCl signature of the contents. The public signing key could be put into the status message field of each user, and if each user put the same signature public key as the status message on each of his devices, then that signature pk can become the PersonaID. The mapping table can be automatically scanned and any entries for which the PersonaID == ToxPk could be automatically updated to use the signing key as the PersonaId. The NGC group does not need to be shown to the user by clients, but the client would parse the stream, and parse the entries, verify the signature based on the signing Pk found in the friend's status message, and the client and library update the PersonaID table.
The library and the clients add one new feature: the ability of the client to express interest in a PersonaID and to update the table with the new ToxID found un the blob when it arrives. Or for privacy, we could limit the interest in the list of the ToxPks of out friends.
The clients lets a user push a blob whenever he wants - like when he changes devices. You could push a blob, or have a message containing the blob information pushed to the universal group.
The clients lets a user push a blob whenever he wants - like when he changes devices. You could push a blob, or have a message containing the blob information pushed to the group of friends.
Some clients may let the user decide whether of not to accept a blob update when it arrives.
## MultiDevice Announcements Blob
So what is the blob of information that is pushed by DHT annoucements/
So what is the blob of information that is pushed by DHT annoucements, or in the messages to the friends group?
It has these characteristics:
@ -53,7 +50,7 @@ It has these characteristics:
3) The name is related to, and derivable from, the PersonaID - say the name is the PersonaID for now.
4) It it pushed regularly so people can get the PersonaID relatively soon - say hourly for now. Any longer means a person who has not connected to that friend before has to wait longer if they only have a PersonaID.
4) It it pushed regularly so people can get the PersonaID relatively soon - say hourly for now. Any longer means a person who has not connected to that friend before has to wait longer if they only have a PersonaID. This is also true if we push the blob info to a friend NGC group as the messages are not buffered if offline.
5) It might be encrypted so that the contents can not be seen in transit.
@ -78,6 +75,18 @@ Unknown for now is does the client have to send an add request to the new ToxID
Either way the clients would manage this seemlessly to aggregate the two ToxPks together under one Persona that is shown to the user. The library does most of this by accepting the update from the blob to update the table pointing from PersonaID to the new ToxPk.
## MultiDevice Profiles
In order for MultiDevice to work, we need to bootstrap a new devices from an
existing profile. We assume all clients use a common tox profile format, though
most complement the Tox profile with an ini file or similar.
If you just copy a profile from one device to the next it will not work as
you cannot have 2 profiles with the same keys online at the same time. We could have a simple utility that rekeys a profile and creates a new ToxID, so that we could copy a profile and rekey it. Then the new client running the rekeyed profile could send a DHT announcement updating to the new ToxID. The old keys would be added to the new profile's friends list.
The profile rekey utility could also do other things at the same time, like empty the TCP_RELAYS section of the profile if desired. See <https://git.plastiras.org/emdee/tox_profile>
## MultiDevice Groups
Previously, we described how we simply copy a profile to a new devices and change the public/private keys as a starting point.
@ -105,14 +114,3 @@ There is Pythonscript to parse profiles that could be modified to rekey them at:
https://git.plastiras.org/emdee/tox_profile
## MultiDevice Profiles
In order for MultiDevice to work, we need to bootstrap a new devices from an
existing profile. We assume all clients use a common tox profile format, though
most complement the Tox profile with an ini file or similar.
If you just copy a profile from one device to the next it will not work as
you cannot have 2 profiles with the same keys online at the same time. We could have a simple utility that rekeys a profile and creates a new ToxID, so that we could copy a profile and rekey it. Then the new client running the rekeyed profile could send a DHT announcement updating to the new ToxID. The old keys would be added to the new profile's friends list.
The profile rekey utility could also do other things at the same time, like empty the TCP_RELAYS section of the profile if desired. See <https://git.plastiras.org/emdee/tox_profile>