diff --git a/MultiDeviceAnnouncementsPOC.md b/MultiDeviceAnnouncementsPOC.md
index 8815aaa..ab7b6c1 100644
--- a/MultiDeviceAnnouncementsPOC.md
+++ b/MultiDeviceAnnouncementsPOC.md
@@ -26,37 +26,35 @@ lagging behind well-known centralized messenger systems. A few
 examples are Google Hangouts, Facebook Messenger, and Skype. Every one
 of these syncs messages to every device which connects to their
 network. If you need an address, number, or entire friend list it’s a
-simple login away. [[ToxMultiDevice]]
+simple login away - because they're centralized. 
 
-Not the goal of this project but an important benefit, Multi-Device
-support would solve some of the issues sharing a ToxID: it would allow
-the clients to connect with mobile devices (NFC, QR codes, other) and
-be available anywhere.
+Multi-Device support would solve some of the issues sharing a ToxID:
+it would allow the clients to connect with mobile devices (NFC, QR
+codes, other) and be available anywhere.
 
 ## First Steps
 
 The idea is to firstly define a PersonaID, much like a ToxPk that
 stays permanent across his devices, and maps the Person to the active ToxPk.
+So we distinguish between a Person, and a Friend who is one ToxID in a Person.
 
 So the first step is to extend all library code and all clients to
-work with PersonaIDs as well as ToxPks. The PersonaIDs would be client
-facing, and the ToxPk code would be for internal access. A simple
-implementation would be duplicating all code calls that deals with
-ToxPks to have a layer of calls on top that take the PersonaID and
-consult a table that contains the active ToxPk, and then calls the
-ToxPk function.
+work with PersonaIDs as well as ToxPks. The PersonaIDs would be client facing, a
+nd the ToxPk code would be for internal access. A simple implementation
+would be duplicating all code calls that deals with ToxPks to have a
+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, let's say that the table is initially
 populated with all the existing ToxPks by deriving a default PersonaID
 ToxID by a simple method: the default table contains a PersonaID that
-is the ToxPk (identity table).
+maps to the first the ToxPk of the Person that it sees (identity table).
 
 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 will
 move to showing the PersonaID not the ToxPk as the primary client-facing ID,
 and extend the clients with the ability to see the table of Personae ->
-ToxPks (but maybe not change the entries), and the active ToxPk for
-each PersonaID.
+ToxPks (but maybe not change them), and the active ToxPk for each PersonaID.
 
 More concretely, the PersonaID mapping table would be like a dictionary
 with 2 (or more) types of entries; before the arrival of a blob update,
@@ -71,12 +69,14 @@ with no breakage. After the arrival of a blob to update the table,
 the PersonaID is an ordered dictionary mapping to a list of device PKs:
 ```
 {"Pk1": "Pe1",
- "Pe1": ["Pe1k1", "Pe1k2", ...],
+ "Pe1": ["Pe1pk1", "Pe1pk2", ...],
  "Pk2": "Pk2",
  ...}
 ```
 or better still, associated ordered dictionary mapping to a dictionary with
-```devices``` entry with a dictionary using nicknames:
+```devices``` entry with a dictionary using nicknames, (leaving room for other
+fields in the Person dictionary such as groups Persona keys).
+:
 ```
 {"Pk1": "Pe1",
  "Pe1": {"devices": {
@@ -90,7 +90,7 @@ or better still, associated ordered dictionary mapping to a dictionary with
 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,
+ * ```["Pe1pk1", "Pe1pk2", ...]``` 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