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 12:11:14 +02:00
parent eb28a511fa
commit e13df116e3
1 changed files with 7 additions and 18 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

23
MultiDevice-Announcements-POC.md

@ -24,8 +24,6 @@ More concretely, the PersonaID mapping table would be like a dictionary with 2 (
"Pk2": "Pk2", "Pk2": "Pk2",
...} ...}
``` ```
So we could get the whole network switched over to accomodating PersonaIDs with no breakage. After the arrival os a blob to update the table with the PersonaID and its associated ordered dictionary mapping to a list So we could get the whole network switched over to accomodating PersonaIDs with no breakage. After the arrival os a blob to update the table with the PersonaID and its associated ordered dictionary mapping to a list
``` ```
{"Pk1": "Pe1", {"Pk1": "Pe1",
@ -83,7 +81,6 @@ It has these characteristics:
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 is 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 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.
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. 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.
@ -97,7 +94,7 @@ 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. The same blob could be on each of your devices, with a minor change when the active device changes.
TWith 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
``` ```
1007-128-64-2/(32+6+12) = 16 1007-128-64-2/(32+6+12) = 16
``` ```
@ -107,31 +104,24 @@ users you have never invited will not be able to verify, unless they had the sig
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.) (This 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.
Or we could have the DHT announcements have a steady stream of this update information: the contents of the blob are sent 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 signing 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. Each client would watch the stream for blobs named the PersonaID that they are interested in, which they know from the public signing key being in the status message of the friends.
Or we could have the DHT announcements have a steady stream of this update information: the contents of the blob are sent 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. Each client would watch the stream for blobs named the PersonaID that they are interested in, which they know from the public signing key being in the status message of the friends.
Or you could push a blob as a file similar to how avatars work, if it got too big for a status message. All of the avatar code could be reused to be blob code, with the addition of the step of verifying the signature against the public signing key in the status message of one of the users/PK in the blob. Or you could push a blob as a file similar to how avatars work, if it got too big for a status message. All of the avatar code could be reused to be blob code, with the addition of the step of verifying the signature against the public signing key in the status message of one of the users/PK in the blob.
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, or simply put the signing key and a a blob.gz.base64 in the status message. The clients lets a user push a blob whenever he wants - like when he changes devices.
## MultiDevice Profiles ## MultiDevice Profiles
In order for MultiDevice to work, we need to bootstrap a new devices from an 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 existing profile. 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 would push a new blob with the new device's PK, signed by the signing keypair which is independent of profiles.
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 edit the TCP_RELAYS section of the profile if desired. See <https://git.plastiras.org/emdee/tox_profile> The profile rekey utility could also do other things at the same time, like edit the TCP_RELAYS section of the profile if desired. See <https://git.plastiras.org/emdee/tox_profile>
The table of Persona to list-of-PKs would *not* be saved in the profile, as it refers to multiple ToxPKs, and should be easily managed by a keymanager. It's just a json dictionary for each Persona, plus a signing key and a signature. We could have a subdirectory of Personae, with each blob stored in a filename with the PersonaID (signing public key) as the filename.json. The blob is a json dictionary for each Persona, plus a signing key signature. We could have a subdirectory of Personae, with each blob stored in a filename with the PersonaID (signing public key) as the filename.json and handle updates the way we do avatars. Or if we pushed to the status message, clients could watch status message changes easily using the status_message callback.
Clients could implement with status message changes easily using the status_message callback.
## MultiDevice Groups ## MultiDevice Groups
@ -158,4 +148,3 @@ These are not simply the keypair of the Persona that is the new profile - how ar
There is Pythons cript to parse profiles that could be modified to rekey them at: There is Pythons cript to parse profiles that could be modified to rekey them at:
https://git.plastiras.org/emdee/tox_profile https://git.plastiras.org/emdee/tox_profile