Update 'MultiDevice Announcements POC'

MultiDevice-Announcements-POC.md

@@ -70,7 +70,9 @@ Let's say we have a friend, and we know his ToxPk. We initially derive his Perso
 
 We will call a blob the information that will update our PersonaID mapping to his active ToxID that is pushed to clients.  We want to watch the the blob flow for changes; so what is the blob flow of information:
 1. If a blob is small we can base64 encode it and stick it in his status message,
-2. We can do a blob push mechanism like we do for avatars, and push a blob into a file in a Personae directory, saved as the PersonaID.json as a filename.
+
+2. We can do a blob push mechanism like we do for avatars, and push a blob into a file in a subdirectory called ```Personae```, with each blob stored in a filename with the PersonaID (signing public key) as the filename.json and handle updates the way we do avatars.
+
 3. We might push it as a DHT announcement.
 
 Some clients may let the user decide whether of not to accept a blob update when it arrives.
@@ -93,22 +95,20 @@ It has these characteristics:
 
 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 can be used as the PersonaID. If a secret is used as the seed of the signing keypair, then the generated keypair is reproducible.
 
-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 TokPk of the Persona could open the blob to get the update. Hence 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.
+Each client would watch the stream or DHT announcements for blobs named the PersonaID that they are interested in, which they know from the public signing key being in the status message of the friends. 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 TokPk of the Persona could open the blob to get the update. Hence 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.
+
+The public signing key could be put into the status message field of each Person, and if each user put the same signature public key as the status message on each of his devices, then that signing 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.
 
 So let's say for now to focus this discussion, we will ignore DHT announcements.
 
-1. It can be pushed as files like avatars amongst Friends, or
+1. Set your status message to be the signing public key and push the blob by some means like avatars to Friends, or
 
-2. It can be pushed 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.
+2. It can be pushed 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. 
 
-The same blob would be on each of your devices. Then either:
+In fact we could do #2 first to get things going, and then do #1, which is more changes to the code, although a lot of the code could be morphed from the avatar code. Or you could push a blob as a file, if it got too big for a status message. 
 
-1. compress and base64 encode the blob and append it to the public signing key and
-put that in the status message if less than 1007 bytes. 
+The same blob would be on each of your devices.
 
-2. Set your status message to be the signing public key and push the blob by some means like avatars.
-
-In fact we could do #2 first to get things going, and then do #1, which is more changes to the code, although a lot of the code could be morphed from the avatar code.
 
 ### put that in the status message if less than 1007 bytes
 
@@ -120,9 +120,12 @@ With the signature and the public key, this should leave room for at least 12 de
 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, unless they had the signing public key independently (perhaps using /sendfile). But perhaps that's good.
 
+If we pushed to the status message, clients could watch status message changes easily using the status_message callback.
+
 ### It can be pushed as files like avatars amongst Friend
 
-All the avatar code could be repurposed to also handle blobs.
+All the avatar code could be repurposed to also handle blobs, with the signing public key put into the Person's status message. 
+
 
 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.
 
@@ -130,11 +133,7 @@ Unknown for now is does the client have to send an add request to any new ToxPks
 
 The clients would manage this seemlessly to aggregate the 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 list of ToxPks (devices) with the first one being the active one.
 
-Or we could have the DHT announcements have a steady stream of this update information: the contents of the blob are sent  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 signing 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. Each client would watch the stream for blobs named the PersonaID that they are interested in, which they know from the public signing key being in the status message of the friends.
-
-Or you could push a blob as a file similar to how avatars work, if it got too big for a status message.   All of the avatar code could be reused to be blob code, with the addition of the step of verifying the signature against the public signing key in the status message of one of the users/PK in the blob.
-
-The clients lets a user push a blob whenever he wants - like when he changes devices. 
+The clients let a user push a blob whenever he wants - like when he changes devices. 
 
 ## MultiDevice Profiles
 
@@ -143,7 +142,6 @@ existing profile. If you just copy a profile from one device to the next it will
 
 The profile rekey utility could also do other things at the same time, like edit the TCP_RELAYS section of the profile if desired. See <https://git.plastiras.org/emdee/tox_profile>
 
-The blob is a json dictionary for each Persona, plus a signing key signature. We could have a subdirectory of Personae, with each blob stored in a filename with the PersonaID (signing public key) as the filename.json and handle updates the way we do avatars. Or if we pushed to the status message, clients could watch status message changes easily using the status_message callback.
 
 ## MultiDevice Groups
 
@@ -168,5 +166,5 @@ it seems also that self's keypair are saved to the group:
 
 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 Pythons cript to parse profiles that could be modified to rekey them at:
+There is Python script to parse profiles that could be modified to rekey them at:
 https://git.plastiras.org/emdee/tox_profile