diff --git a/MultiDevice-Announcements-POC.md b/MultiDevice-Announcements-POC.md
index cfd2a13..20744e1 100644
--- a/MultiDevice-Announcements-POC.md
+++ b/MultiDevice-Announcements-POC.md
@@ -2,7 +2,7 @@ Previous: [[Home]]
 
 ## We need to solve the usage of Tox with multiple devices.
 
-The idea here is to address one simple usecase: a person can have multiple devices and he wants one device to be "active" at any given time. So he pushes an annoucement of what device he is currently using so that others can communicate to the device he is using.
+The idea here is to address one simple usecase: a person can have multiple devices and he wants one device to be "active" at any given time. So he pushes an announcement of what device he is currently using so that others can communicate to the device he is using.
 
 The POC ignores for now the problem of history sync that this creates. We can address that later perhaps with tools like rsync.
 
@@ -12,14 +12,35 @@ The POC assumes he pushes on a regular basis and we choose hourly for the moment
 
 The idea is to firstly define a PersonaID, much like a ToxPk that stays permanent and maps the Person to the active ToxPk.
 
-So the first step is to change all library code and all clients to work with PersonaIDs as  well as  ToxPks. The PersonaIDs would be client facing, and the ToxID code will be internal. A simple step of duplicating all code that deals with ToxIDs to have a 1:1 layer of calls on top that take the PersonaID and consult a table that contains the active ToxPk, and then calls the ToxPk function.
+So the first step is to change all library code and all clients to work with PersonaIDs as  well as  ToxPks. The PersonaIDs would be client facing, and the ToxPk code will be internal. A simple step of duplicating all code that deals with ToxPks to have a 1:1 layer of calls on top that take the PersonaID and consult a table that contains the active ToxPk, and then calls the ToxPk function.
 
-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.
+For the sake of argument, let's say that the table is initially populated with from all the existing known ToxPks 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 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 can add this layer of PersonaID->ToxPk 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 in the clients the ability to see the table of Personae -> ToxPks (but maybe not change the entries), and the active ToxPk for each PersonaID.
 
-So we could get the whole network switched over to accomodating PersonaIDs with no breakage.
+More concretely, the PersonaID mapping table would be like a dictionary with 2 (or more) types of entries; before the arrival of a blob, the table is by default(in json)
+```
+{"Pk1": "Pk1",
+ "Pk2": "Pk2",
+ ...}
+ ```
+ 
 
+So we could get the whole network switched over to accomodating PersonaIDs with no breakage. After the arrival os a blob to update the table with the PersonaID and its associated ordered dictionary mapping 
+```
+{"Pk1": "Pe1",
+ "Pe1": ["Pe1k1", "Pe1k2", ...],
+ "Pk2": "Pk2",
+ ...}
+ ```
+ where
+ * ```Pk1``` is the PK of user1,
+ * ```Pe1``` is the PersonaID of user1, which could be the public signing key of user1.
+ * ```["Pe1k1", "Pe1k2", ...]``` are the PKs of each of the devices of user1,
+    delivered in a blob signed by ```Pe1``
+    
+Richer formats for the table are obviously possible, but we want to maintain a structure that forsees this table being managed by a keyring manager like ```keepassxc```.
+ 
 ## MultiDevice Announcements Push
 
 So if we modify the library and clients as described in MultiDeviceAnnouncementsPOC