emdee/tox_profile
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Update 'MultiDevice Announcements POC'

emdee 2022-10-09 14:55:09 +02:00
parent bf7931f4c9
commit 5d9a9e25a9
1 changed files with 15 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

29
MultiDevice-Announcements-POC.md

@ -2,36 +2,39 @@ 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 announcement of what device he is currently using so that others can communicate to the device he is using.
This is based on the premise that solving the usage of Tox with multiple devices
is an urgent problem, as anyone with mobiles runs into it, and all the competion software deals with it.
** Woke Warning: gender specific, non-android friendly gammar and pronouns are used. **
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 so kind of announcement of what device he is currently using so that others can communicate to the device he is currently using.
The POC ignores for now the problem of history sync that this creates. We can address that later perhaps with tools like rsync.
The proposal assumes that there will be a lag time between him pushing an annoucement and others getting it and being able to find him.
The POC assumes he pushes on a regular basis and we choose hourly for the moment, if the network can stand it. We assume he pushes only when he is online.
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.
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 ToxPk code will be internal. A simple step of duplicating all code calls 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.
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, let's say that the table is initially populated with all the existing known ToxPks by deriving a default PersonaID from a ToxID by a simple method: the default table contains a PersonaID that is the ToxPk (identity table).
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->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 the primary data, 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 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.
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)
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 (assuming 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 to a list
So we could get the whole network switched over to accomodating PersonaIDs 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", ...],
"Pk2": "Pk2",
...}
```
or associated ordered dictionary mapping to a dictionary with nicknames
or better stil, associated ordered dictionary mapping to a dictionary with nicknames
```
{"Pk1": "Pe1",
"Pe1": {"Device1Nick": "Pe1k1",
@ -40,8 +43,7 @@ or associated ordered dictionary mapping to a dictionary with nicknames
...}
```
where
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,
@ -51,8 +53,7 @@ Richer formats for the table are obviously possible, but we want to maintain a s
## MultiDevice Announcements Push
So if we modify the library and clients as described above
how do we keep it up to date when a friend changes his devices?
So if we modify the library and clients as described above how do we keep it up to date when a friend changes his devices?
If we know the PersonaID, how is the library code table of PersonaID to ToxPk mapping updated? We want this to be mainly automatic without bothering the user.