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 07:09:27 +02:00
parent 8ddcae4f07
commit 8c4697e865
1 changed files with 5 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
MultiDevice-Announcements-POC.md

@ -31,13 +31,12 @@ If we know the PersonaID, how is the library code table of PersonaID to ToxID ma
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.
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.
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.
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.
Some clients may let the user decide whether of not to accept a blob update when it arrives.
@ -60,6 +59,8 @@ 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.
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.