Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 43
Это всё здорово, но
Рад бы использовать для общения с семьёй, продвигать по работе, но на текущем этапе оно не пригодно ни для чего, кроме общения гиков.
- Где звук под мобильные платформы?
- Где эхоподавление в десктопном клиенте?
- Как пользоваться на нескольких устройствах?
- Что делать с оффлайн сообщениями?
Рад бы использовать для общения с семьёй, продвигать по работе, но на текущем этапе оно не пригодно ни для чего, кроме общения гиков.
> Что делать с оффлайн сообщениями?
Как вы себе это представляете в без-серверной архитектуре?
> Как пользоваться на нескольких устройствах?
Из той же серии, нет ведь сервера для синхронихации между клиентами.
Если вам нужно что-то с центральным сервером, то зачем тогда смотреть на Tox.
Как вы себе это представляете в без-серверной архитектуре?
> Как пользоваться на нескольких устройствах?
Из той же серии, нет ведь сервера для синхронихации между клиентами.
Если вам нужно что-то с центральным сервером, то зачем тогда смотреть на Tox.
1) Как у Шкапа — оффлайн сообщения висят в исходящих, пока оба не окажутся в онлайне. Понимаю, криво, но таки.
2) Разве невозможно подвязать двух клиентов на специфических условиях, чтобы обменялись историями?
Но, на самом деле меня интересует какой SLA у Tox — процент потерь «пинга», собственно время «пинга». А то я видал как-то СМС «с новым годом» в феврале, что не укладывается в моё понимание техники СМС.
И маскировка трафика против цензоров Tor, как такового, есть/будет?
В дальнейшем, конечно, потребуются расширенные функции передачи сообщений, ставших де-факто стандартом, например, передача файлов.
Я вот так осознаю разницу между Proof of Conception и популярным End User продуктом.
2) Разве невозможно подвязать двух клиентов на специфических условиях, чтобы обменялись историями?
Но, на самом деле меня интересует какой SLA у Tox — процент потерь «пинга», собственно время «пинга». А то я видал как-то СМС «с новым годом» в феврале, что не укладывается в моё понимание техники СМС.
И маскировка трафика против цензоров Tor, как такового, есть/будет?
В дальнейшем, конечно, потребуются расширенные функции передачи сообщений, ставших де-факто стандартом, например, передача файлов.
Я вот так осознаю разницу между Proof of Conception и популярным End User продуктом.
Передача файлов давно есть. А вот маскировка — это интересно.
Как у Шкапа — оффлайн сообщения висят в исходящих, пока оба не окажутся в онлайне. Понимаю, криво, но таки.
Так оно сейчас и происходит в некоторых клиентах.
Разве невозможно подвязать двух клиентов на специфических условиях, чтобы обменялись историями?
В теории да, но на практике это сильно будет усложнять протокол без добавления к-л гарантий.
Но, на самом деле меня интересует какой SLA у Tox — процент потерь «пинга», собственно время «пинга».
Чем больше мощность сети, тем надежней ее работа. Точных цифр никто никогда сказать не сможет ввиду самой природы сети, но на данный момет все работает вполне себе быстро и относительно надежно.
И маскировка трафика против цензоров Tor, как такового, есть/будет?
Тут не совсем понятно что имеется ввиду. Весь трафик Tox всегда шифруется, номера портов владелец ноды волен выбирать любые, маршруты Tor периодически меняются.
Как вы себе это представляете в без-серверной архитектуре?
Исхитриться-то как-нибудь можно. Например, остающиеся в онлайне клиенты могли бы хранить сообщения (скажем, с некоторым таймаутом) для дальнейшей передачи получателю и перекидывать их другим при плановом выходе из сети. Для повышения надёжности можно ввести дублирование (скажем, кто-то оказывается "главным хранителем" сообщения и назначает нескольких дублёров, при внезапном выходе дублёров из сети назначают новых дублёров, при уходе главхранителя им становится один из дублёров). Если сохранять сообщения в локальном хранилище и возобновлять бдение при возвращении в онлайн, можно будет дополнительно защититься от потери сообщения при внезапном выпадении сразу всех хранителей.
И, таким образом, у нас будет очень много ненужного, даже паразитного, трафика, тем более, если в сообщении содержится какой-нибудь тяжёлый файл. Объёмы «хранителей», «дублёров» и количество одновременных соединений небесконечны, что предоставляет прекрасную возможность для атаки на всю сеть разом, используя всего одного атакующего, если я всё правильно понял.
Никто и не предлагает файлы в оффлайн передавать. Мало какие IM это позволяют, да и не нужно это.
А вот передачу сообщений по предложенному механизму вполне можно сделать. Объем трафика врядли увеличится значительно, т.к. много сообщений никто в оффлайн не отправляют. Плюс если сделать срох хранения небольшим — скажем 72 часа как у СМС — сеть будет чистится.
В тоже время даже если хранителей не будет в результате атаки или по любой другой причине — когда автор выйдет в онлайн, клиент увидит что сообщение до сих пор не доставлено — отправит его повторно.
А вот передачу сообщений по предложенному механизму вполне можно сделать. Объем трафика врядли увеличится значительно, т.к. много сообщений никто в оффлайн не отправляют. Плюс если сделать срох хранения небольшим — скажем 72 часа как у СМС — сеть будет чистится.
В тоже время даже если хранителей не будет в результате атаки или по любой другой причине — когда автор выйдет в онлайн, клиент увидит что сообщение до сих пор не доставлено — отправит его повторно.
Гарантии получается все равно нет — если уходишь в оффлайн надолго — гадай доставлено или нет. С дублерами и хранителями тоже самое — гарантировать что они все не уйдут в оффлайн быстрее передачи сообщения невозможно. Плюс можно спамить гигабайтами текста, забивая память.
То есть опять таки нужна супернода (сервер) для хранения сообщений, чтоб хоть какие-то гарантии были.
Вариант пересылать когда оба в онлайне — это уже задача клиента, а не протокола.
Т.е. на взгляд элементарная задача, но с требованиями а). распределенности б). гарантированной доставки сообщения решить ее далеко не просто.
То есть опять таки нужна супернода (сервер) для хранения сообщений, чтоб хоть какие-то гарантии были.
Вариант пересылать когда оба в онлайне — это уже задача клиента, а не протокола.
Т.е. на взгляд элементарная задача, но с требованиями а). распределенности б). гарантированной доставки сообщения решить ее далеко не просто.
Сообщение будет гарантированно доставлено. Например, когда автор выйдет в онлайн.
Ну это же не интересные доводы. Из разряда: не более 100 килобайт текста от одного автора.
В конце, концов, если ТАК важна доставка в онлайн — делается личный "хранитель" на своем сервере, который работает хранителем только для вас.
Или же арендуется услуга такого хранителя предоставляемого кем-то другим.
Вот только не надо решать это через централизованные сервера, как в случае со скайпом сделали.
Плюс можно спамить гигабайтами текста, забивая память.
Ну это же не интересные доводы. Из разряда: не более 100 килобайт текста от одного автора.
В конце, концов, если ТАК важна доставка в онлайн — делается личный "хранитель" на своем сервере, который работает хранителем только для вас.
Или же арендуется услуга такого хранителя предоставляемого кем-то другим.
Вот только не надо решать это через централизованные сервера, как в случае со скайпом сделали.
"Хранитель" и будет этим центральным сервером. Сейчас ничего не мешает взять консольный клиент и запустить его на своем выделенном сервере — клиент будет 24х7 в онлайне, а уж чем забирать с него историю и как через него отправлять сообщения — это вопрос не сильно сложный технологически.
Центральный сервер — это устройство, которое:
1) необходимо для работы
2) находится в ведомстве конкретной группы людей
Очевидно, что хранитель оба эти требования не удовлетворяет. Он может принадлежать кому угодно и не нужен для работы. Лишь дополнительный сервис.
Технически плевое дело.
Правда концепция хранителей позволит передавать свои сообщения левым людям, не заморачиваясь с установкой личного сервера, в отличии от предложенного варианта с клиентом в вечном онлайне.
1) необходимо для работы
2) находится в ведомстве конкретной группы людей
Очевидно, что хранитель оба эти требования не удовлетворяет. Он может принадлежать кому угодно и не нужен для работы. Лишь дополнительный сервис.
Технически плевое дело.
Правда концепция хранителей позволит передавать свои сообщения левым людям, не заморачиваясь с установкой личного сервера, в отличии от предложенного варианта с клиентом в вечном онлайне.
Сообщение будет гарантированно доставлено. Например, когда автор выйдет в онлайн.
Такой функционал уже имеется в клиентах. Это гарантия со стороны клиента а не протокола.
В конце, концов, если ТАК важна доставка в онлайн — делается личный «хранитель» на своем сервере, который работает хранителем только для вас.
С таким же успехом можно просто не выходить из Tox на своем компе и оставить его запущенным.
Вот только не надо решать это через централизованные сервера, как в случае со скайпом сделали.
Попробуйте на досуге придумать метод гарантированной доставки оффлайн сообщения без супернод (==хранитель который всегда онлайн == зависимость от владельца этой ноды). Именно оффлайн, а не доставлять когда оба онлайн (это, как мы сказали, уже есть)
Хранить в DHT сети (при условии что это часть протокола конечно)? Т е данные размазаны по куче разных клиентских устройств. Но имхо лучше так хранить вещи вроде списка контактов, метаинформации
Хранить у всех пользователей все ожидающие сообщения? Куча памяти.
У части? У какой? А если они уходят в оффлайн — копировать другим или как? Слишком маленькая часть — есть вероятность что все уйдут в оффлайн, слишком большая — слишком много места будут занимать эти сообщения, тем более если хранить их вечно. Не вечно? А сколько тогда? И т.д.
У части? У какой? А если они уходят в оффлайн — копировать другим или как? Слишком маленькая часть — есть вероятность что все уйдут в оффлайн, слишком большая — слишком много места будут занимать эти сообщения, тем более если хранить их вечно. Не вечно? А сколько тогда? И т.д.
Хранить можно и на диске, зарезервировав сколько-там места, например 50МБ. Хранение не у всех конечно. и не у определенного числа пользователей — данные не просто режутся на дольки а создается большое число частей — с избыточностью. скажем, при избыточности 3х у нас получается 30 долек — из которых любых 10 достаточно для получения точной копии. 20 нод из 30 могут уйти оффлайн. избыточность и количество частей можно подобрать. Гарантии оно не дает конечно но вероятность ухода оффлайн всех нод одновременно если N большое достаточно мала.
Достаточно просто решается введением времени жизни на уровне протокола. Сразу обещаем что оффлайн живет неделю скажем. Это все-таки IM.
P.S. существуют распределенные децентрализованные системы, хранящие так информацию (см maidsafe, storj.io)
Никто не говорит что это просто. Это возможно.
Не вечно? А сколько тогда? И т.д.
Достаточно просто решается введением времени жизни на уровне протокола. Сразу обещаем что оффлайн живет неделю скажем. Это все-таки IM.
P.S. существуют распределенные децентрализованные системы, хранящие так информацию (см maidsafe, storj.io)
Никто не говорит что это просто. Это возможно.
Предлагаю вам отписаться тут.
Perfect Dark еще работает по такому принципу.
Попробуйте на досуге придумать метод гарантированной доставки оффлайн сообщения без супернод
Волшебство?
Ну а в целом, вы требуете от инструмента то, чего в нем никогда не было и не будет. А именно — гарантий.
IM никогда не был способом гарантированно доставить сообщение. Даже в онлайне. И не смотря на то, что надежность их весьма высока: гарантии — это не про них.
Если сохранять сообщения в локальном хранилище и возобновлять бдение при возвращении в онлайн, можно будет дополнительно защититься от потери сообщения при внезапном выпадении сразу всех хранителей.
Собственно qTox сейчас именно так и делает.
qTox уже наверно год не может починить багу с потерей соединения после спящего режима, что делает его непригодным к использованию. И при этом насколько я знаю это лучший кросс платформенный криент.
Если я верно понял, то это баг не самого qTox'а, а core-либы — https://github.com/irungentoo/toxcore/issues/1550
Blockchain, например. Только такие оффлайн-сообщения не получится хранить вечно, будут отпадать по таймауту. Вроде у Bitmessage есть подобное.
- Через транзитные ноды, которые или доставили немедленно или выставили TTL и выслали другим транзитным нодам, и пусть по сети гуляет сообщение до исчерпания TTL. Оно же и так зашифровано.
Правда при включении вашего клиента обратно — получите пачку копий с разных узлов, но это как раз не проблема. Банально введите сообщению GUID и дропайте повторения.
- А несколько устройств — это обычная репликация с ноды А на ноду Б (и наоборот), если у вас одинаковый private key у обоих — то вот вам и решение. И механизм поддержки офлайна вполне справится с «одну выключил вторую включил».
Из-за природы Tox-сети, в ней невозможно нормально реализовать offline-сообщения. Для меня очень важна данная функциональность, поэтому при всей моей любви к tox, я им пользоваться не могу.
Пока не будет нормальных удобных клиентов с полноценным функционалом, все преимущества протокола можно забыть ибо нормально пользоваться невозможно, а пока имеем кучу глючных клиентов с сильно кастрированным функционалом для некоторых платформ.
Поздравляю, наверное, с помощью данной статьи в настоящий момент разрыв по количеству пользователей в России всего лишь на 1 меньше чем в США (544 vs 545 соответственно)!
Осталось только мне зайти в tox=) Жаль пароль забыл...
Осталось только мне зайти в tox=) Жаль пароль забыл...
Нужен клиент для роутеров, чтобы сидел в инвизе и принимал офлайновые сообщения и раздавал на вошедшие в сеть устройства. И самое главное полноценные клиенты для мобильных устройств.
И самое главное полноценные клиенты для мобильных устройств.
Глупо ждать полноценные клиенты когда в core-либе периодически ломают API, недавно как раз были изменения в A/V API, сейчас вот почти готова новая реализация групп-чатов с новым API и протоклом.
Изменения в API известны задолго до их вливания в ядро. Так, например, к новому ToxAV были готовы все клиенты и переключились в течении суток. Я бы не назвал это "ломают".
Проблема с мобильными клиентами, как мне кажется, немного в другом — людям, которым интересен проект, не особо интересна мобильная версия. Людям, которым интересна мобильная версия, не особо интересен проект. И тех и других по своему можно понять.
Проблема с мобильными клиентами, как мне кажется, немного в другом — людям, которым интересен проект, не особо интересна мобильная версия. Людям, которым интересна мобильная версия, не особо интересен проект. И тех и других по своему можно понять.
Tox хорошая вещь, особенно когда допилят. И сейчас бы пользовался. вот только, а как пользоваться одним аккаунтом на нескольких устройствах?
А нужно ли это? Очень вероятно что проблему нескольких аккаунтов можно было бы решить, сделав использование нескольких сразу удобным (группы аккаунтов или что-то такое). Да, история не синхронизируется. Но, во-первых это плата за безопасность, а во-вторых без этого вполне можно жить (особенно если предусмотрена нормальная ручная синхронизация: я на компе нажимаю на сообщении «синхронизовать с мобильным аккаунтом» и готово). Короче нужно делать не «так как в скайпе», а так, чтобы было удобно. Хотя оно и будет иначе из-за другой природы сети.
Скорее всего вы меня не так поняли. Допустим на одном ПК установим Tox-клиент, а потом на втором ПК тоже. Но как на них выходя в сеть Tox, авторизироваться в одном и том же аккаунте? Я не имею ввиду, что сидеть сразу с двух. А только с одного в один момент времени.
Скопировать профиль с ключами?
Мой ответ предполагал что это вам просто не надо. Сама концепция решает это по другому. Как пример (возможно сырой): под именем пользователя в списке контактов могут скрываться несколько аккаунтов и сообщения посылаются на все из них (хотя реально это должно быть гибко, т.к. ту информацию что я доверяю для обработки на ПК, я могу не доверять обрабатывать на мобилке). Над конкретной реализацией нужно хорошенько подумать чтобы сбалансировать удобство/безопасность/нагрузку на сеть.
Жаль, что нет версии для Debian arm. И я правильно понимаю, что сама по себе ваша сборка порт в роутере не пробрасывает?
Извините за некропостинг, но глаз зацепился за абзац про расстояние между нодами. Мне кажется, там какая-то путаница: максимальное расстояние между нодами — 111...1 — будет не для половины пространства ключей, а ровно для одной ноды (если такая есть).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Распределенная природа мессенджера Tox