emdee/tox_profile
2
3
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Update 'MultiDevice Announcements POC'

emdee 2022-10-09 15:25:20 +02:00
parent 5d9a9e25a9
commit 34a8344ffc
1 changed files with 35 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

49
MultiDevice-Announcements-POC.md

@ -5,7 +5,7 @@ Previous: [[Home]]
This is based on the premise that solving the usage of Tox with multiple devices This is based on the premise that solving the usage of Tox with multiple devices
is an urgent problem, as anyone with mobiles runs into it, and all the competion software deals with it. is an urgent problem, as anyone with mobiles runs into it, and all the competion software deals with it.
** Woke Warning: gender specific, non-android friendly gammar and pronouns are used. ** _ Woke Warning: gender specific, non-android friendly gammar and pronouns are used. _
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 so kind of announcement of what device he is currently using so that others can communicate to the device he is currently using. 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 so kind of announcement of what device he is currently using so that others can communicate to the device he is currently using.
@ -58,9 +58,20 @@ So if we modify the library and clients as described above how do we keep it up
If we know the PersonaID, how is the library code table of PersonaID to ToxPk mapping updated? We want this to be mainly automatic without bothering the user. If we know the PersonaID, how is the library code table of PersonaID to ToxPk mapping updated? We want this to be mainly automatic without bothering the user.
We would need to modify the client code to save a copy if the mapping table, We would need to modify the client 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 Persona storage. The storage file could be json, possibly encrypted with ToxESave, or a files in a Personae directory saved in JSON, like we do with avatars, with the filename being the PersonaID.json.(Again, we want to maintain a structure that forsees this table being managed by a keyring manager like ```keepassxc```.) It would not be saved in a profile, as this table spans multiple profiles. so that when we start up a client, the mapping table is filled with last good values from the Persona storage. For the sake of this POC:
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 - the entry in the table is a string. We want to watch the DHT announcements , or changes in his status message, or a blob push mechanism like we do for avatars, for a blob of information that will update our PersonaID mapping to his active ToxID. 1. the storage file could be JSON, possibly encrypted with ToxESave, or
2. it could be a files in a Personae directory with files saved in JSON, like we do with avatars, with the filename being the PersonaID.json.
Again, we want to maintain a structure that forsees this table being managed by a keyring manager like ```keepassxc```. It would not be saved in a profile, as this table spans multiple profiles.
Let's say we have a friend, and we know his ToxPk. We initially derive his PersonaID by setting it to the friend's public key - the entry in the table is a string.
We will call a blob the information that will update our PersonaID mapping to his active ToxID that is pushed to clients. We want to watch the the blob flow for changes; so what is the blob flow of information:
1. If a blob is small we can base64 encode it and stick it in his status message,
2. We can do a blob push mechanism like we do for avatars, and push a blob into a file in a Personae directory, saved as the PersonaID.json as a filename.
3. We might push it as a DHT announcement.
Some clients may let the user decide whether of not to accept a blob update when it arrives. Some clients may let the user decide whether of not to accept a blob update when it arrives.
@ -70,30 +81,36 @@ So what is the blob of information that is pushed??
It has these characteristics: It has these characteristics:
1) It has 3 things - a name and a payload, and a NaCl signature. 1. It has 3 things - a name and a payload, and a NaCl signature.
2) It is small - 1K to 4K in size. 2. It is small - 1K to 4K in size.
3) As we will need a NaCl signing keypair in order to sign out payload, the name, (PersonaID) can be the public key of the signing keypair - 32 bytes or 64 hex chars. 3) As we will need a NaCl signing keypair in order to sign out payload, the name, (PersonaID) can be the public key of the signing keypair - 32 bytes or 64 hex chars.
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 by DHT announcements. If we push it like avatars, then it can be pushed once at start and subsequently on any changes. 4. If we push the blob info by DHT announcements,t 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. If we push it like avatars, then it can be pushed once at start and subsequently on any changes.
5) It might be encrypted so that the contents can not be seen in transit, but if the push mechanism is within Tox, it would be unnecessary. 5) It might be encrypted so that the contents can not be seen in transit, but if the push mechanism is within Tox, it would be unnecessary.
6) It must be signed so that it can be verified to be from the PersonaID, so we will assume every person generates a NaCl signing keypair and uses the same keypair for all of his devices. The public key of the signing keypair is the PersonaID. If a secret is used as the seed of the signing keypair, then the generated keypair is reproducible. 6) It must be signed so that it can be verified to be from the PersonaID, so we will assume every person generates a NaCl signing keypair and uses the same keypair for all of his devices. The public key of the signing keypair can be used as the PersonaID. If a secret is used as the seed of the signing keypair, then the generated keypair is reproducible.
Pushing the blob through DHT announcements would mean that the PersonaID to ToxPk mapping could be accessed even by people who were not yet your Friends - helping discovery. This may not be a good idea, depending on if it's encrypted. This set of ToxPks could be keys that open the encrypted blob. Anyone who already has a ToIPk 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 - like a multi-key Vera/True/dmwrapper container. But it might be enough for the blob to be signed, and that would be a good starting point - add encryption later if needed. Pushing the blob through DHT announcements would mean that the PersonaID to ToxPk mapping could be accessed even by people who were not yet your Friends - helping discovery. This may not be a good idea, depending on if it's encrypted. This set of ToxPks could be keys that open the encrypted blob. Anyone who already has a TokPk of the Persona could open the blob to get the update. Hence this encryption is different from most Tox encryption in that multiple keys can open it - like a multi-key Vera/True/dmwrapper container. But it might be enough for the blob to be signed, and that would be a good starting point - add encryption later if needed.
Let's say for now to focus this discussion, it is pushed like avatars amongst Friends, or as a status message. If we compress and base64 encode the blob, sign it and attach the signature in hex, and keep it under 1007 chars, then it can be set as your status message on all of your devices. The status message is visible to all of your friends so they all have a copy of the latest blob all of the time. So let's say for now to focus this discussion, we will ignore DHT announcements.
Then either: 1. It can be pushed as files like avatars amongst Friends, or
1. Set your status message to be the signing public key and push the blob by some means - DHT announcement, universal NGC chat group, some sendfile magic, or like avatars... 2. It can be pushed as a status message. If we compress and base64 encode the blob, sign it and attach the signature in hex, and keep it under 1007 chars, then it can be set as your status message on all of your devices. The status message is visible to all of your friends so they all have a copy of the latest blob all of the time.
2. compress and base64 encode the blob and append it to the public signing key and The same blob would be on each of your devices. Then either:
1. compress and base64 encode the blob and append it to the public signing key and
put that in the status message if less than 1007 bytes. put that in the status message if less than 1007 bytes.
The same blob could be on each of your devices, with a minor change when the active device changes. 2. Set your status message to be the signing public key and push the blob by some means like avatars.
In fact we could do #2 first to get things going, and then do #1, which is more changes to the code, although a lot of the code could be morphed from the avatar code.
### put that in the status message if less than 1007 bytes
With the signature and the public key, this should leave room for at least 12 devices in less than 1007 bytes, compressed and base64 encoded. With 1007 bytes with the signature and signing key, and nicknames of 12 bytes it will take about 16 devices With the signature and the public key, this should leave room for at least 12 devices in less than 1007 bytes, compressed and base64 encoded. With 1007 bytes with the signature and signing key, and nicknames of 12 bytes it will take about 16 devices
``` ```
@ -103,9 +120,13 @@ With the signature and the public key, this should leave room for at least 12 de
One problem with this is that only your Friends could verify the blob, which means One problem with this is that only your Friends could verify the blob, which means
users you have never invited will not be able to verify, unless they had the signing public key independently (perhaps using /sendfile). But perhaps that's good. users you have never invited will not be able to verify, unless they had the signing public key independently (perhaps using /sendfile). But perhaps that's good.
### It can be pushed as files like avatars amongst Friend
All the avatar code could be repurposed to also handle blobs.
Unknown for now is does the client have to send an add request to any new ToxPks found in the blob (new devices) to make them active if they have never seen the PK before? I assume yes. If so then it complicates things a little as the blob might need to contain ToxIDs. The code could accept either, distinguishing by length. Unknown for now is does the client have to send an add request to any new ToxPks found in the blob (new devices) to make them active if they have never seen the PK before? I assume yes. If so then it complicates things a little as the blob might need to contain ToxIDs. The code could accept either, distinguishing by length.
(This might be a signed way of associating nicknames with Pks if we use associated ordered dictionary mapping to a dictionary with nicknames.) (The blob might be a signed way of associating nicknames with Pks if we use associated ordered dictionary mapping to a dictionary with nicknames.)
The clients would manage this seemlessly to aggregate the 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 list of ToxPks (devices) with the first one being the active one. The clients would manage this seemlessly to aggregate the 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 list of ToxPks (devices) with the first one being the active one.