C-toxcore: Функциональное предложение: сетевой вышибала

Я думаю, что эта функция, вероятно, лучше реализована в боте, а не в базовой библиотеке.

Вы должны быть в состоянии написать библиотеку bouncer, которая предоставляет интерфейс tox.h , чтобы клиенты могли быть созданы для него, как если бы это был toxcore, без необходимости изменения какого-либо клиентского кода. Например, первый вызов, который клиент делает для функции tox_bootstrap() в этой библиотеке баунсера, может рассматриваться как адрес:порт :pubkey демона баунсера, к которому должна подключиться библиотека баунсера. После того, как соединение будет установлено, все функции tox_ на клиенте будут RPC для удаленного вышибалы, например, клиент, выполняющий tox_friend_send_message() , отправит демону RPC с просьбой отправить это сообщение на наш имени и верните нам код функции, чтобы вернуть его клиенту. Библиотека bouncer может использовать все, что захочет, для связи с демоном bouncer, работающим на удаленном сервере, от простого HTTPS (что, вероятно, вам нужно, если вы хотите уменьшить использование сети) до пользовательских пакетов toxcore.

Да, я согласен с @sudden6 , это должна быть отдельная библиотека, а не часть библиотеки toxcore.

Я даже не думал о библиотеке RPC, а скорее о боте, который просто хранит сообщения и пересылает их по текстовой команде.

Как бы вы общались с ботом? Если бы это был бот Tox, разве вам не нужно было бы подключаться к DHT, чего хочет избежать zer0def?

@sudden6 Я больше думал о вышибале IRC, чем о боте. Не уверен, что вы знакомы с вышибалами IRC, так что просто представьте клиент qTox, который представляет собой графический интерфейс + toxcore, но вместо того, чтобы GUI и toxcore работали на вашем локальном компьютере, вы по-прежнему запускаете графический интерфейс, работающий на вашем компьютере, но toxcore — это графический интерфейс. взаимодействует с запущен на удаленном сервере. Вы можете добиться этого, написав библиотеку, которая притворяется toxcore, чтобы qTox компилировался с ней без каких-либо изменений кода, но на самом деле это был бы не toxcore, а скорее библиотека, которая взаимодействует с удаленным экземпляром toxcore.

Но разве это не реализовано в полных узлах, которые мобильные клиенты используют через режим TCP? Насколько я понимаю, режим TCP не участвует в сети DHT.

@dingosan , вам все еще нужно постоянно подключаться к узлу TCP. Насколько я понял, вышибала тоже будет хранить сообщения?

@sudden6 внезапно , вероятно, следует поддерживать согласованность журналов, иначе, вероятно, будет достаточно запуска ваших клиентов в качестве TCP-узла.

Привет, я выполняю подобную работу без изменения протокола toxcore.
Это не вышибала, как IRC, а больше похоже на мост.
Он использует gRPC/websock как для поддержки собственного программного клиента, так и для веб-приложения.
Мост хранит все сообщения, когда он находится в сети. И все клиенты моста могут получать синхронизированные сообщения.
Клиенты могут получать все сообщения истории, а несколько клиентов могут синхронизировать сообщения друг с другом с помощью моста.

Это работа в процессе, все еще демонстрация, кому интересно, может взглянуть:
https://github.com/envsh/tox-homeserver

Проблема в том, что теперь группа является временной, нет хорошего способа объединить групповые сообщения после повторного создания группы.

Аккуратно :) звучит офигенно!

Проблема в том, что теперь группа является временной, нет хорошего способа объединить групповые сообщения после повторного создания группы.

У нас такая же проблема в qTox. Это будет возможно с постоянными группами, потому что они имеют уникальные идентификаторы. Другой способ может состоять в том, чтобы рассматривать каждую созданную группу как отдельную и отображать их все как отдельную историю для пользователя. Так:

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

Это не так хорошо, но все еще можно использовать. Некоторые люди, возможно, даже предпочли бы смотреть на историю таким образом.