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

Future Directions

emdee 2022-10-10 21:26:47 +00:00
parent 61c11b11ee
commit 52d1f5ff91
3 changed files with 86 additions and 22 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

59
MultiDeviceAnnouncementsPOC.md

@ -59,11 +59,14 @@ the PersonaID is an ordered dictionary mapping to a list of device PKs:
"Pk2": "Pk2",
...}
```
or better still, associated ordered dictionary mapping to a dictionary with nicknames
or better still, associated ordered dictionary mapping to a dictionary with
```devices``` entry with a dictionary using nicknames:
```
{"Pk1": "Pe1",
"Pe1": {"Device1Nick": "Pe1k1",
"Device2Nick": "Pe1k2", ...},
"Pe1": {"devices": {
"Device1Nick": "Pe1k1",
"Device2Nick": "Pe1k2", ...}
},
"Pk2": "Pk2",
...}
```
@ -80,28 +83,36 @@ keyring manager like ```keepassxc```.
## 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? 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.
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.
We would need to modify the client code to save a copy if the mapping table,
so that when we start up a client, the mapping table is filled with last good values from the Persona storage. For the sake of this POC:
We would need to modify the client code to save a copy if the mapping
table, so that when we start up a client, the mapping table is filled
with last good values from the Persona storage. For the sake of this POC:
1. the storage file could be JSON, possibly encrypted with ToxESave, or
2. it could be a files in a Personae directory with files saved in JSON, like we do with avatars, with the filename being the ```PersonaID.json```.
2. it could be a files in a ```Personae``` directory with files saved
in JSON or YAML, like we do with avatars, with the filename being named
```PersonaID.json```.
Again, we want to maintain a structure that foresees this table being
managed by a keyring manager like ```keepassxc```. It would not be
saved in a profile, as this table spans multiple profiles.
Let's say we have a friend, and we know his ToxPk. We initially derive his PersonaID by setting it to the friend's public key - the entry in the table is a string.
Let's say we have a friend, and we know his ToxPk. We initially derive
his PersonaID by setting it to the friend's public key - the entry in
the table is a string.
We will call a blob the information that will update our PersonaID
We will call "a blob" the information that will update our PersonaID
mapping to his active ToxID that is pushed to clients. We want to
watch the the blob flow for changes; so what is the blob flow of information:
watch the blob flow for changes. So what is the blob flow of information?
1. If a blob is small we can base64 encode it and stick it in his status message,
2. We can do a blob push mechanism like we do for avatars, and push a blob into a file in a sub-directory called ```Personae```, with each blob stored in a filename with the PersonaID (signing public key) as the filename.json and handle updates the way we do avatars.
2. We can do a blob push mechanism like we do for avatars, and push a blob into a file in a sub-directory called ```Personae```, and handle updates the way we do avatars.
3. We might push it as a DHT announcement.
@ -110,7 +121,7 @@ update when it arrives.
## MultiDevice Announcements Blob
So what is the blob of information that is pushed??
So what is the blob of information that is pushed?
It has these characteristics:
@ -264,6 +275,13 @@ which case, the notion of the blob needs extending from just the
ToxPks and nicknames of each of the devices, to include the secret
keys of that Persona for each NGC group the Persona belongs to.
In other words if I have 3 profiles with 3 nicks and 3 keypairs, and the
first profile had a GROUP section where I have a group_nick, could I copy
the GROUP section entirely into the other 2 profiles, and then be a member
of the NGC group known as group_nick when I used those profiles? If so,
the Persona should have dictionarys for each group, with
```group_nick```, ```self_public_key``` and ```self_secret_key``` in each.
( Aside: I don't like the idea of keeping secret keys in profiles; they
should be managed by a keymanager. In a corporate setting, this will
be a requirement. )
@ -271,18 +289,28 @@ be a requirement.)
There is a Python script to parse profiles that could be modified to rekey
group self entries at: https://git.plastiras.org/emdee/tox_profile
## Future Directions
If Personae identify which are your devices, it opens the possibility that
clients could treat incoming messages from one of your devices differently.
Instead of simply displaying the message in a window, the client might
examine the message to see if it is a command. So clients could build in,
for example a filebot, that responds to a set of commands if it's coming
from one of your devices. Automated file transfer, DoorSpy, history sync;
the possibilities are endless.
## Summary
The changes to the core are not large:
1. Change the status message callback to look for public signing keys
2. Change the status message callback to look for public signing keys
as a first cut, and then extend the avatar file transfer mechanism
2. Change the status message callback to look for blobs as a first
implementation, and then later extend the avatar file transfer mechanism
to transfer blobs
3. Use the public signing keys to verify the blobs
3. Use the public signing keys to verify the blobs. This a NaCl call.
4. Store the blobs in a subdirectory, with their signature.
5. Use the blobs to populate the table, and designate one entry as active.
6. Wrap all the calls that use a PK to look in the table for the active PK.
7. Update the tables, if files are deleted from the ```Persona``` directory.
All existing unmodified users would continue to work: no testnet required.
@ -294,3 +322,4 @@ the changes to the clients are not large:
4. Add the ability to push a new blob to Friends, or perhaps selected Friends.
Also we would want the Python script to keep profiles within a Persona in sync.
We need to resolve the questions about having the same groups Personae.

42
ToxAndTorInChina.md

@ -11,14 +11,46 @@ Did the reports of blocking in China include blocking over Tor? Tor itself has i
So the best way to handle this may be to improve the documentation in Tox of how to use Tor, and how to configure Tor to use pluggable transports. They are the only things that work in e.g. Egypt or Iran.
I also think the other way of getting a lot of resilience "cheaply" is to encourage bootstrap node operators to also run a Tor node to serve the BS over Onionv3. This is the only way I can see dealing with the fact that Tox is a network of so few bootstrap nodes. If the Tox codebase was improved to work with Onionv3 BS nodes, and OnionV3 relays, it would be much more resilient.
I also think the other way of getting a lot of resilience "cheaply" is
to encourage bootstrap node operators to also run a Tor node to serve
the BS over Onionv3. This is the only way I can see dealing with the
fact that Tox is a network of so few bootstrap nodes. If the Tox
codebase was improved to work with Onionv3 BS nodes, and OnionV3
relays, it would be much more resilient.
There is a way of configuring Tor to uniquely assign a life-of-the-tor-instance IPv4 address from a predefined private range (VirtualAddrNetwork) to each onion address it sees: AutomapHostsOnResolve. So Tox could use OnionV3 BS nodes in a properly configured Tor with just some properly configured BS hosts lists (if enough BS nodes provided OnionV3 addresses), Then we could leave the heavy lifting of the cat-and-mouse games of pluggable transports etc. to Tor (or i2p), and not try to chase them ourselves.
There is a way of configuring Tor to uniquely assign a
life-of-the-tor-instance IPv4 address from a predefined private range
(VirtualAddrNetwork) to each onion address it sees:
AutomapHostsOnResolve. So Tox could use OnionV3 BS nodes in a
properly configured Tor with just some properly configured BS hosts
lists (if enough BS nodes provided OnionV3 addresses), Then we could
leave the heavy lifting of the cat-and-mouse games of pluggable
transports etc. to Tor (or i2p), and not try to chase them ourselves.
To even try out this approach I think you need to fix the [open-for-five-years-and-counting](https://github.com/TokTok/c-toxcore/issues/469) issue of not resolving the IP address of the targets when you are in front of a SOCKS5 proxy (Tor). But maybe there's another way: you could contact each of the OnionV3 BS nodes outside of Tox and get the IPv4 address of each Onion BS node, for- life-of-the-tor-instance which is usually long enough, in Python using the Tor stem library. Then you could use these IPv4 addresses as your BS nodes, as long as your client didn't suffer from the dreaded deranged-hard-coded-bs syndrome.
To even try out this approach I think you need to fix the
[open-for-five-years-and-counting](https://github.com/TokTok/c-toxcore/issues/469)
issue of not resolving the IP address of the targets when you are in
front of a SOCKS5 proxy (Tor). But maybe there's another way: you
could contact each of the OnionV3 BS nodes outside of Tox and get the
IPv4 address of each Onion BS node, for- life-of-the-tor-instance
which is usually long enough, in Python using the Tor stem library.
Then you could use these IPv4 addresses as your BS nodes, as long as
your client didn't suffer from the dreaded deranged-hard-coded-bs syndrome.
I've tried this but it's currently impossible to test as there is no equivalent to the ```other/fun/bootstrap_node_info.py``` script for TCP connections. For UDP you can send a packet of len 78 with the magic first bytes and get a version and MOTD reply. Not so for TCP ( in fact if you do send such a packet to the TCP it send the BS node into an [infinite loop for which it never recovers](https://github.com/TokTok/c-toxcore/issues/2332)). So we need a simple fix to the TCP_server code to at least look for a special packet like this and be nice and send a simple nice reply like the UDP case. Raised as https://github.com/TokTok/c-toxcore/issues/2331
I've tried this but it's currently impossible to test as there is no
equivalent to the ```other/fun/bootstrap_node_info.py``` script for
TCP connections. For UDP you can send a packet of len 78 with the
magic first bytes and get a version and MOTD reply. Not so for TCP (
in fact if you do send such a packet to the TCP it send the BS node
into an [infinite loop for which it never
recovers](https://github.com/TokTok/c-toxcore/issues/2332)). So we
need a simple fix to the TCP_server code to at least look for a
special packet like this and be nice and send a simple nice reply like
the UDP case. Raised as
https://github.com/TokTok/c-toxcore/issues/2331
We should not kid ourselves that we don't all live in China - wthe pllanet is in a loc$down and I think we might quickly find out just how much resiliance we need.
We should not kid ourselves that we don't all live in China or Iran -
the planet is in a loc$down and I think we might quickly find out just
how much resiliance we need.
Up: [[DDosSmallNumberOfBSNodes]]

3
ToxComparedWithOtherIm.md

@ -53,3 +53,6 @@ Features:
Centralized systems make it easy to MITM the E2E crypto, so unless they
are open source, they can't be trustworthy.
### WhatsApp
* https://www.sott.net/article/472864-Telegram-CEO-issues-warning-about-WhatsApp-security