emdee/tox_profile
1
0
Fork 0
Code Issues Pull Requests 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
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