Pull to refresh

Comments 69

Y — это от 'yet another...'?

Не, ну ребят, вы серьёзно? Новый мессенджер? А дальше что, новый поисковик?
Новый браузер забыли, это же тренд
Смех смехом, а вот нового поисковика не помешало бы.
Например более специализированного. Для IT сектора, юристов и т.п.
Считаю что будет весьма востребовано.

Ещё не хватает независимых агрегаторов новостей.
А можно конкретный кейс и конечную цель? Ведь результат это не поисковик как таковой, а более релевантный результат поиска?

Я просто почему акцентируюсь на этом. Конечный результат можно получить и без создания своего поисковика. Это мета поиск. Приведу пример. У нас был проект агрегатора магазинов детской одежды. Возникла задача добавить туда еще Х магазинов в заданном регионе. В итоге я сделал парсер поисковой выдачи Яндекса по магазинам в заданном регионе + обход этих магазинов с целью поиска каналов связи с ними (телефон, почта). После чего начали холодный обзвон магазинов. По сути как результат получили мета поисковик заточенный под решение конкретного кейса. Для получения этого результата не пришлось создавать поиск общего назначения и удалось получить работающий модуль буквально за пару дней.
Да, отдельный поисковик писать не совсем корректно.

Можно воспользоваться имеющимися поисковикам, особенно если их api позволяет это сделать «законно».

Отдельный поисковик подошел бы юристам и бухгалтерам активно работающих с номенклатурой. Сейчас они решают эти задачи с помощью программ типа Консультант плюс и Гарант., но что если все эти ресурсы объединить под одним поисковиком? Все юридические ресурсы, включая конечно же государственные.

А что такой бы поисковик улучши бы? Данные системы работают на рынке уже даже не первое десятилетие и имеют огромный опыт и базу документов. Кому и для чего нужен был бы такой поисковик? Это я даже пока не предлагаю задуматься о смехе монетизации/финансированная такого проекта.
Соглашусь.
Юристам и бухгалтерам быстрее и надежнее воспользоваться специализированным софтом.
Обычным людям достаточно будет гугла и яндекса.

Вот обычным людям типа меня недостаточно: в выдаче консультации, новости, что угодно, но не официальные или доверенные источники, особенно когда нужно найти какой-нибудь не закон, а подзаконный акт.

Немного порассуждаю про востребованность.
Беру упомянутый Консультант и Гарант. Вот конкурентный проект pravo.ru который в свое время пытался отстраиваться от них не поиском (поиск априори механизм который должен быть из коробки и быстро работать), а созданием сообщества юристов + современный интерфейс. История с поиском в принципе не очень связанная, хотя под капотом в итоге сложная система на базе sphinx search.
К сожалению я не компетентен в этих вопросах, но сама идея специализированных поисковых систем мне интересна.
Как умственный эксперимент в плане применимости в той или иной сфере.

В общем то многие из читателей Хабра имеют по крайней мере базовые представления о it технологиях и хотелось бы понять про особенности технической реализации. Пока от манифеста неясно на кого он ориентирован. Инвесторы тут не читают.

Отлично. Теперь можно следующий шаг — заказывать независимый аудит кода.
И нужно еще отдельное описание алгоритмов и криптографии для отдельного анализа.

Вы будете данные ваших пользователей будут храниться у вас на сервере
Так мы будем или данные будут?

Персональные данные шифруются и отправляются в блокчейн
Как-то не очень вяжется с предыдущим заявлением.
Хотя постойте, это я дурак, ведь обещали только «данные ваших пользователей будут храниться у вас на сервере», а не «данные ваших пользователей будут храниться только у вас на сервере».
Теперь непонятно, нафига мне разворачивать сервер, если данные всё равно в блокчейне.

Исходный код сервера, компонентов шифрования и приложений будет открыт. Протокол сетевого обмена будет открыт. Если вы разбираетесь в C++ / C# / Kotlin или React, вы сможете познакомиться с нашим продуктом изнутри, убедиться в правдивости наших слов и даже сделать свою собственную версию.
Это супер! Но сразу возникает пара вопросов.

Первый. Вами же чуть выше заявлялось:
Заканчивается разными интерфейсными приемами вроде блокировки снимков экрана, когда на экране есть защищенные сообщения
Допустим, я вам поверил и отправил свое супер-пупер секретное сообщение в надежде, что мой собеседник его не заскриншотит. Как (при условии открытия исходников) вы можете гарантировать, что у моего собеседника версия клиента не собрана из исходников с вырезанной функцией блокировки скриншотов (тут я не поднимаю вопрос о том, насколько нужна такая функция — ваши приёмы элементарно обходятся фотографированием экрана камерой другого телефона)?

Второй. Вы обсуждаете возможность монетизации с помощью «простой помесячной подписки на обновления сервера». Я что-то не очень понимаю, как при открытых исходниках можно ограничить возможность обновления сервера тем, кто не оплатил подписку.

я уверяю вас, что к концу статьи вы начнете доверять нам
«Я вам не скажу за всю Одессу» (с), но лично я не вижу, с чего бы вдруг.
> Как-то не очень вяжется с предыдущим заявлением.
Данные, которые попадают в блокчейн шифруются либо на ключе пользователя, либо на ключе сервера. Мы отсылаем информацию о привязках пользователей, чатов, каналов к серверам, чтобы сервера могли понимать куда отправлять сообщения. Информация о пользователе в открытом виде хранится только на его сервере. Сервер знает имя, телефон (если привязан), сообщения и (возможно) список контактов. Итого — вся информация хранится на сервере, часть — в блокчейне, но она зашифрована и другие сервера не смогут прочитать оттуда информацию.

> Как (при условии открытия исходников) вы можете гарантировать, что у моего собеседника версия клиента не собрана из исходников с вырезанной функцией блокировки скриншотов

Мы никак не можем это гарантировать. Более того, мы выкладываем исходники как раз для того, чтобы можно было собирать свои приложения и использовать их в нашей сети. Представьте что мы начали требовать какое-то разрешение, которое по вашему мнению нам не нужно — у вас есть опция собрать свой клиент без этого требования.

> Я что-то не очень понимаю, как при открытых исходниках можно ограничить возможность обновления сервера тем, кто не оплатил подписку.

Сразу оговорюсь, что монетизация еще не утверждена. Возможность обновления мы не запретим, но т.к. наш мессенджер поддерживает PUSH-уведомления и, как вариант, мы отправлять Push уведомления пользователям вашего сервера о том что вы используете нелицензированную версию. Если вы знакомы с серверной стороной работы Push, то вы знаете что для отправки уведомления нужны ключи. По понятным причинам мы не могли встраивать эти ключи в распространяемые сервера, поэтому отправкой push-уведомлений неподключенным клиентам занимается наш сервис. Чтобы без потерь по функционалу перестать платить нам за подписку вам придется не только выпилить код из сервера, но и выпустить свой клиент, при этом потеряв возможность общения между серверами. В принципе, задача решаемая, но выгода от такого действия сомнительна.

Если лицензия MIT, то сообщение об использовании нелицензионной версии ложно.

(Как и в GPL.) Точнее могут быть ложными. Вам никто не мешает говорить «каждую новую версию нашего открытого ПО вы должны покупать», но нельзя запретить получить исходники бесплатно от того, кто заплатил.
Данные, которые попадают в блокчейн шифруются либо на ключе пользователя
Вопрос: зачем?
Обычный пользователь с вероятностью «пять девяток» не будет бакапить свой ключ. И при краже/потере/поломке смартфона с клиентом этот ключ пропадёт. Какой ему толк от того, что «информация пользователя хранится в блокчейне», если он её не может достать (а если может достать без ключа — значит, и другие смогут)?

Мы никак не можем это гарантировать.
Однако при этом — заявляете.
Вы бы стали доверять человеку/компании, который/которая обещает что-то, что заведомо не может выполнить?

Сразу оговорюсь, что монетизация еще не утверждена
Ну вот и создаётся впечатление, что у вас самих нет видения:
  • того, кто будет пользоваться вашим мессенджером
    (у вас на сайте есть шикарный перл — «вы можете отправить оконечно зашифрованные сообщения и файлы, при этом, ваш собеседник не сможет сохранить себе… полученные зашифрованные данные… если на экране есть хотя бы одно зашифрованное сообщение» — кто тот пользователь, что отправляет бесполезные для собеседника файлы?)
  • почему кто-то будет менять свой/свои текущий/текущие мессенджеры на ваш (какая ваша «фишка»?)
  • за счет каких средств вы будете развиваться («Попробуем так, а может эдак, ну или ещё как-нибудь»)
Вопрос: зачем?

Чтобы можно было достать и расшифровать данные пользователя когда его сервер умер. Данные пользователя бэкапятся в блокчейн и при необходимости пользователь сможет их оттуда достать и «переехать» без потерь на новый сервер.

Однако при этом — заявляете.
Вы бы стали доверять человеку/компании, который/которая обещает что-то, что заведомо не может выполнить?


Мы заявляем о том что предприняли все доступные нам средства для защиты данных пользователя. Мы ведь не можем стоять рядом с каждым вашим собеседником и следить чтобы он ничего не разболтал. Мы со своей стороны сделали многое для защиты сообщений, усложнили процесс слива данных настолько, насколько это возможно. Если у вас есть какие-то предложения, как сделать еще лучше — дайте знать, будем рады сделать.

… ваш собеседник не сможет сохранить себе… полученные зашифрованные данные… если на экране есть хотя бы одно зашифрованное сообщение» — кто тот пользователь, что отправляет бесполезные для собеседника файлы?

Речь идет о том что эти файлы открываются в приложении и не могут быть заскринены или пересланы. Вы отправляете фото своей кредитки своему другу и можете быть уверены что в нашем приложении ваш друг не может сохранить себе фотографию (файл на устройстве хранится в зашифрованном виде и расшифровывается только на время отображения), друг не сможет ни переслать, ни расшарить в другие приложения, ни заскринить. Только переписать руками или фотографировать другим телефоном, но закрыть это вне наших возможностей.

какая ваша «фишка»?

Наша «фишка» в человеческой безопасности. В комментариях уже неоднократно всплывала мысль что хардкорная безопасность обывателю не нужна. Ему там неудобно и сложно. Мы стараемся встать туда, где телеграмм и сингал уже не устраивают по безопасности, но bitmessage и tox слишком сложны для пользователя.
Вы отправляете фото своей кредитки своему другу и можете быть уверены что

… что я достаточно доверяю своему другу. А если не доверяю, то зачем я буду ему пересылать чувствительную информацию?
Чтобы можно было достать и расшифровать данные пользователя когда его сервер умер. Данные пользователя бэкапятся в блокчейн и при необходимости пользователь сможет их оттуда достать и «переехать» без потерь на новый сервер
На мой взгляд, обычный пользователь не будет заморачиваться с надёжным хранением ключа. При такой предпосылке утрата пользовательского устройства, на котором установлен мессенджер, приведет и к бесполезности «бакапа в блокчейн».
А если пользователь своё устройство не утрачивает — то данные прекрасно хранятся на этом устройстве, и «переезд на другой сервер» проблемой быть не должен.
Так зачем (кроме «потому что мы можем!» и «потому что блокчейн — это звучит гордо круто») класть в блокчейн зашифрованные пользовательским ключом данные?

Речь идет о том что эти файлы открываются в приложении и не могут быть заскринены или пересланы
На предыдущем допросе :) было установлено, что даже этого вы гарантировать не можете.
Так зачем обещать?
Допустим, Вася отправил Пете супер-пупер секретное сообщение в надежде, что его не заскриншотят. А у Пети — пересобранный клиент, и он и заскриншотил, и в интернет выложил. Что Вася подумает о ваших обещаниях, и о том, стоит ли вам доверять? Что он про вас расскажет Маше или, скажем, в этих ваших интернетах?

Вы отправляете фото своей кредитки своему другу и можете быть уверены что в нашем приложении ваш друг не может сохранить себе фотографию
Ок, представим себе другой пример. Я отправляю фото своей кредитки своему другу через ваш мессенджер, а следом файлик — «реферат_распечатать.odt». Ну у меня просто нет принтера, а у друга — есть. И тут "… ваш собеседник не сможет сохранить себе… полученные зашифрованные данные… если на экране есть хотя бы одно зашифрованное сообщение". Стану после такого я пользоваться вашим мессенджером?

Мы стараемся встать туда, где телеграмм и сингал уже не устраивают по безопасности, но bitmessage и tox слишком сложны для пользователя.
На какой размер аудитории рассчитываете?
На мой взгляд, обычный пользователь не будет заморачиваться с надёжным хранением ключа. При такой предпосылке утрата пользовательского устройства, на котором установлен мессенджер, приведет и к бесполезности «бакапа в блокчейн».

Согласен с тем что обычному пользователю сложно объяснить важность этих ключей и их надежного хранения, но двигатель внутреннего сгорания тоже когда-то был сложен, а сейчас все с ним успешно справляются. Сложные технологии становятся проще. Бэкап в блокчейн позволяет хранить любую конфиденциальную информацию, а не только переписки. Это может стать надежным хранилищем данных, о котором писал Tim Berners-Lee

На предыдущем допросе :) было установлено, что даже этого вы гарантировать не можете.
Так зачем обещать?
Допустим, Вася отправил Пете супер-пупер секретное сообщение в надежде, что его не заскриншотят. А у Пети — пересобранный клиент, и он и заскриншотил, и в интернет выложил. Что Вася подумает о ваших обещаниях, и о том, стоит ли вам доверять? Что он про вас расскажет Маше или, скажем, в этих ваших интернетах?


Мы говорим лишь о том что сделали в своем клиенте. Мы сделали все что в наших силах. Возможность обойти ограничения остается, но у пользователей есть интерес к этой функции. В отзывах к приложению сингала эта фукнция несколько раз упоминается.

Ок, представим себе другой пример. Я отправляю фото своей кредитки своему другу через ваш мессенджер, а следом файлик — «реферат_распечатать.odt». Ну у меня просто нет принтера, а у друга — есть.

Для передачи файла на печать эта функция не подходит. Либо нам нужно давать опцию отправителю «можно/нельзя открывать в сторонних приложениях» либо искать другие пути. Представьте другой кейс. Есть финансовая компания в которой сидит главный аналитик, пишет рекомендации и рядовым трейдерам. Трейдеры имеют соблазн слить аналитику в свой телеграмм-канал или в конкурирующую компанию. В этом случае мы помогаем и жизнь недобросовестного сотрудника становится несколько сложнее.

На какой размер аудитории рассчитываете?

На большое количество мелких серверов.
… двигатель внутреннего сгорания тоже когда-то был сложен, а сейчас все с ним успешно справляются. Сложные технологии становятся проще.
Двигатели внутреннего сгорания стали сложнее (инжекторы/турбонаддувы/электронное управление). Технологии не становятся проще вообще. Они становятся отработаннее/надежнее и поэтому проще для пользователя. И сложнее вообще.

Бэкап в блокчейн позволяет хранить любую конфиденциальную информацию, а не только переписки.
Позволяет. Я и не спорил. Вопрос был другой: зачем хранить в блокчейне информацию (тем более конфиденциальную)?

Я могу назвать минимум три довода против того, чтобы писать приватную пользовательскую информацию в блокчейн:
  • Это дополнительная потенциальная точка уязвимости для приватности пользовательских данных: развитие компьютеров неизбежно приведет к тому, что алгоритмы шифрования, нынче считающиеся надёжными, перестанут быть таковыми. И {непонятно зачем} записанная в блокчейн конфиденциальная информация станет доступной;
  • Это дополнительная потенциальная точка уязвимости для производительности: чтобы условный Вася мог хранить свою собственную информацию в блокчейне, кто-то для этого должен предоставить ему ресурсы. Если Вася — злоумышленник, он может начать забивать «модный-стильный-молодежный» блокчейн мусором (гы, пока писал комментарий, на хабре появился замечательный пример, как рядовые пользователи могут использовать мессенджер в качестве файлопомойки);
  • Для среднестатистического пользователя информация в блокчейне бесполезна: при утрате устройства информация она теряется;

А вот доводов «за» использование блокчейна (в данном применении) у меня нет. У вас они есть? Если да, то какие?

Мы говорим лишь о том что сделали в своем клиенте. Мы сделали все что в наших силах. Возможность обойти ограничения остается
Как это читаю лично я: «Дыра в заборе осталась, хозяевам участка выданы заявления об их безопасности; на убеждение хозяев участка потрачено 100500 ед. ресурсов»

у пользователей есть интерес к этой функции. В отзывах… эта фукнция несколько раз упоминается.
Вы уверены, что это «ваши» пользователи? Или планируете реализовывать хотелки всех подряд?

Есть финансовая компания в которой сидит главный аналитик, пишет рекомендации и рядовым трейдерам. Трейдеры имеют соблазн слить аналитику в свой телеграмм-канал или в конкурирующую компанию. В этом случае мы помогаем и жизнь недобросовестного сотрудника становится несколько сложнее.
Ваш способ не решает задачу ограничения распространения информации. Вы потратили ресурсы на создание видимости.
Чтобы без потерь по функционалу перестать платить нам за подписку вам придется не только выпилить код из сервера, но и выпустить свой клиент, при этом потеряв возможность общения между серверами.

???
Можно с этого места поподробнее? Почему это вдруг автор альтернативного сервера теряет возможность общения между серверами, если протокол открыт? И почему он вдруг потеряет в функциональности, если как вы утверждаете код сервера открыт?


В принципе, задача решаемая, но выгода от такого действия сомнительна.

Эм, выгода как минимум в перетягивании клиентов на свой сервер. Что-то я не понимаю вашу модель монетизации. Или вы всё же реализуете в какой-то форме вендорлок, чтобы принудить юзеров платить, и тогда вашему мессенджеру дорога туда же, куда и десяткам вендорлокнутых мессенджеров до вас. Или, предположим, вы действительно реализовали идеальный протокол, открыли клиент, сервер. Что тогда мешает клиентам перейти на форк вашего сервера, где не надо ничего никому платить? Вы так уверены, что форков не будет?

И почему он вдруг потеряет в функциональности, если как вы утверждаете код сервера открыт?

Upd: Этот вопрос снимается, невнимательно читал

Почему это вдруг автор альтернативного сервера теряет возможность общения между серверами, если протокол открыт?

Владельцу альтернативного сервера будет проблематично подключаться к оригинальным серверам, т.к. он не будет иметь необходимой подписи, которую мы выдаем при лицензировании и оригинальные сервера будут отвергать такой коннект. Альтернативному серверу придется создавать свою сеть альтернативных серверов.

Что тогда мешает клиентам перейти на форк вашего сервера, где не надо ничего никому платить?

Ничего не помешает. Нужно сделать форк сервера и клиентов под этот сервер. Будет новый мессенджер на основе нашего. Если он будет популярнее оригинального — хорошо. Это не исключено. В этом случае мы обновим свои CV и пойдем искать работу :)

Коллеги, а взлетел хоть один p2p мессенджер в современности, напомните? Ну, типа как раньше Скайп, с его супернодами?

В Гонконге во время недавних событий какие только не использовались. Массово не взлетел ни один, ибо не удобно.

А что было плохо? Медленно? Списка контактов не было? Не знаете, проводил кто анализ?

Под «массово» я имел в виду глобально.
а взлетел хоть один p2p мессенджер в современности, напомните?
Jami and Briar — но низенько-низенько.
А вот FireChat сдох, хотя его материнская глагна жива, но страница именно про этот проект — 404.

Tox вполне юзабелен, но не очнеь распространён.

У tox проблема в том, что обычный пользователь его не осилит.

Не согласен, при переходе на удаленку пробовали Tox — нормально среднестатистический офисный работник его "осиливает", кстати в нашем случае звук был лучше, чем у Skype (ну скайпом вообще сейчас пользоваться невозможно, что стоит только отсуствие возможности отключить обновления).
Хотя в конечном итоге остаовились на WattsApp.

Последний раз, когда я попытался попробовать Tox, он хотел использовать закрытые в офисе порты и не было никакой возможности заставить его работать по 80 или 443.


Если сегодня клиент просто скачивается с плеймаркета и работает, как клиент вацапа или телеграма, то значит это повод еще раз на него посмотреть.


Какой клиент, кстати, использовали?

Про порты не знаю, мы пользовали на телефоне для аудио на личном интернете (удаленка), для текста и файлов были другие средства.
Antox.
У нас не p2p. У нас децентрализация по типу федерализации. Сеть создают сервера, а пользователи подключаются к этим серверам. Сервера обмениваются информацией друг с другом и позволяют реализовать поиск контактов, общение между пользователями разных серверов.
Бессмысленно. Сервер = точка отказа/перехвата коммуникаций. В этом плане (невзирая на модный нынче блокчейн) ваше предложение пока лишено смысла.
При желании можете сделать сервер на ноутбуке у себя дома / в офисе. Перехват коммуникации исключен надежным шифрованием. Посмотрите на второй слой шифрования — «Шифрование данных в канале связи» в нашей документации
У p2p проблема с мобильными клиентами. Допустим Tox на андроид жрёт батарейку/трафик и это не победить т.к. полный клиент обязан выполнять все функции т.е. участвовать в жизни сети пересылая чужие пакеты. В данном случае теоретически есть шанс на повторение успеха скайпа т.к. присутствуют промежуточные сервера и мобильные клиенты могут расслабиться. Полетит оно или нет очень сильно зависит от сложности настроек и общей организации сети.

А вот стартовать в космос подобный мессенджер может только если в какой-то стране закрутят гайки в отношении уже существующих лидеров и этот окажется удобной альтернативой.

Впрочем есть сомнения. Они делают сквозное шифрование опциональным. Наверняка будут проблемы с одновременным доступом нескольких клиентов. Их мечты на монетизацию через push тоже сомнительны т.к. мелкие транзакции убыточны, а платить ощутимые деньги за то что можно взять бесплатно много людей не захотят. И это мы ещё не коснулись административного давления за запрещённый контент. В сети появятся плохие фотографии, музыка, видео и клиенты начнут выпиливать из магазинов приложений.
Я бы роль сервера (суперноды) перекладывал, допустим, на десктопный клиент. Ну, если уж проектировать. Либо, допустим, на андроид-клиент, находящийся на зарядке (трафик нынче дёшев, а вот батарея — не очень). С весами, в зависимости от мощности хоста.
А тут — почему я должен доверять выделенному серверу?

Не совсем понятна архитектура приложения. Что будет децентрализованно, что хранится только на копии сервера, что на центральной системе. Ну и согласен с предыдущим комментарием, говорите про открытость, но пока есть только собранный докер и приложение в Google play.

Схему хранения данных и исходный код готовим к публикации. Опубликуем на гитхабе в ближайшее время.
Мы в своей реализации решили проблемы этого протокола. Поиск контактов в Jabber сложно назвать рабочим. Передать файл, защищенный оконечным шифрованием быть может и возможно, но далеко не каждый клиент это позволяет. Push-уведомления важны для пользователей, но их ввели только в феврале 2020 и неясно когда он дойдет до конечного пользователя. Jabber был хорош, но он значительно уступает современным мессенджерам по функционалу.
Поиск контактов в Jabber сложно назвать рабочим

Интересна ваша реализация. Какова она? Jabber в полне решил эту проблему.
Передать файл, защищенный оконечным шифрованием быть может и возможно, но далеко не каждый клиент это позволяет.

Как и с вашим мессенджером будет. Ведь вы даете возможность создавать собственные клиенты.
Jabber был хорош, но он значительно уступает современным мессенджерам по функционалу.

Протокол Jabber таков, что через него можно реализовать всё (совершенно всё), что хочешь. Более того, поверх этого протокола можно и шифрование ввести, если использовать собственную реализацию клиента.
Интересна ваша реализация. Какова она? Jabber в полне решил эту проблему.

Настоящие данные пользователя знает только сервер пользователя. Когда пользователь (А) отправляет запрос на поиск другого участника по телефону / имени и т.д., сервер пользователя А ищет подходящие контакты и среди своих пользователей, и параллельно отправляет запросы к другим серверам, чтобы те тоже искали подходящих пользователей. Каждый сервер ищет только среди своих юзеров. Сперва выполняется обычная выборка из СУБД, затем происходит фильтрация результатов поиска на предмет определения доступа пользователя А к данным по которым нашелся другой пользователь (Б). Например, искали по номеру телефона, но пользователь Б закрыл доступ к телефону своими настройками. Б выбывает из итоговой выборки. Сервер пользователя А ожидает ответы от других серверов и отдает итоговую выборку на клиент.

Остается нюанс с тем что если сервер интересующего вас пользователя недоступен, то вы его не найдете. Пока так. Сохранять телефоны/имена/почты в публичном виде мы не хотим, это нарушает безопасность и создает угрозу злоупотребления.

Из вашего коммента так и не понятно, в чём проблема поиска юзернейма в jabber.


Единственное, что jabber ищет только в пределах одного сервера (точнее, XEP-0055 просто не говорит ничего о том, из каких данных сервер формирует ответ), но я бы не назвал это недостатком. В токсе вообще поиска контактов нет как такового, собеседник должен вам напрямую выдать свои контактные данные, и это даже лучше (проще, секьюрнее).

У нас можно искать между серверами, а также можно полностью скрыть свои данные и давать своим друзьям ID через QR-код (практически как в Tox).

Мне кажется, было бы неплохо добавить в статью сравнение с другими существующими децентрализованными мессенджерами, как минимум:



Чем ваш проект лучше уже существующих?
Что мотивировало вас его начать делать новый мессенджер, а не вкладываться в один из существующих (ну, кроме желания заработать)? Что заставляет вас верить, что ваш проект сможет решить проблемы, которые не смогли решить существующие децентрализованные мессенджеры (в первую очередь — найти свою аудиторию)?

В двух словах — он юзабельнее. Вместо p2p мы используем федерализацию, при которой клиенты подключаются к серверу (как в jabber / jami). Вместо хранения всего в классической СУБД, часть информации мы шифруем и сбрасываем в блокчейн, чтобы при сбое можно было восстановить эту информацию. Вместо хранения всего в блокчейне (включая сообщения) мы используем связку классических СУБД и блокчейна, чтобы сообщения доходили сразу, а не дожидались генерации блока. С одной стороны есть небезопасные, но удобные системы, с другой безопасные, но с которыми рядовой человек не разберется. Мы постарались встать по-середине.

Пользователь намертво привязан к серверу или есть возможность миграции между серверами прозрачно для него и его контактов?

Миграция пользователей между серверами возможна, требует лишь подтверждения от администратора сервера, куда перемещается клиент.
Есть прекрасный открытый мессенджер: github.com/tinode/chat

Концепция децентрализованной федеративной сети.
Есть личный опыт использования?
Несколько лет назад в познавательных целях.
Понравилась реализация привязки телефона. Это отдельный необязательный «тег» у контакта.
Полностью открытая платформа, код аккуратный и легко читаемый.

Сам по себе малоперспективный. Имеет смысл для IT специалистов как альтернатива телеге.

Из перспективных и интересных стоит обратить внимание на Delta Chat. Мессенджера, использующего email в качестве транспорта вместо собственных серверов.
Я уверен что подобных сервисов на гитхабе не один десяток, разной степени готовности. Чатботов у нас еще нет, наш проект еще молод для этого, но давайте пройдемся по пунктам раздела «Planned» проекта Tinode:
1. Федерализация. У нас готова. Есть куда дорабатывать, но уже сейчас сеть функционирует.
2. End to end шифрование. У нас готово, работает.
3. Групповые чаты без ограничения клиентов. Нет никакой проблемы отправить сообщение в чат на миллион пользователей. Сервер отвечает отправителю как только он сохраняет запись о сообщении в БД. Отправка сообщений выполняется асинхронно, не блокируя работу сервера. Поэтому, что чат на троих, что на миллион, у пользователя нет с этим проблем.
4. Не могу понять что имеется ввиду под «Hot standby». Может вы поможете?
5. Настройки срока хранения сообщений у нас пока нет. Есть настройка сохранения оконечно зашифрованных сообщений на сервере и TTL для всех сообщений.

Конкуренция всегда хорошо.
Tinode давно развивается. Ребята всерьез настроены заменить им протокол XMPP.

Т.е. по сути преследуют другую цель.
4. Не могу понять что имеется ввиду под «Hot standby». Может вы поможете?

Наверняка кластер с горячим переключением на запасной сервер при недоступности мастера.

Положим миллиона пользователей у Вас нет. Не будет ли все это тормозить в стиле скайпа пятилетней давности никто не знает. Обеспечение высокой нагрузки это отдельная тема и я пока не верю что действительно любая необкатанная (не только Ваша) система может эти миллионы выдержать.

Наша сеть федерализирована. Каждый владелец сервера запускает сервер, в первую очередь, «для своих», а затем уже думает давать или нет в паблик. Не ожидаю что будет много серверов с нагрузкой по миллиону пользователей одновременно. Нам больше видится множество «мелких» точек, которые создают общую сеть. Мы работаем над автоматической балансировкой сети, чтобы можно было пользователей безопасно перебрасывать на другой, более свободный и лучше расположенный сервер. Ожидаем что это значительно повысит отказоустойчивость серверов с сети в целом.

А сценарий, что каждый поднимет себе сервер ложится в вашу модель? Вот я, например, если захочу попробовать ваш мессенджер, буду поднимать свой сервер. И вряд ли там будет хоть ещё один пользователь.

Да, наилучшим образом. Вы можете общаться с остальными, вы будете владельцем своих данных. Ни ваш сервер, ни остальные, не почувствуют проблем с тем что на вашем сервера вы один. Мы так и задумывали что сервера будут создаваться под небольшие команды.

У автора уже спросили достаточно. Мой вопрос иной.
Каким образом вы полагаете сражаться с государством в части исполнения 149-ФЗ, в частности статьи 10?
Будет ли каждый участник пиринговой сети рассматриваться как распространитель информации?
«Сражаться» с государствами мы не планируем, наша зона ответственности ограничивается разработкой ПО. Все что касается эксплуатации — дело владельца отдельного сервера. Серверное приложение обладает десятками параметров, позволяющее настроить его работу под разные законы.
Конкретно по вашему вопросу: пункт 9 статьи 2 этого же закона говорит что распространение = «получение информации неопределенным кругом лиц». Настройки сервера позволяют ограничить свободную регистрацию, а также создавать приватные групповые чаты и каналы. В этом случае участник сети не будет распространителем информации.
UPD: опубликован исходный код:
Server (c#, .netCore 2.2): github.com/Ymessenger/ymessenger
Android (Kotlin): github.com/Ymessenger/android-app
Sign up to leave a comment.

Articles

Change theme settings