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:02:35 +02:00
parent a3d8d6c05d
commit eb28a511fa
1 changed files with 29 additions and 26 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

55
MultiDevice-Announcements-POC.md

@ -26,13 +26,23 @@ More concretely, the PersonaID mapping table would be like a dictionary with 2 (
```
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
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",
"Pe1": ["Pe1k1", "Pe1k2", ...],
"Pk2": "Pk2",
...}
```
or associated ordered dictionary mapping to a dictionary with nicknames
```
{"Pk1": "Pe1",
"Pe1": {"Device1Nick": "Pe1k1",
"Device2Nick": "Pe1k2", ...},
"Pk2": "Pk2",
...}
```
where
* ```Pk1``` is the PK of user1,
* ```Pe1``` is the PersonaID of user1, which could be the public signing key of user1.
@ -43,15 +53,15 @@ Richer formats for the table are obviously possible, but we want to maintain a s
## MultiDevice Announcements Push
So if we modify the library and clients as described in MultiDeviceAnnouncementsPOC
So if we modify the library and clients as described above
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 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 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 pPersona storage - not saved in a profile - as this table spans multiple profiles.
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.
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 , or changes in his status message for a blob of information that will update our PersonaID mapping to his active ToxID.
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.
Some clients may let the user decide whether of not to accept a blob update when it arrives.
@ -65,25 +75,20 @@ It has these characteristics:
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 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.
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.
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.
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.
5) It might be encrypted so that the contents can not be seen in transit.
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.
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.
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.
The easier thing to do is to 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.
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 - 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. 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 either:
Then either:
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...
@ -92,17 +97,15 @@ 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 blob itself could be as simple as a json or yaml ordered dictionary with the keys being the nickname associate with the PK, and the values the PK or the device.
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
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
```
1007-128-64-2/(32+6+12) = 16
```
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. 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.
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.
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.)