emdee/tox_profile
2
3
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Updates

emdee 2022-10-18 08:50:31 +00:00
parent ea1adf92e7
commit 92e4abd89f
1 changed files with 17 additions and 17 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

34
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 examples are Google Hangouts, Facebook Messenger, and Skype. Every one
of these syncs messages to every device which connects to their 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 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 Multi-Device support would solve some of the issues sharing a ToxID:
support would solve some of the issues sharing a ToxID: it would allow it would allow the clients to connect with mobile devices (NFC, QR
the clients to connect with mobile devices (NFC, QR codes, other) and codes, other) and be available anywhere.
be available anywhere.
## First Steps ## First Steps
The idea is to firstly define a PersonaID, much like a ToxPk that 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. 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 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 work with PersonaIDs as well as ToxPks. The PersonaIDs would be client facing, a
facing, and the ToxPk code would be for internal access. A simple nd the ToxPk code would be for internal access. A simple implementation
implementation would be duplicating all code calls that deals with would be duplicating all code calls that deals with ToxPks to have a
ToxPks to have a layer of calls on top that take the PersonaID and layer of calls on top that take the PersonaID and consult a table that
consult a table that contains the active ToxPk, and then calls the contains the active ToxPk, and then calls the ToxPk function.
ToxPk function.
For the sake of argument, let's say that the table is initially For the sake of argument, let's say that the table is initially
populated with all the existing ToxPks by deriving a default PersonaID populated with all the existing ToxPks by deriving a default PersonaID
ToxID by a simple method: the default table contains a PersonaID that 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 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 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, 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 -> 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 ToxPks (but maybe not change them), and the active ToxPk for each PersonaID.
each PersonaID.
More concretely, the PersonaID mapping table would be like a dictionary 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, 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: the PersonaID is an ordered dictionary mapping to a list of device PKs:
``` ```
{"Pk1": "Pe1", {"Pk1": "Pe1",
"Pe1": ["Pe1k1", "Pe1k2", ...], "Pe1": ["Pe1pk1", "Pe1pk2", ...],
"Pk2": "Pk2", "Pk2": "Pk2",
...} ...}
``` ```
or better still, associated ordered dictionary mapping to a dictionary with 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", {"Pk1": "Pe1",
"Pe1": {"devices": { "Pe1": {"devices": {
@ -90,7 +90,7 @@ or better still, associated ordered dictionary mapping to a dictionary with
where: where:
* ```Pk1``` is the PK of user1, * ```Pk1``` is the PK of user1,
* ```Pe1``` is the PersonaID of user1, which could be the public signing key 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`` delivered in a blob signed by ```Pe1``
Richer formats for the table are obviously possible, but we want to Richer formats for the table are obviously possible, but we want to