Iran

emdee 2022-10-12 18:08:39 +00:00
parent 96bd1ab39b
commit d3c6249463
6 changed files with 73 additions and 39 deletions

@ -7,4 +7,4 @@ As the network is now, the number of nodes is very small, and all well known.
So Tox is vulnerable to being completely taken down by blocking a So Tox is vulnerable to being completely taken down by blocking a
small number of nodes. small number of nodes.
See: [[ToxAndTorInChina]] See: [[ToxAndTorInChinaAndIran]]

@ -19,6 +19,22 @@ using so that others can communicate to the device he is currently using.
The POC ignores the problem of history sync that this creates. The POC ignores the problem of history sync that this creates.
Others can address that later perhaps with tools like rsync. Others can address that later perhaps with tools like rsync.
## Background
When it comes to multi-device support, at the present time we are
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 its a
simple login away. [[ToxMultiDevice]]
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.
## 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.
@ -182,6 +198,8 @@ under 1007 chars, then it can be set as your status message on all of
your devices. The status message is visible to all of your friends so your devices. The status message is visible to all of your friends so
they all have a copy of the latest blob all of the time. they all have a copy of the latest blob all of the time.
3. If the blog.gz is less than 1000 chars, could it fit in a QR code?
In fact we could do #2 first to get things going, and then do #1, In fact we could do #2 first to get things going, and then do #1,
which is more changes to the code, although a lot of the code could be which is more changes to the code, although a lot of the code could be
morphed from the avatar code. Or you could push a blob as a file if morphed from the avatar code. Or you could push a blob as a file if

@ -41,16 +41,19 @@ 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 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 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 ( 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 in fact if you do send such a packet to the TCP it send the BS node into an
into an [infinite loop for which it never [infinite loop for which it neverrecovers](https://github.com/TokTok/c-toxcore/issues/2332)).
recovers](https://github.com/TokTok/c-toxcore/issues/2332)). So we So we need a simple fix to the TCP_server code to at least look for a
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 special packet like this and be nice and send a simple nice reply like
the UDP case. Raised as the UDP case. Raised as https://github.com/TokTok/c-toxcore/issues/2331
https://github.com/TokTok/c-toxcore/issues/2331
We should not kid ourselves that we don't all live in China or Iran - 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 the planet is in a loc$down and I think we might quickly find out just
how much resiliance we need. how much resiliance we need. s/China/Iran/Syria/Russia/
* https://www.themoscowtimes.com/2021/12/07/why-the-kremlin-blocking-tor-is-a-big-deal-a75751
* https://www.wired.com/story/russia-block-tor-censorship/
* https://www.eff.org/deeplinks/2011/05/syrian-man-middle-against-facebook
Up: [[DDosSmallNumberOfBSNodes]] Up: [[DDosSmallNumberOfBSNodes]]

@ -53,6 +53,9 @@ Features:
Centralized systems make it easy to MITM the E2E crypto, so unless they Centralized systems make it easy to MITM the E2E crypto, so unless they
are open source, they can't be trustworthy. are open source, they can't be trustworthy.
It is *much* harder to Tox over Tor than to block services like
WhatsApp which relay on centralized servers.
### WhatsApp ### WhatsApp
* https://www.sott.net/article/472864-Telegram-CEO-issues-warning-about-WhatsApp-security * https://www.sott.net/article/472864-Telegram-CEO-issues-warning-about-WhatsApp-security

@ -32,7 +32,6 @@ ToxIDs are difficult to share without having an existing textual
communication connection (anything you can copy from or paste communication connection (anything you can copy from or paste
to). Sharing ToxIDs in other ways is problematic. to). Sharing ToxIDs in other ways is problematic.
When it comes to multi-device support, at the present time we are When it comes to multi-device support, at the present time we are
lagging behind well-known centralized messenger systems. A few 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
@ -40,25 +39,27 @@ of these syncs messages to every device which connects to their
network. If you need an address, number, or entire friend list its a network. If you need an address, number, or entire friend list its a
simple login away. simple login away.
Not the goal of this project but an important benefit, Multi-Device
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. 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.
## Prerequisites ## Prerequisites
### Data Syncing (Friends and Messages): ### Data Syncing (Friends and Messages):
Devices may go online and offline. Its required that an online device be able to keep other devices in the “device group” in sync, Updating both friends and messages.[a][^1][b][^2] Devices may go online and offline. Its required that an online device be able to keep other devices in the “device group” in sync, Updating both friends and messages.(a)[^1](b)[^2]
### Contact Syncing ### Contact Syncing
Contacts (called friends in the Toxcore API) are synced across all Contacts (called friends in the Toxcore API) are synced across all
devices using a transactional method. As a pair the devices decide devices using a transactional method. As a pair the devices decide
which will have the primary role, and which will take which will have the primary role, and which will take secondary.
secondary. Throughout the entire syncing process, the primary device hroughout the entire syncing process, the primary device will send
will send its data, followed by a “done” packet. The secondary will its data, followed by a “done” packet. The secondary will then send
then send its data, followed by its own “done” packet. The primary its data, followed by its own “done” packet. The primary device will
device will then send a “commit” packet, and will then commit the data then send a “commit” packet, and will then commit the data from
from temporary storage, into active use. Once receiving the “commit” temporary storage, into active use. Once receiving the “commit”
packet, the secondary device will do the same. packet, the secondary device will do the same.
Either Client can send an Error packet at either time, which will then Either Client can send an Error packet at either time, which will then
@ -108,8 +109,15 @@ Security and safety is the primary concern, however this needs to be tempered wi
### Device IDs ### Device IDs
Device IDs need to be unique and never changing. On each connect, each client should query each friend they connect to, to verify if they support multi-device AND are in a group. This can be done by asking for the deviceID at ```__device0```. If there is a device at that address; then enumerate for each other device. Device IDs need to be unique and never changing. On each connect, each
Devices will be found by the string_to_id service using the protected `__device[0-9]+` group. (Toxcore must protect strings that start with two underscores such as “__[string]”, and not allow a client to use them in the string_to_id API.) client should query each friend they connect to, to verify if they
support multi-device AND are in a group. This can be done by asking
for the deviceID at ```__device0```. If there is a device at that
address; then enumerate for each other device. Devices will be found
by the string_to_id service using the protected `__device[0-9]+`
group. (Toxcore must protect strings that start with two underscores
such as “__[string]”, and not allow a client to use them in the
string_to_id API.)
Starting with ```__device0```, the client will attempt to resolve the Starting with ```__device0```, the client will attempt to resolve the
@ -153,7 +161,10 @@ friend/contact list, and the selected amount of history text history
to the new device. to the new device.
A max limit of devices will need to be chosen later to limit worst case usage of enumerating devices. (Additional protocol requirements will be detailed later, i.a. security limitations, verifiable, master device, slave device, deauthed devices.) A max limit of devices will need to be chosen later to limit worst
case usage of enumerating devices. (Additional protocol requirements
will be detailed later, i.a. security limitations, verifiable, master
device, slave device, deauthed devices.)
## Message sending ## Message sending
@ -170,8 +181,8 @@ received the message, and may stop. This will protect the sender from
having to maintain a list of who needs what message, and leave the having to maintain a list of who needs what message, and leave the
additional data syncing up to the receiving client. additional data syncing up to the receiving client.
It is considered the job of the receiving client to keep all the other
It is considered the job of the receiving client to keep all the other devices in sync with the rest of the group. devices in sync with the rest of the group.
### Alternatives Considered ### Alternatives Considered
@ -195,7 +206,7 @@ Effective and secure history syncing across devices.
How to add a user to your contact list How to add a user to your contact list
* By Primary ToxID[f][^6][g][^7] * By Primary ToxID(f)[^6](g)[^7]
* By any deviceID * By any deviceID
* Something else? * Something else?
@ -253,8 +264,6 @@ Conversations that need to be added to the spec:
``` ```
### Feature Requests: ### Feature Requests:
(Requested publicly, no suggestions have been reviewed or accepted yet.) (Requested publicly, no suggestions have been reviewed or accepted yet.)
@ -266,30 +275,30 @@ Conversations that need to be added to the spec:
## Footnotes ## Footnotes
* [a][^1] Does this design document define a way in which friends (and perhaps groups) are to be synced? And how would friend/group syncing work across multi-devices that don't have a common time base? * (a)[^1] Does this design document define a way in which friends (and perhaps groups) are to be synced? And how would friend/group syncing work across multi-devices that don't have a common time base?
* [b][^2] I haven't fully decided on the final spec for this question. * (b)[^2] I haven't fully decided on the final spec for this question.
Currently my plan is to retain information about changes as a numerical delta, and use the largest delta. But as I haven't started on this section, really I have no idea. Currently my plan is to retain information about changes as a numerical delta, and use the largest delta. But as I haven't started on this section, really I have no idea.
* [c][^3] What about in the case of an A/V call? Does that get broadcast to call connected clients or only the last 3? A tox client running on a mobile device that had not sent a user-generated message missing a call would be bad. * (c)[^3] What about in the case of an A/V call? Does that get broadcast to call connected clients or only the last 3? A tox client running on a mobile device that had not sent a user-generated message missing a call would be bad.
* [d][^4] I'm likely to drop that idea in total. * (d)[^4] I'm likely to drop that idea in total.
Currently toxcore sends everything to all devices. Currently toxcore sends everything to all devices.
* [e][^5] With other services such as Discord, when a call comes in depending on what is on, I could have two PCs, a laptop and cellphone all ring, but whatever device I answer on obviously gets the call. * (e)[^5] With other services such as Discord, when a call comes in depending on what is on, I could have two PCs, a laptop and cellphone all ring, but whatever device I answer on obviously gets the call.
* [f][^6] how is primary toxID different from any other ID? which device is the primary one? as far as I understood they are all equal. * (f)[^6] how is primary toxID different from any other ID? which device is the primary one? as far as I understood they are all equal.
* [g][^7] I'm not sure there's going to be anything like a primary ID in the final source. When discussing it, the idea of a master device came up as a security tool. But the longer I consider it, the less I think it'll help at all * (g)[^7] I'm not sure there's going to be anything like a primary ID in the final source. When discussing it, the idea of a master device came up as a security tool. But the longer I consider it, the less I think it'll help at all
* [h][^8] Does it make sense to think about sending the file to both * (h)[^8] Does it make sense to think about sending the file to both
clients, if the user accepts on multiple devices? Especially for clients, if the user accepts on multiple devices? Especially for
bigger files or multiple recipients a P2P protocol (e.g. torrent) bigger files or multiple recipients a P2P protocol (e.g. torrent)
may be useful. may be useful.
* [i][^9] Yeah, I've given that a little thought. The current idea * (i)[^9] Yeah, I've given that a little thought. The current idea
floating around has been to implement something torrent like inside floating around has been to implement something torrent like inside
group chats. Maybe we could use that as well? As far as multiple group chats. Maybe we could use that as well? As far as multiple
devices, what I think is best is transfer the file to the first to devices, what I think is best is transfer the file to the first to
@ -297,7 +306,7 @@ Currently toxcore sends everything to all devices.
way the sender doesn't have to spend the extra data for the way the sender doesn't have to spend the extra data for the
receivers convenience. receivers convenience.
* [j][^10] I like that idea. Especially if one thinks about those users * (j)[^10] I like that idea. Especially if one thinks about those users
on a phone with limited traffic. You wouldn't want to use all your on a phone with limited traffic. You wouldn't want to use all your
available data just so others can sync. You could add a button on available data just so others can sync. You could add a button on
top of lets say a picture saying "sync with my other devices" to top of lets say a picture saying "sync with my other devices" to
@ -305,4 +314,5 @@ Currently toxcore sends everything to all devices.
just sending it once should be a lot easier. I'd consider media sync just sending it once should be a lot easier. I'd consider media sync
between my devices as a nice-to-have. between my devices as a nice-to-have.
* [k][^11] Could it be a good idea to allow sync incomplete downloaded files from device A to device B and then start downloading from device B * (k)[^11] Could it be a good idea to allow sync incomplete downloaded
files from device A to device B and then start downloading from device B

@ -23,7 +23,7 @@ If you are not running over Tor and are on a stable connection, try it.
Every BSnode operator who wants to help the network be resilient in Every BSnode operator who wants to help the network be resilient in
places like Iran should run a Tor server that provides the node as an places like Iran should run a Tor server that provides the node as an
onionV3 service; see [[ToxAndTorInChina]]. onionV3 service; see [[ToxAndTorInChinaAndIran]].
If you run a bootstrap node, you can run a Tor Ononv3 gateway to the If you run a bootstrap node, you can run a Tor Ononv3 gateway to the
node by simply adding the following lines to your ```torrc``` node by simply adding the following lines to your ```torrc```