Update 'MultiDevice Announcements POC'

MultiDevice-Announcements-POC.md

@@ -16,7 +16,7 @@ So the first step is to change all library code and all clients to work with Per
 
 For the sake of argument, lets say that the table is initially populated with from all the existing known ToxIDs by deriving a default PersonaID from a ToxID by a simple method. We'll adopt the simplest mechanism although we can do better: the default table contains a PersonaID that is the ToxPk.
 
-So we can add this layer of PersonaID->ToxID mapping to the library and all clients right away with no breakage. In time the clients move to showin the PersonaID not the ToxPk as primary, and add the ability to see (but maybe not change) the active ToxPk.
+So we can add this layer of PersonaID->ToxID mapping to the library and all clients right away with no breakage. In time the clients move to showing the PersonaID not the ToxPk as primary, and add the ability to see the table of Personae -> ToxPks (but maybe not change the entries), and the active ToxPk.
 
 So we could get the whole network switched over to accomodating PersonaIDs with no breakage.
 
@@ -80,6 +80,8 @@ 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.
 
+(This might be a signed way of associating nicknames with Pks.)
+
 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.
 
 
@@ -98,9 +100,11 @@ most complement the Tox profile with an ini file or similar.
 If you just copy a profile from one device to the next it will not work as
 you cannot have 2 profiles with the same keys online at the same time. We could have a simple utility that rekeys a profile and creates a new ToxID, so that we could copy a profile and rekey it. Then the new client running the rekeyed profile could send a DHT announcement updating to the new ToxID. The old keys would be added to the new profile's friends list.
 
-The profile rekey utility could also do other things at the same time, like empty the TCP_RELAYS section of the profile if desired. See <https://git.plastiras.org/emdee/tox_profile>
+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 table of Persona to list-of-PKs would *not* be saved in the profile, as it refers to multiple ToxPKs, and should be easily managed by a keymanager. It's just a json dictionary for each Persona, plus a signing key and a signature. Clients could deal with this easily using the status_message callback.
+The table of Persona to list-of-PKs would *not* be saved in the profile, as it refers to multiple ToxPKs, and should be easily managed by a keymanager. It's just a json dictionary for each Persona, plus a signing key and a 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.
+
+Clients could implement with status message changes easily using the status_message callback.
 
 ## MultiDevice Groups