Add an option to disable relaying onion traffic #441
Comments
|
You can disable UDP (which disables the DHT). Your client should provide an option for this. |
|
It is disabled in both of the mentioned clients. From my work network I could not even have any UDP traffic. It's filtered by the firewall. Still there is TCP traffic between my computer and the relay node I connect to (via TCP port 443). Even if all my contacts are offline. |
|
It's looking for your contacts, and making sure that the node where your friend will look for you, knows you're online. |
|
Why does it have to look for my contacts every second? I have only two contacts. It communicates with ten times more amount of data than when chatting. Let alone mobile devices that run a client like Antox which is also based on toxcore. They will drain the battery really fast just because of this (I think) unnecessary relay/lookup data that uses Wi-Fi or mobile internet (3G/4G) which means high power consumption. Not to mention the traffic it continuously causes when connected to a 3G/4G mobile internet network. It can consume a significant part of the data plan. Traffic should only be generated when there is communication and peer-to-peer connections should be preferred with UPnP techniques instead of relaying everything. Before Tox gets widespread this should be thought over again seriously. Tox should be decentralized as much as possible. Not interdependent that causes a lot of unnecessary extra traffic. |
|
|
Well, I'm not saying that all relaying or user announcing have to be disabled. I'm saying that there should be an option that I don't want to participate in forwarding this traffic, because it causes high data usage and it costs extra money when we're talking about data plans on mobile networks. |
|
We should certainly reduce data usage. We will be looking into that in due time (after we've established a basis upon which we can build, and which we can modify without the constant fear of things breaking in subtle ways). But, I don't think you are relaying traffic if you disable UDP. #440 could be related to this issue. |
|
also (but a different issue) is sending own avatar every time a friend comes online. they will be sending avatar byte constantly all the time |
|
@zoff99 clients should use tox_hash() to get a reproducible data hash for the avatar. Then send the avatar with that hash. Again, sane clients will check this against the hash they have already, and will cancel the file transfer if they already have that avatar. |
|
if 1 million devices send avatar hashes every 1 minute, thats still stupid and just a waste of bandwidth. this is not a code issue, but rather a specification issue. it says that sending avatar is required when a friend comes online. there should be room for a "can send avatar ...." or something. |
|
You're really gonna be discouraged when you learn that toxcore sends your
name and your status message to every friend every time you connect.
…On Jan 24, 2017 1:29 AM, "Zoff" ***@***.***> wrote:
if 1 million devices send avatar hashes every 1 minute, thats still stupid
and just a waste of bandwidth
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#441 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAO20Np3JWJDoidKB3frbdSxnvQyLalvks5rVcR5gaJpZM4Lk2Iy>
.
|
|
:-) |
|
Action here is: add an option to ignore all onion traffic. This option is for users who want to be in the DHT but don't want to participate in the onion. |
iphydf
changed the title
|
No. The onion can not be optional. |
|
Either it should be optional or Tox is gonna be yet another bloatware that causes high CPU usage on older computers, drains the battery of mobile devices and consumes a lot of data plan. I would be really sad about this. I don't think it's a good idea not to care about the resource consumption toxcore causes in all clients based on it. We'll end up with something like the so-called "modern web". Like the Facebook website which is the most bloated interface ever. However it could be different. They're just some main concepts that should be changed. This is an architerctural decision. There are users that can relay a lot of traffic, e.g. desktop computers with a 10Mbit/100Mbit internet connection. Call them supernodes. All desktop clients should have an option to relay the traffic or not and it should be enabled by default. It should have three states Enabled / Disabled / Auto. Auto should be the default. When it's active, Toxcore should do measurements and compute some statistics for itself of network delay, ping and throughput, and CPU usage (!). If the network performance is constantly low or CPU usage caused by Toxcore is high, it should give up the onion style routing for some hours or days. On mobile devices these should be disabled completely. Friend announcement should be asynchronous. So if I connect via a client that has relaying disabled, it announces me to one of the bootstrap nodes. The bootstrap nodes introduce me to the DHT network so the supernodes can announce me to other relay-disabled clients. When I open a chat window with someone toxcore should establish a P2P connection to the friend. UPnP must have a high priority for implementation. It's supported by millions of devices and P2P connections could spare most of the traffic for the relay nodes. Avatars and any meta information (like status messages) should not be sent unless there is any communication. Or there should be a logic like the avatar and the status message should be timestamped and be sent just once a friend comes online. So it should be a local hash table with timestamps paired with friend IDs. Timestamps represent the time a friend successfully received my avatar and stauts message. If the timestamp of the avatar doesn't represent a time later than my avatar was changed, nothing should be sent to that friend. Tox needs serious optimizations like above or it will be the same bloated messenger like all other cloud applications (like Facebook's Messenger) or java-based torrent clients. I don't want to see this happen. |
|
isn't the privacy created by the onion is the whole point of tox? |
|
@magwas I think that this privacy must have configurable levels to choose the tradeoff, how much you would like to sacrifice for privacy. For example, privacy for me means that my data are not stored unencrypted on corporate servers (like at Facebook, Google etc.). But I don't live in a police state so that I don't need to hide my IP address or the fact that I'm communicating directly with another IP address (P2P logic). I know that in a lot of situations onion is good. But in my case it's just an inconvenience and a waste of resources. This is why it should be optional. |
|
@palikacska There are things which do not work without people helping out each other. Onion is such a thing. |
|
there should be some consideration for mobile devices in tox soon. i just hope. @magwas if you should live in a such a state then you still need to conserve battery on your mobile device. with empty battery you have no communication at all. |
|
@magwas It's about the choice I can make to commit a tiny percentage of my resources or not. For me, relaying can be enabled by default when I'm on my desktop computer with a fast connection. On fast networks I would also leave it enabled. However, on slower networks, older computers and mobile devices it has more disadvantages than ever. Mobile networks still have high-latency characteristics in many countries, even in the modern part of the world. Let alone the data plans which I do not want to donate because it costs me extra money. Even if the phone batteries lasted for 30 days with one charge, it would be a very bad idea to relay traffic via mobile devices. This is why it should be changed. Relaying should be enabled by default in desktop clients and disabled by default in mobile clients. And of course there could be and Auto option with tradeoffs like Antox could detect if the device is charging and it's on a fast WiFi network, so it can turn it on automatically. I'm really sorry for the people who live in a police state, but I would rather sacrifice my desktop bandwidth to relay their traffic than my mobile bandwidth. But there are some cases where I don't want to sacrifice even my desktop bandwidth, for example when I connect my notebook to a mobile network with a data plan. |
SkyzohKey
added
enhancement
|
If you make it optional the network is harmed by leeches |
|
@optimumtact If you don't make it optional, the network will become bloated. If you don't make it optional, a lot of network traffic will be wasted by Tox users just because of the idealism of rerouting all connections that should not be rerouted in 99% of the cases. If you don't make it optional, each mobile user with data plan will waste several hundreds of dollars annually just to keep following this relaying idealism. So guess what, Tox will not be so popular in the mobile era, thus it will not be popular at all in a world where everyone has a smartphone. Furthermore, it will deserve not to be popular if this is because of the narrow-sighted idealism of developers. We are talking about two problems here.
|
|
The onion needs to be completely dropped.
…On Jun 7, 2017 7:25 AM, "palikacska" ***@***.***> wrote:
@optimumtact <https://github.com/optimumtact> If you don't make it
optional, the network will become bloated. If you don't make it optional, a *lot
of network traffic will be wasted* by Tox users just because of the
*idealism* of rerouting all connections that should not be rerouted in
99% of the cases.
If you don't make it optional, each mobile user with data plan will waste
several hundreds of dollars annually just to keep following this relaying
idealism.
So guess what, Tox will not be so popular in the mobile era, thus it will
not be popular at all in a world where everyone has a smartphone.
Furthermore, it will deserve not to be popular if this is because of the
narrow-sighted idealism of developers.
We are talking about two problems here.
1.
Tox relays all traffic into an onion in order to hide the identity of
its users. In 99% of the cases this should not be necessary. This will only
be necessary if you live in a police state where secret service comes after
you just because of the fact that you communicate with someone on the Tox
network or lock you up without a warrant for the same reason. In western
world, like the USA or the EU this is not the situation. *Pure P2P
connections should be allowed and even made default.* It will take a
huge amount of load off the onion and leave it for people who really need
it. For these reasons, Tox would have to be redesigned, using the
distributed network only for finding each other, and using the onion only
when specified.
2.
Tox makes it compulsory to participate in traffic relaying, regardless
of the bandwidth and other technical limits of the network connection used.
In the long term this will make the network very unreliable as well as
making mobile users with data plans waste a lot of money for relaying the
traffic. *Traffic relaying should be made optional.*
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#441 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAO20BTLziaFTf67z97OpL0Io97yNpgsks5sBrL0gaJpZM4Lk2Iy>
.
|
|
Someone suggested the above is overly general. So, just to be clear; finding friends with the onion is insecure, and doesn't offer the protections desired. The correct solution is to locate friends using something that can be considered private. The onion doesn't fit in that circle. |
|
is there any progress about this option? Looks like this is a main issue that makes Tox unusable on mobile devices. |
|
Mobile devices should use TCP. @zugz also has a replacement for the onion in the works, so I'll close this for now. |
Mind i ask what is that onion replacement? still serverless solution?, i am little out of loop. Thanks. |
|
Yes still serverless. |
|
Reopening this for now. We don't have zugz' new implementation yet, and maybe this becomes relevant at some point. |
|
Maybe private TCP relays could take some of the load off the public ones. If you have a desktop running the app, you could set it to relay TCP, but only for your friends and your own other accounts. In this semi-trusted mode you could also do things like have the TCP server reserve a bit of storage for each friend, and pass along true offline messages. The downside of this is that it becomes easier to attack an individual by becoming their friend and relaying traffic, and spying on the metadata, but it also makes it harder to attack anyone who isn't your friend since you no longer have to rely on a set of defaults by random strangers. Multiple trust levels for friends are a good idea anyway, not everyone needs to be able to send you large files, so this could be resolved just by not relaying traffic through untrusted friends, or just written off as a "Don't add enemy spies as your friends" fix. Most people would be a lot happier to relay messages for friends than strangers, this seems like a powerful way to strengthen the network. |
|
@EternityForest something along this line already exists: https://github.com/zoff99/ToxProxy it's not a perfect solution, but it does do offline messages and offline messages in group chats on a device that you keep at home |
|
That's pretty awesome! I wonder how hard it would be to merge the code and
standardize it for inclusion in clients?
…On Sat, Feb 5, 2022, 1:25 AM Zoff ***@***.***> wrote:
@EternityForest <https://github.com/EternityForest> something along this
line already exists:
https://github.com/zoff99/ToxProxy
it's not a perfect solution, but it does do offline messages and offline
messages in group chats on a device that you keep at home
—
Reply to this email directly, view it on GitHub
<#441 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAFZCHY6HFJ6GVDIQXIEADDUZTNG7ANCNFSM4C4TMIZA>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
it's more in a proof of concept state. |
I use uTox and Isotoxin and noticed that all two Tox clients generate some traffic at around 1kB/s. Checked it with a sniffer and looks like encrypted data. Did some Google search and I suppose it's DHT traffic coming from the bootstrap node I connect to. Can DHT traffic relaying be disabled?
I'm behind a firewall (restricted work network) and no other clients or nodes can connect to me. I also cannot connect to any other nodes that do not default to port 443. So I think it's nonsense for me to relay traffic. Or relay among whom? The only node I can communicate with is a TCP relay bootstrap node.
The text was updated successfully, but these errors were encountered: