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

Update 'MultiDevice Announcements POC'

emdee 2022-10-03 09:46:19 +02:00
parent cc75b887da
commit 9fcbd278b0
1 changed files with 58 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

60
MultiDevice-Announcements-POC.md

@ -1,6 +1,6 @@
Previous: [[Home]]
We need to solve the usage of Tox with multiple devices.
## We need to solve the usage of Tox with multiple devices.
The idea here is to address one simple usecase: a person can have multiple devices and he wants one device to be "active" at any given time. So he pushes an annoucement of what device he is currently using so that others can communicate to the device he is using.
@ -21,4 +21,60 @@ So we can add this layer of PersonaID->ToxID mapping to the library and all clie
So we could get the whole network switched over to accomodating PersonaIDs with no breakage.
Next: [[MultiDeviceAnnouncementsPush]]
## MultiDevice Announcements Push
So if we modify the library and clients as described in MultiDeviceAnnouncementsPOC
how do we keep it up to date when a friend changes his devices.
If we know the PersonaID, how is the library code table of PersonaID to ToxID mapping updated. We want this to be mainly automatic without bothering the user.
We would need to modify the profile code to save a copy if the mapping table,
so that when we start up a client, the mapping table is filled with last good values from the profile.
Lets say we have a friend, and we know his ToxID. We derive his PersonaID by setting the checksum to 0s. We want to watch the DHT announcements for a blob of information that will update our PersonaID mapping to his active ToxID.
Note that if we do so that destroys the possibility to simply derive the PersonaID from the ToxID. That derivation is a startup mechanism to get the network switched over to client-facing PersonaIDs, and after that we rely on the profile to boostrap the 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.
The clients lets a Persona push a blob whenever he wants - like when he changes devices.
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/
It has these characteristics:
1) It has 2 things - a name and a payload.
2) It is small - 1K to 4K in size.
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.
5) It is encrypted so that the contents can not be seen in transit.
6) It is encrypted so that it can be verified to be from the PersonaID.
So here is a best guess of how the encryption works. I'm not a crypto guy, so please take it with a grain of salt and help with suggestions.
The blob is intended to be the mapping to an active ToxID, and could be a mapping to a set of ToxIDs, the set of that Personas devices, with one marked active. This set of ToxIDs could be keys that open the encrypted blob. Anyone who already has a ToxID of the Persona could open the blob to get the update. So this encryption is different from most Tox encryption in that multiple keys can open it.
Unknown for now is does the client have to send an add request to the new ToxID to make it active if they have never seen it before? I assume yes.
Either way the clients would manage this seemlessly to aggregate the two ToxIDs 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 ToxID.
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>