C-toxcore: Propuesta de función: gorila de la red

Creado en 18 ene. 2018  ·  11Comentarios  ·  Fuente: TokTok/c-toxcore

La idea se asemeja en gran medida a los rebotadores de IRC, donde uno configura un cliente proxy/retransmisor que permanece conectado a la red, mientras que el cliente real se conecta o desconecta del rebotador para poder comunicarse. Eso ayudaría especialmente a la adopción de sistemas móviles (por ejemplo, teléfonos inteligentes) que sufren el agotamiento de la batería y los costos de la red de telecomunicaciones de DHT.

Solo menciono esto, porque he tenido al menos 3 personas que abandonaron la red únicamente porque son principalmente usuarios móviles y consideran inaceptables los inconvenientes mencionados anteriormente.

P3 proposal

Comentario más útil

Debería poder escribir una biblioteca de rebotes que exponga la interfaz tox.h para que los clientes puedan construirse contra ella como si fuera toxcore, sin necesidad de cambiar ningún código de cliente. Por ejemplo, la primera llamada que hace un cliente a la función tox_bootstrap() en esta biblioteca de rebote podría tratarse como dirección: puerto : clave pública de un demonio de rebote al que debería conectarse la biblioteca de rebote. Después de establecer la conexión, todas las funciones tox_ en el cliente serían RPC para el gorila remoto, por ejemplo, el cliente que hace tox_friend_send_message() enviaría un RPC al daemon pidiéndole que envíe ese mensaje a nuestro nombre y devolvernos el código de función para devolverlo al cliente. La biblioteca bouncer podría usar cualquier cosa que desee para comunicarse con el demonio bouncer que se ejecuta en el servidor remoto, desde HTTPS simple (que es probablemente lo que desea si desea reducir el uso de la red) hasta los paquetes personalizados de toxcore.

Sí, estoy de acuerdo con @sudden6 , eso es algo que debería ser una biblioteca separada, no una parte de la biblioteca toxcore.

Todos 11 comentarios

Creo que esta característica probablemente se implemente mejor en un bot y no en la biblioteca principal.

Debería poder escribir una biblioteca de rebotes que exponga la interfaz tox.h para que los clientes puedan construirse contra ella como si fuera toxcore, sin necesidad de cambiar ningún código de cliente. Por ejemplo, la primera llamada que hace un cliente a la función tox_bootstrap() en esta biblioteca de rebote podría tratarse como dirección: puerto : clave pública de un demonio de rebote al que debería conectarse la biblioteca de rebote. Después de establecer la conexión, todas las funciones tox_ en el cliente serían RPC para el gorila remoto, por ejemplo, el cliente que hace tox_friend_send_message() enviaría un RPC al daemon pidiéndole que envíe ese mensaje a nuestro nombre y devolvernos el código de función para devolverlo al cliente. La biblioteca bouncer podría usar cualquier cosa que desee para comunicarse con el demonio bouncer que se ejecuta en el servidor remoto, desde HTTPS simple (que es probablemente lo que desea si desea reducir el uso de la red) hasta los paquetes personalizados de toxcore.

Sí, estoy de acuerdo con @sudden6 , eso es algo que debería ser una biblioteca separada, no una parte de la biblioteca toxcore.

Ni siquiera pensé en una biblioteca RPC, sino más bien en un bot que simplemente almacena los mensajes y los reenvía con un comando de texto.

¿Cómo te comunicarías con el bot? Si fuera un bot Tox, ¿no necesitarías estar conectado al DHT, que zer0def quiere evitar?

@sudden6 Estaba pensando más en términos de un gorila de IRC que de un bot. No estoy seguro si está familiarizado con los gorilas de IRC, así que imagine el cliente qTox, que es una GUI + toxcore, pero en lugar de tener GUI y toxcore ejecutándose en su máquina local, aún ejecuta la GUI ejecutándose en su máquina pero el toxcore la GUI se comunica con se está ejecutando en un servidor remoto. Podría lograr esto escribiendo una biblioteca que pretenda ser toxcore, de modo que qTox se compile contra ella sin necesidad de cambios de código, pero en realidad no sería un toxcore sino una biblioteca que se comunica con la instancia remota de toxcore.

¿Pero no se implementa esto en los nodos completos que utilizan los clientes móviles a través del modo TCP? Según tengo entendido, el modo TCP no participa en la red DHT.

@dingosan aún necesita estar conectado todo el tiempo al nodo TCP. Por lo que entendí, ¿un gorila también almacenaría los mensajes?

@sudden6 probablemente debería mantener la consistencia del registro; de lo contrario, ejecutar sus clientes como un nodo TCP probablemente sería suficiente

Hola, estoy haciendo un trabajo como este sin modificar el protocolo toxcore.
No es un gorila como IRC, sino más bien como un puente.
Se usa gRPC/websock para admitir el cliente del programa nativo y la aplicación web.
El puente almacena todos los mensajes cuando está en línea. Y todos los clientes del puente pueden recibir mensajes sincronizados.
Los clientes pueden extraer todos los mensajes del historial y varios clientes pueden sincronizar mensajes entre sí con la ayuda de la causa del puente.

Este es un trabajo en progreso, aún es una demostración, cualquier persona interesada puede echarle un vistazo:
https://github.com/envsh/tox-homeserver

El problema ahora es que el grupo es temporal, no hay una buena manera de fusionar los mensajes del grupo después de volver a crear el grupo.

Genial :) suena increíble!

El problema ahora es que el grupo es temporal, no hay una buena manera de fusionar los mensajes del grupo después de volver a crear el grupo.

Tenemos el mismo problema en qTox. Será posible con grupos persistentes, porque tienen identificaciones únicas. Otra forma podría ser tratar cada grupo creado como separado y mostrarlos todos como un historial separado para el usuario. Me gusta esto:

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

No es tan bueno, pero aún utilizable. Algunas personas incluso preferirían ver la historia de esta manera.

¿Fue útil esta página
0 / 5 - 0 calificaciones

Temas relacionados

ovalseven8 picture ovalseven8  ·  11Comentarios

zoff99 picture zoff99  ·  4Comentarios

DataMaster-2501 picture DataMaster-2501  ·  6Comentarios

zoff99 picture zoff99  ·  7Comentarios

grinapo picture grinapo  ·  4Comentarios