C-toxcore: Funktionsvorschlag: Netzwerk-Bouncer

Ich denke, diese Funktion ist wahrscheinlich besser in einem Bot und nicht in der Kernbibliothek implementiert.

Sie sollten in der Lage sein, eine Bouncer-Bibliothek zu schreiben, die die tox.h -Schnittstelle verfügbar macht, sodass Clients dagegen gebaut werden können, als wäre es Toxcore, ohne dass der Client-Code geändert werden muss. Beispielsweise könnte der erste Aufruf eines Clients an die tox_bootstrap() -Funktion in dieser Bouncer-Bibliothek als Adresse:Port :Pubkey eines Bouncer-Daemons behandelt werden, mit dem sich die Bouncer-Bibliothek verbinden soll. Nachdem die Verbindung hergestellt wurde, wären alle tox_ -Funktionen auf dem Client RPC für den entfernten Bouncer, z. B. würde der Client, der tox_friend_send_message() ausführt, einen RPC an den Daemon senden, der ihn auffordert, diese Nachricht an unseren zu senden Namen und senden Sie den Funktionscode an uns zurück, um ihn dem Kunden zurückzugeben. Die Bouncer-Bibliothek könnte alles verwenden, was sie für die Kommunikation mit dem Bouncer-Daemon verwenden möchte, der auf dem Remote-Server läuft, von einfachem HTTPS (was wahrscheinlich das ist, was Sie wollen, wenn Sie die Netzwerknutzung reduzieren möchten) bis zu den benutzerdefinierten Paketen von Toxcore.

Ja, ich stimme @sudden6 zu, das sollte eine separate Bibliothek sein, kein Teil der Toxcore-Bibliothek.

An eine RPC-Bibliothek habe ich gar nicht gedacht, sondern eher an einen Bot, der die Nachrichten einfach speichert und auf einen Textbefehl weiterleitet.

Wie würden Sie mit dem Bot kommunizieren? Wenn es ein Tox-Bot wäre, müssten Sie nicht mit dem DHT verbunden sein, was zer0def vermeiden möchte?

@plötzlich6 Ich dachte eher an einen IRC-Bouncer als an einen Bot. Nicht sicher, ob Sie mit IRC-Bouncern vertraut sind, also stellen Sie sich einfach den qTox-Client vor, der eine GUI + Toxcore ist, aber anstatt GUI und Toxcore auf Ihrem lokalen Rechner laufen zu lassen, führen Sie immer noch die GUI auf Ihrem Rechner aus, aber den Toxcore die GUI kommuniziert mit läuft auf einem entfernten Server. Sie könnten dies erreichen, indem Sie eine Bibliothek schreiben, die vorgibt, Toxcore zu sein, sodass qTox dagegen kompilieren würde, ohne dass Codeänderungen erforderlich sind, aber in Wirklichkeit wäre es kein Toxcore, sondern eine Bibliothek, die mit der entfernten Toxcore-Instanz kommuniziert.

Aber ist dies nicht in den vollständigen Knoten implementiert, die die mobilen Clients über den TCP-Modus verwenden? Der TCP-Modus nimmt nach meinem besten Verständnis nicht am DHT-Netzwerk teil.

@dingosan Sie müssen immer noch ständig mit dem TCP-Knoten verbunden sein. Soweit ich verstanden habe, würde ein Türsteher die Nachrichten auch speichern?

@plötzlich6 es sollte wahrscheinlich die Protokollkonsistenz aufrechterhalten, andernfalls würde es wahrscheinlich ausreichen, Ihre Clients als TCP-Knoten auszuführen

Hallo, ich mache einige Arbeiten wie diese, ohne das Toxcore-Protokoll zu ändern.
Es ist kein Türsteher wie IRC, sondern eher eine Brücke.
Es verwendet gRPC/Websock sowohl für die Unterstützung des nativen Programmclients als auch für die Web-App.
Die Bridge speichert alle Nachrichten, wenn sie online ist. Und alle Clients der Bridge können synchronisierte Nachrichten empfangen.
Die Clients können alle Verlaufsnachrichten abrufen, und mehrere Clients können Nachrichten mit Hilfe von Bridge gegenseitig synchronisieren.

Dies ist in Arbeit, noch eine Demo, jeder Interessierte kann einen Blick darauf werfen:
https://github.com/envsh/tox-homeserver

Das Problem ist jetzt, dass die Gruppe temporär ist, es gibt keine gute Möglichkeit, Gruppennachrichten zusammenzuführen, nachdem die Gruppe neu erstellt wurde.

Ordentlich :) hört sich toll an!

Das Problem ist jetzt, dass die Gruppe temporär ist, es gibt keine gute Möglichkeit, Gruppennachrichten zusammenzuführen, nachdem die Gruppe neu erstellt wurde.

Wir haben das gleiche Problem in qTox. Mit persistenten Gruppen wird dies möglich sein, da sie eindeutige IDs haben. Eine andere Möglichkeit könnte darin bestehen, jede erstellte Gruppe separat zu behandeln und dem Benutzer alle als separate Historie anzuzeigen. So was:

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

Es ist nicht so gut, aber immer noch brauchbar. Manche Menschen würden es vielleicht sogar vorziehen, die Geschichte so zu sehen.