New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature proposal: network bouncer #695
Comments
I think this feature is probably better implemented in a bot and not in the core library. |
You should be able to write a bouncer library that exposes Yeah, I agree with @sudden6 , that's something that should be a separate library, not a part of the toxcore library. |
I didn't even think as far as a RPC library, but more like a bot that just stores the messages and forwards them on a text command. |
How would you communicate with the bot? If it was a Tox bot, wouldn't you need to be connected to the DHT, which zer0def wants to avoid? |
@sudden6 I was thinking more in terms of an IRC bouncer rather than a bot. Not sure if you are familiar with IRC bouncers, so just imagine the qTox client, which is a GUI + toxcore, but instead of having GUI and toxcore running on your local machine you stll run the GUI running on your machine but the toxcore the GUI communicates with is running on a remote server. You could achieve this by writing a library that pretends to be toxcore, so that qTox would compile against it without any code changes needed, but in actually it wouldn't be a toxcore but rather a library that communicates with the remote toxcore instance. |
But isn't this implemented in the full nodes that the mobile clients make use of via the TCP mode? The TCP mode does not participate in the DHT network to my best understanding. |
@dingosan you still need to be connected all the time to the TCP node. As far as I understood, a bouncer would also store the messages? |
@sudden6 it probably should to maintain log consistency, otherwise running your clients as a TCP node would probably suffice |
Hi, I am do some work like this without modify toxcore protocol. This is work in progress, still a demo, anyone interesting can take a look: The problem is now the group is temporary, there is not good way to merge group messages after recreate group. |
Neat :) sounds awesome! |
We have the same problem in qTox. It will be possible with persistent groups, because they have unique IDs. Another way could be to treat each created group as separate and show all of them as separate history to the user. Like this:
It's not as good, but still usable. Some people maybe would even prefer to see history this way. |
This should be done in a layer above toxcore. |
The idea largely resembles IRC bouncers, where one sets up a proxy/relay client which remains connected to the network, while the actual client attaches to/detaches from the bouncer in order to communicate. That would especially aid adoption for mobile systems (for example, smartphones) which suffer battery drain and telco network costs from DHT.
Only mentioning this, because I've had at least 3 people abandon the network solely because they're primarily mobile users and consider the forementioned drawbacks unacceptable.
The text was updated successfully, but these errors were encountered: