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

Update 'MultiDeviceAnnouncementsBlob'

emdee 2022-09-22 01:47:54 +02:00
parent bf06ed1245
commit 8756148bbd
1 changed files with 4 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
MultiDeviceAnnouncementsBlob.md

@ -1,8 +1,8 @@
Previous: [[MultiDeviceAnnouncementsPush]]
So what is the blob of information that is pushed by DHT annoucements.
So what is the blob of information that is pushed by DHT annoucements/
It has these charachteristics:
It has these characteristics:
1) It has 2 things - a name and a payload.
@ -20,7 +20,7 @@ So here is a best guess of how the encryption works. I'm not a crypto guy, so pl
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.
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?
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 ToxID.
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.