C-toxcore: Proposta de recurso: segurança de rede

Acho que esse recurso provavelmente é melhor implementado em um bot e não na biblioteca principal.

Você deve ser capaz de escrever uma biblioteca de segurança que exponha a interface tox.h para que os clientes possam ser construídos com ela como se fosse toxcore, sem a necessidade de alterar nenhum código do cliente. Por exemplo, a primeira chamada que um cliente faz para a função tox_bootstrap() nesta biblioteca de segurança pode ser tratada como address:port :pubkey de um daemon de segurança ao qual a biblioteca de segurança deve se conectar. Após a conexão ser estabelecida, todas as funções tox_ no cliente seriam RPC para o segurança remoto, por exemplo, o cliente fazendo tox_friend_send_message() enviaria um RPC para o daemon solicitando que ele enviasse aquela massagem em nosso nome e retornar o código da função de volta para nós para devolver ao cliente. A biblioteca do bouncer pode usar o que quiser para se comunicar com o daemon do bouncer em execução no servidor remoto, desde HTTPS simples (que provavelmente é o que você deseja se quiser reduzir o uso da rede) até os pacotes personalizados do toxcore.

Sim, concordo com @sudden6 , isso é algo que deve ser uma biblioteca separada, não parte da biblioteca toxcore.

Eu nem pensei em uma biblioteca RPC, mas mais como um bot que apenas armazena as mensagens e as encaminha em um comando de texto.

Como você se comunicaria com o bot? Se fosse um bot Tox, você não precisaria estar conectado ao DHT, o que zer0def quer evitar?

@sudden6 Eu estava pensando mais em termos de um segurança de IRC do que em um bot. Não tenho certeza se você está familiarizado com seguranças de IRC, então imagine o cliente qTox, que é uma GUI + toxcore, mas em vez de ter GUI e toxcore rodando em sua máquina local, você ainda executa a GUI rodando em sua máquina, mas o toxcore é a GUI se comunica está sendo executado em um servidor remoto. Você pode conseguir isso escrevendo uma biblioteca que finge ser toxcore, para que o qTox compile sem nenhuma alteração de código necessária, mas na verdade não seria um toxcore, mas sim uma biblioteca que se comunica com a instância remota do toxcore.

Mas isso não é implementado nos nós completos que os clientes móveis usam no modo TCP? O modo TCP não participa da rede DHT no meu melhor entendimento.

@dingosan você ainda precisa estar conectado o tempo todo ao nó TCP. Pelo que entendi, um segurança também armazenaria as mensagens?

@sudden6 provavelmente deve manter a consistência do log, caso contrário, executar seus clientes como um nó TCP provavelmente seria suficiente

Oi, estou fazendo alguns trabalhos como este sem modificar o protocolo toxcore.
Não é um segurança como o IRC, mas mais como uma ponte.
É usado gRPC/websock para suporte a cliente de programa nativo e aplicativo da web.
A ponte armazena todas as mensagens quando está online. E todos os clientes da bridge podem receber mensagens sincronizadas.
Os clientes podem puxar todas as mensagens do histórico e vários clientes podem sincronizar mensagens entre si com a ajuda da causa do bridge.

Este é um trabalho em andamento, ainda é uma demonstração, qualquer pessoa interessante pode dar uma olhada:
https://github.com/envsh/tox-homeserver

O problema é que agora o grupo é temporário, não há uma boa maneira de mesclar mensagens de grupo após recriar o grupo.

Legal :) parece incrível!

O problema é que agora o grupo é temporário, não há uma boa maneira de mesclar mensagens de grupo após recriar o grupo.

Temos o mesmo problema no qTox. Isso será possível com grupos persistentes, pois eles possuem IDs exclusivos. Outra maneira poderia ser tratar cada grupo criado como separado e mostrar todos eles como um histórico separado para o usuário. Assim:

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

Não é tão bom, mas ainda utilizável. Algumas pessoas talvez até preferissem ver a história dessa maneira.