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

Update 'MultiDevice Announcements POC'

emdee 2022-10-06 20:25:15 +02:00
parent b7ceefddb3
commit 8ddcae4f07
1 changed files with 11 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

13
MultiDevice-Announcements-POC.md

@ -56,14 +56,23 @@ It has these characteristics:
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.
5) It is encrypted so that the contents can not be seen in transit.
5) It might be encrypted so that the contents can not be seen in transit.
6) It is encrypted so that it can be verified to be from the PersonaID.
6) It must be signed so that it can be verified to be from the PersonaID.
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.
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
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
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.