C-toxcore: Feature proposal: network bouncer

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 tox.h interface so that clients could be built against it as if it was toxcore, without need to change any client code. For example, the first call a client does to tox_bootstrap() function in this bouncer library could be treated as address:port:pubkey of a bouncer daemon that the bouncer library should connect to. After the connection is established, all tox_ functions on the client would be RPC for the remote bouncer, e.g. the client doing tox_friend_send_message() would send a RPC to the daemon asking it to send that massage on our behalf and return the function code back to us to give back to the client. The bouncer library could use anything it wants for communicating with the bouncer daemon running on the remote server, from plain HTTPS (which is probably what you want if you want to reduce the network usage) to toxcore's custom packets.

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.
It's not a bouncer like IRC, but more like as a bridge.
It's use gRPC/websock for both support native program client and web app.
The bridge store all messages when it's online. And all bridge's clients can receive messages synchronized .
The clients can pull all history messages, and multiple clients can sync messages each other with bridge's help of cause.

This is work in progress, still a demo, anyone interesting can take a look:
https://github.com/envsh/tox-homeserver

The problem is now the group is temporary, there is not good way to merge group messages after recreate group.

Neat :) sounds awesome!

The problem is now the group is temporary, there is not good way to merge group messages after recreate group.

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:

26.05.2018 12:45 Tox Public Chat
26.05.2018 11:31 #toktok
26.05.2018 10:15 meeting
25.05.2018 08:10 meeting
24.05.2018 01:20 Tox Public Chat

It's not as good, but still usable. Some people maybe would even prefer to see history this way.