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

Update 'MultiDevice Announcements POC'

emdee 2022-10-07 08:40:28 +02:00
parent 8c4697e865
commit d5911a0ed7
1 changed files with 19 additions and 19 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

38
MultiDevice-Announcements-POC.md

@ -10,14 +10,13 @@ The proposal assumes that there will be a lag time between him pushing an annouc
The POC assumes he pushes on a regular basis and we choose hourly for the moment, if the network can stand it. We assume he pushes only when he is online.
The idea is to firstly define a PersonaID, much like a ToxID that stays permanent and maps the Person to the active ToxID.
The idea is to firstly define a PersonaID, much like a ToxPk that stays permanent and maps the Person to the active ToxPk.
So the first step is to change all library code and all clients to work with PersonaIDs as well as ToxIDs. The PersonaIDs would be client facing, and the ToxID code will be internal. A simple step of duplicating all code that deals with ToxIDs to have a 1:1 layer of calls on top that take the PersonaID and consult a table that contains the active ToxID, and then calls the ToxID function.
So the first step is to change all library code and all clients to work with PersonaIDs as well as ToxPks. The PersonaIDs would be client facing, and the ToxID code will be internal. A simple step of duplicating all code that deals with ToxIDs to have a 1:1 layer of calls on top that take the PersonaID and consult a table that contains the active ToxPk, and then calls the ToxPk function.
For the sake of argument, lets say that the table is initially populated with from all the existing known ToxIDs by deriving a default PersonaID from a ToxID by a simple method. We'll adopt the simplest mechanism although we can do better: the default table contains a PersonaID that is the ToxID with a checksum of all zeros.
(we ignore for now the possibility of a real all zero checksum.)
For the sake of argument, lets say that the table is initially populated with from all the existing known ToxIDs by deriving a default PersonaID from a ToxID by a simple method. We'll adopt the simplest mechanism although we can do better: the default table contains a PersonaID that is the ToxPk.
So we can add this layer of PersonaID->ToxID mapping to the library and all clients right away with no breakage. In time the clients move to showin the PersonaID not the ToxID as primary, and add the ability to see (but maybe not change) the active ToxID.
So we can add this layer of PersonaID->ToxID mapping to the library and all clients right away with no breakage. In time the clients move to showin the PersonaID not the ToxPk as primary, and add the ability to see (but maybe not change) the active ToxPk.
So we could get the whole network switched over to accomodating PersonaIDs with no breakage.
@ -26,17 +25,18 @@ So we could get the whole network switched over to accomodating PersonaIDs with
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.
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 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.
so that when we start up a client, the mapping table is filled with last good values from the profile. This might not be saved in a profile - this table spans multiple profiles - one per device.
Lets say we have a friend, and we know his ToxID. 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 everyone 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 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 == ToxID could be automatically updated.
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.
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 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.
The clients lets a user push a blob whenever he wants - like when he changes devices. You could push a blog or have a message pushed to the universal group.
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.
Some clients may let the user decide whether of not to accept a blob update when it arrives.
@ -59,16 +59,16 @@ It has these characteristics:
6) It must be signed so that it can be verified to be from the PersonaID.
Pushing the blob through DHT announcements would mean that the PersonaID to ToxId mapping could be accessed even by people who were not yet your Friends - helping discovery, or maybe not, depending on if it's encrypted.
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.
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.
The blob is intended to be the mapping to an active ToxPk, and could be a mapping to a set of ToxIDs, the set of that Personas devices, with one marked active. 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.
Or it might be enough for the blob to be signed. If the blob had at attached
signature generated by the NaCl signing functions. This would mean that the owner
of the Persona would generate a NaCl signing keypair to sign the blob. Then the question is how to push th3 public NaCl signing key. Would this work:
1) Set your friend status message to be the signing public key
1) Set your status message to be the signing public key
2) Do the same with the same key on each of your devices.
One problem with this is that only your Friends could verify the blob, which means
@ -76,15 +76,15 @@ users you have never invited will not be able to verify. But perhaps that's good
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.
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 Groups
Previously, we described in [[MultiDeviceInitialization]] we simply copy a profile to a new devices and change the public/private keys as a starting point.
Previously, we described how we simply copy a profile to a new devices and change the public/private keys as a starting point.
But we are left with as special problem with NGC groups.
The code is assumed to have been modified to handle Personas and, at first glance, NGC groups become groups of Personas. Each member of the group is a Persona, and uses the table lookup to get the active ToxID.
The code is assumed to have been modified to handle Personas and, at first glance, NGC groups become groups of Personas. Each member of the group is a Persona, and uses the table lookup to get the active ToxPk.
But the group structure in the profile has a copy of the founder's shared_state.founder_public_key (group_pack.c#L293) So if the profile being copied onto a new device is the profile of the founder, then this key would need to be updated too.
@ -99,13 +99,14 @@ it seems also that self's keypair are saved to the group:
* self_public_key #L353
* self_secret_key #L354
Are these simply the keypair of the Persona that is the new profile? If so, then these keys have to be updated with the new keypair of the new profile.
These are not simply the keypair of the Persona that is the new profile - how are they created? These keys have to be updated with the new keypair of the new profile.
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
@ -115,4 +116,3 @@ 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>