Pull to refresh

Comments 225

А потом придёт ФСБ и попросит предоставить ключи шифрования для сообщений, передаваемых через P2P.
и что? мир он большой, в нем больше чем одно государство.
А потом придёт ФСБ и попросит
К кому это оно придёт? К каждому из миллиона пользователей? Замучается приходить.
Впрочем… Если процесс будет развиваться как сейчас, то общество разделится на две примерно равных части: одни будут приходить, к другим будут приходить. Вот тогда удастся охватить всех.
… причём если продолжить мою мысль из поста — я же не предлагал это делать именно телеграмму (хотя они сейчас быстрее всего развиваются) могут и vk сделать аналогичное или любой другой мессенджер…
вк под мэйл ру на п2п?.. очень смешно
если это им обеспечит храенение и передачу информации куданадо, то не удивлюсь. p2p может обеспечить приватность/анонимность, а может и не обеспечивать, всё на усмотрение создателя приложения.
если это им обеспечит храенение и передачу информации куданадо


полагаете вк или майл.ру не хватает своих ресурсов настолько что они заморочаться на п2п?
предполагаю, что экономия никому еще не мешала, вот налоговая перестает слать письма почтой при перво заходе в их ЛК — это экономия, я не думаю что у налоговой нет денег на почту…
предполагаю, что экономия никому еще не мешала, вот налоговая перестает слать письма почтой при перво заходе в их ЛК — это экономия, я не думаю что у налоговой нет денег на почту…


Когда Дуров продал ВК фирме Майл.Ру — он не продал датацентр, железо, сервера.
Видимо, Майл.Ру, также как и вы, поначалу считала, что сэкономила.
И начала Майл.Ру постепенно переезжать, но при этом продолжала платить Дурову за сервера арендную плату.
Год вроде фирма Майл.Ру пыталась это сделать… Как впоследствии оказалось — безуспешно.
Ибо в в конечном итоге решила фирма Майл.Ру, что дешевле будет выкупить датацентр вКонтакте со всем железом, чем менять базис, на котором основан сервис вКонтакте.
Так Дуров дважды продал вКонтакте фирме Майл.Ру.
«Продал» — я бы писал в данном случае курсивом и в кавычках.

К каждому не надо, достаточно прийти к паре сотен (в месяц), посадить лет на восемь за измену родине и раструбить в СМИ, остальные забоятся.
shifttstas прав, конечно, государств много, но вам это вряд ли поможет — не будете же вы менять государство из-за какого-то мессенджера, если до сих пор всё устраивало.

Такие случаи с VK раз в неделю происходят, сильно аудитория упала?

Какие именно случаи? Сажают на восемь лет? Я не в курсе, VK не пользуюсь, поясните, пожалуйста.

Да, за картинку в личном, закрытом альбоме например (из свежего)

Очень интересно.
Мне казалось, это такая cамодеятельность служивых людей на местах, проявления палочной системы и сведение личных счётов, а соответствующего госзаказа нет.


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


Не могли бы вы дать пару ссылок на тексты решений судов?

Спасибо.
Тут подробней: graniru.org/Society/Law/m.261472.html
Прения только начались, решения ещё нет, судят даже не случайного человека лайкнувшего мемасик, а активистку, так что меня это не коснётся, я же не оппозиционер.
Именно. Теперь если вам предложат стать оппозиционером, вы будете знать, что с оппозиционерами такое бывает, а с людьми, которых устраивает власть — нет.
Кто предложит? Госдеп? А денег много предложат?
И то, что она не просто мимопроходил, а активистка Артподготовки — ничего не значит?

Нет, ничего не значит. Если сбил ребёнка на переходе — ничего не значит последователь ли ты Навального или племянник прокурора. Ну, при нормальной судебной системе не значит. А при имеющей место быть пародии, конечно же значит, увы…

Странно считать нормальным, что к кому-то закон «в большей степени применим». Одно дело — законы, которые ограничивают деятельность каких-то оппозиционных организаций (хотя это тоже зло, но хотя бы очевидное), и другое — когда мне можно устраивать дома дискотеки до утра, потому что я лояльный, а соседу Васе после 22.00 нельзя и с женой поругаться, потому что он в оппозиции.

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


И даже если вы считаете себя "неуловимым джо" — вы или ваши близкие можете быть на её месте. Ну знаете "Сначала они пришли...", да?

Надо отдавать себе отчёт в том, что нельзя прослыть участником подробной группировки и не привлечь к себе внимания. Сначала ее взяли по подозрению к причастности, потом начали разрабатывать, изъяли комп, стали на нем шарить и искать — за что можно присадить. Все органы так поступают, Аль Капоне посадили на да убийства, а за то, что смогли найти.
Именно это, и не только для рф, мотивирует изначально пилить открытый протокол с динамическими сессионными ключами для каждого пользователя индивидуально.

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

Серверов тоже нет — точки давления в сети просто нет, не на что надавить, нечего блокировать, нечем пугать.

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

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

А система доставки подписанного кода давно и хорошо проработана — весь софт подписывается ключами, которые автоматически проверяются при установке, а для параноиков всегда есть возможность все собирать самому

От постоянной передачи по блютусу\вайфаю телефоны и полдня не проживут. Но идея мне нравится.

Готов с вами поспорить, у меня постоянно включен Bluetooth — наушники, и Wi-Fi — который используется дома, на работе и в метро. К моменту возврата домой у меня остается 25-32% заряда. Очевидно, что Mesh будет добавлять нагрузку, с другой стороны — вы не будете тратить электричество на прожорливый 3G/4G модем, который кушает больше чем Wi-Fi/Bluetooth
Нееет, это так не работает. Это значит, что Вы будете тратить электричество не только на прожорливый модем, но и на вайфай с блютусом.

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

Но энергия будет тратится не только на загрузку контента, но и еще на его раздачу.
Будет, по этому я и говорю — точно не понятно каков будет итог, даже если это будет тратить дополнительные 5% аккумулятора то я буду не против.

Вряд ли 5%.
Попробуйте включить на телефоне хотспот и посмотреть через него фильм, да ещё тремя устройствами сразу — часа через три сядет. Лопата — через четыре.

Хотспот — плохой пример, телефон вещает по wi-fi на максимальной мощности + 4G модем, я тестировал FireChat- копейки кушает.

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

Модем ожидающий звонок потребляет значительно меньше, чем в состоянии активности.

Давайте возьмем конкретный пример. Телеграм в фоне обновляет ленты переодически, так он это делает через модем, переводя его в активное состояние и потребляя энергию (прямо пропорционально удаленности БС кстати говоря) в случае с wi-fi — мы гарантировано взаимодействует с ближайшим устройством не включая модем.
Хорошо, давайте проведём конкретный тест: откроем на телефоне веб-сервер (их полно в аппсторах даже для айфона, например, вот), подключимся к точке доступа и будем каждые две минуты с десятка разных устройств скачивать файлик на пару мегабайт.
Мне даже стало интересно, я бы проверил.
FireChat не вчера появился и сейчас его авторы пилят интернет на базе mesh-сети из устройств пользователей.
Я знаю, я собственно и описываю интеграцию FireChat в популярные мессенджеры. Проблема FireChat (как и любого Mesh решения) — для его работы нужно много людей. У мессегджеров аудитория уже есть. А на firechat никто только ради Mesh переходить не будет.
Еще опишу пару кейсов, которые я себе вижу при Mesh мессенджере:
1. Простое добавление в группу/чат/канал людей (Например вы — студент или родитель на собрании или турист в группе и гид/учитель/староста создал чат, вместо муторного сканирования QR кодов/шаринга ссылки — можно просто поставить опцию — сделать чет видимым рядом находящимся на N минут — и все его увидят сразу)

2. Простая отправка файла/чат с соседом — у Apple файлы могут быть отправлены через AirDrop, ровно такой же принцип только для обычного чата (кейс — надо что-то передать по быстрому с ранее не известным человеком, открываем видимость себя в настройках и оп — второй человек видит в списке вас и отправляет вам всё что надо) дополнительным бонусом идет не раскрытие номера телефона

3. Помощь с доступом чащего всего, Wi-Fi в мире, безлимитный по объему трафика, почему бы мессенджеру не предоставить возможность работать через другой телефон который подключен к wi-fi сети (Кейс — вы заграницей и у вас не работает интернет, но рядом есть пользователь с подключением по wi-fi к своей домашней сети — можно подключится к серверам мессенджера в урезанном варианте — например передача только текста, без мультимедия) по идее никого из этой схемы ни за что привлечь нельзя, доступа в интернет как таковой — нет, только к мессенджеру.
Вы поддерживаете идею Mesh сети из вашего мессенджера?
Да, я поддержу любую фичу, которая будет не по зубам Роскомнадзору.
И все мои соседи будут знать, что я читаю и с кем общаюсь? Спасибо, не надо
Не обязательно, можно сделать так, что бы не знали. С другой стороны, соседи будут знать не с кем вы общаетесь, а с что читает id:1372728373637 с сигналом 15% рядом с ними.
Звучит как вектор для деанона. Ага, id:1372728373637 читает лентач/медузу/что_то_еще, запишем в оппозиционеры, придет день Д и час Ч, можно будет прийти к нему. На третьем этаже 15%, на четвертом 45%, а на пятом все 75%, значит наш пациент где-то тут.
Сейчас это можно сделать через СОРМ
Как только вы зайдете в вагон, приложение соединится с аналогичным приложением и начнет обновлять контент через него.

Через что соединится-то?

Через Wi-Fi и/или Bluetooth, аналогичный пример приведёт в посте и комментариях (FireChat)

То есть вместо двух соединений (одно по BT с моими наушниками, и второе по соте) телефону придется держать минимум четыре (потому что чтобы была сеть, нужно, чтобы каждое устройство держало как минимум два соединения), два из них — с недоверенными устройствами, и постоянно прокачивать через себя чужой трафик? Спасибо, но нет, и батарейка не вечная, и безопасность моя мне дороже.

Собственно в посте я и рассматриваю то, что на безопасность это не повлияет от слова совсем. Единственное что может быть видно соседям (если не сильно усложнять алгоритм, хотя можно и скрыть) — на какой контент вы подписаны (каналы) — не более. Фактически это сейчас знает любой ваш интернет провайдер (при отсутствии VPN)
Собственно в посте я и рассматриваю то, что на безопасность это не повлияет от слова совсем.

Да разве? У вас есть гарантия, что P2P соединение двух устройств не дает поверхности для атаки?


Единственное что может быть видно соседям (если не сильно усложнять алгоритм, хотя можно и скрыть) — на какой контент вы подписаны (каналы) — не более.

Для начала, им видно то сетевое соединение, через которое они с вами соединились.

Какую атаку вы можете придумать, если есть общая сеть к которой имеет доступ только конкретное приложение с обеих сторон, протокол жестко сертифицирован Google/Apple и приложения сидят в песочнице?

Тут не понятия сетевое соединение, вы вещаете в эфир на общем канале — не более, что то типа wi-fi ad-hoc
Какую атаку вы можете придумать, если есть общая сеть к которой имеет доступ только конкретное приложение с обеих сторон, протокол жестко сертифицирован Google/Apple и приложения сидят в песочнице?

Например, обнаружение устройства в радиусе — это раскрытие приватности. И это не считая атак на сам протокол и "конкретное приложение".


протокол жестко сертифицирован Google/Apple

Напомните название протокола, пожалуйста.

Ваше устройство и так можно обнаружить при включённом wi-fi/bluetooth

Со стороны Apple — multipeer connectivity framework, со стороны Гугл так быстро подсказать не смогу.
Ваше устройство и так можно обнаружить при включённом wi-fi/bluetooth

… которые я могу и не включать, потому что они далеко не всегда мне нужны (ну и про обнаружение незапаренного блютуса за разумное время тоже вопрос интересный, да ну ладно).


Со стороны Apple — multipeer connectivity framework, со стороны Гугл так быстро подсказать не смогу.

… самое смешное начнется, когда вам понадобится говорить между этими системами.


И это мы еще не начали рассматривать атаки на само приложение, пока только на стек смотрим.

… которые я могу и не включать, потому что они далеко не всегда мне нужны (ну и про обнаружение незапаренного блютуса за разумное время тоже вопрос интересный, да ну ладно).


Bluetooth — по BLE протоколу, при Wi-Fi — создать сеть к которой вы заведомо были подключены — MT_FREE например. При подключении к фейковой сети вы передадите свой настоящий Mac адрес

… самое смешное начнется, когда вам понадобится говорить между этими системами.

И это мы еще не начали рассматривать атаки на само приложение, пока только на стек смотрим.


Все верно, вот телеграм решили свой протокол придумать и ничего — живут как-то, так что вопрос дырявости протокола обычно пропорционален его зрелости. (если ничего не делать то ничего и не будет)
Bluetooth — по BLE протоколу,

Который у меня включен? Нет.


при Wi-Fi — создать сеть к которой вы заведомо были подключены — MT_FREE например.

… но не был же. Подключен, в смысле, не был.


так что вопрос дырявости протокола обычно пропорционален его зрелости

А поскольку протокол новый, степень защищенности вы — по сравнению со зрелым протоколом — понизили. О чем и речь.

Если мы берем конкретно вас, как вы написали выше — у вас отключен wifi/bluetooth -> mesh сеть с вами работать не будет, вы будете так же получать контент с сервера.

Я же не предлагаю использовать только её, я предлагаю дополнительно использовать её.
Я же не предлагаю использовать только её, я предлагаю дополнительно использовать её

В этот момент повышая степень своей уязвимости. Я об этом и говорю.

Включая радио интерфейсы — вы понижаете степень защищенности, подключаясь к обще известным wi-fi тоже, я уверен, что если взять TOP 100 wifi сетей, хоть к одной — вы подключитесь => защищенности нет

Не "нет защищенности", а "защищенность понижается". Вы утверждаете, что ваше решение ее не понижает. Это не так.

только как имнно понижается мы так и не решили, если mac не раскрывается, читаете ли вы тот контент который у вас запросили или вы просто его пересылаете — не известно
только как имнно понижается мы так и не решили

Выше по треду. Вы пока что не показали характеристики защищенности предлагаемых вами протоколов (а на multipeer, например, была — закрытая уже — атака, позволявшая понизить на нем уровень шифрования и сделать MITM).

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

Так не работает. Система небезопасна, пока не доказано обратное.

Где конкретно?
Раскрытия отправителя/получателя — нет
Определения кто источник а кто промежуточное звено — нет

С тем же успехом можно сказать, что tor/i2p небезопасны. хотя метод работы схож
Раскрытия отправителя/получателя — нет

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

Зачем вам идентифицировать устройство к которому вы подключились? опять же говорю, есть протоколы tor/i2p/cjdns — они прекрасно работают и разрабатывались при главное условии — промежуточные узлы это MITM атака по умолчанию.
Зачем вам идентифицировать устройство к которому вы подключились?

Чтобы отслеживать, где еще оно появляется.

единственное что вы знаете об устройстве — соседе: уровень сигнала и временный mac адрес который будет изменен через некоторое время

У вас есть основания утверждать, что реализация multipeer у Apple не раскрывает больше информации об устройстве?

У меня есть wireshark, кроме того, протокол от apple — мы взяли как пример (концепт) реализации таковой сети.

Никто не мешает сделать как сделал telegram — не брать openwhisper протокол, а сделать свой — mtproto и героически исправлять в нем ошибки.
Никто не мешает сделать как сделал telegram — не брать openwhisper протокол, а сделать свой

Свой протокол соединения двух устройств разных поставщиков? А где вы доступ к железу-то получите? И откуда после этого возьмется обещанное вами выше "протокол жестко сертифицирован Google/Apple"?

Так есть два стула — или мы берем вендорский протокол и живем с ограничениями вендора, доверяя ему сторону безпасности, или же делаем свой велосипед (mtproto) который может быть, например, мультивендорным.
или же делаем свой велосипед (mtproto) который может быть, например, мультивендорным.

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

Тут может быть вопрос только к Apple, не вкурсе какие у них сейчас ограничения по доступу к модулю wi-fi, android/pc/mac/linux — режим работы карты в adhoc+/infrastructure и далее уже делаем все что угодно.
android/pc/mac/linux — режим работы карты в adhoc+/infrastructure и далее уже делаем все что угодно.

"Все, что угодно" — это прекрасное начало для атаки.

Есть стандартные mesh протоколы, включая сертифицированный из семейства 802, «Все, что угодно» " — я подчеркнул, что мы не ограничены стандартными протоколами, как я выше написал, можно использовать или их или же свой, но с риском уязвимостей.
Есть стандартные mesh протоколы, включая сертифицированный из семейства 802

Сертифицированный на что конкретно? Каждый раз, когда мы берем "стандартный протокол", надо точно понимать, какие гарантии он дает.

ru.m.wikipedia.org/wiki/IEEE_802.11s
Вот пример о котором я говорю, если же говорит о недоверии стандарту 802.х — дальше обсуждать вообще глупо.
defining how wireless devices can interconnect to create a WLAN mesh network, which may be used for relatively fixed (not mobile) topologies

Уже забавно, да?


А дальше пойнт в том, что (а) нигде не сказано, что это стандарт для анонимных сетей (более того, там больше одного раза упоминаются стандарты аутентификации) и (б) выглядит так, как если бы мы получали обычную TCP/IP сеть в результате, т.е. возвращаемся к началу и поверхности атаки.


Так что дело не в том, чтобы "не доверять стандарту", пойнт в том, чтобы знать, что именно этот стандарт гарантирует.

он должен быть не анонимным а приватным

Если он не будет анонимным, можно будет отслеживать перемещения устройства.


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

я уже выше приводил пример, при mac randoimization вы остаетесь анонимным через определенный промежуток времени.

Приватность — тоже был приведет пример доступа не напрямую к источнику, а через посредника.
я уже выше приводил пример, при mac randoimization вы остаетесь анонимным через определенный промежуток времени.

Вот только (а) не показано, что в этом стандарте работает mac randomization и (б) не показано, что в этом стандарте нет других идентифицирующих узел признаков.


Приватность — тоже был приведет пример доступа не напрямую к источнику, а через посредника.

У вас свое понимание приватности применительно к сетям, не совпадающее с моим.

Рандомизация маков — на усмотрениям вендора как бы…

Что как бы говорит нам, что следование этому стандарту никакой анонимности не гарантирует.

хоть к одной — вы подключитесь => защищенности нет
То есть, есть только два уровня безопасности: High и нехай?
на какой контент вы подписаны

Именно это лично мне и не нравится, например


Фактически это сейчас знает любой ваш интернет провайдер

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

Вы ошибаетесь, HTTPS — скрывает конкретный контент, но известен домен, и IP. + через DNS можно выяснить.

Ваш провайдер не узнает что вы написали, но он знает что вы заходили на домен habrahabr.ru, собственно при описанном мной сценарии будет ровно то же самое.
Но он не знает, что именно я на хабре читаю, так что ошибаетесь всё-таки вы. А в вашем сценарии, чтобы получить картинку с не очень приличной поней с соседнего устройства, нужно будет запросить именно эту картинку — тогда и сосед узнает, что я интересуюсь понями (приличными, но мало ли что в ленту попадёт), и я узнаю о соседе, что он интересуется понями, иначе бы картинка с поней на его устройстве не лежала бы. Потом по MAC-адресу, уровню и направлению сигнала и прочим косвенным признакам деанонимизируем соседа и красим ему морду IRL )
Для начала давайте вопрос — как вы собираетесь соотнести MAC адрес с конкретным человеком, при условии, что телефон при отсутствии подключения к Wi-Fi сети его меняет раз в некоторое количество минут?
А при наличии подключения к Wi-Fi используется единственный конкретный MAC. А измерение уровня сигнала тоже никто не отменял
У вас с соседом нет подключения между собой (такого при котором посылается настоящий мак client —> infrastructure) у вас adhoc/p2p

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

+ опять же, я в посте упоминал, что это самый простой вариант реализации, никто не мешает использовать функцию раздачи только при наличии 3 и более пиров, таким образом кто именно любит поней — вам будет не известно.
у вас adhoc/p2p

Ладно, тут я матчасти не знаю


Вы сможете сказать, что только в том направлении любитель поней с маком ххх.

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


никто не мешает использовать функцию раздачи только при наличии 3 и более пиров, таким образом кто именно любит поней — вам будет не известно

Возможно, я тупой, но не понял, как из первой части предложения следует вторая часть

Пример:
Мы с вами едем в одном вагоне в метро, так же в метро с нами едут ещё 5 пользователей мессенджера.

Предположим, я решил скачать контент (поней) который есть у вас, а вы планируете меня вычислить.

Цифры — номера других людей которые вообще не подписаны на поней.
Пони могут передаваться так:
Вы ->3–>2->5 -> я
Или так
Вы -> 2 -> 5 -> я
Или в любой последовательности когда между мной и вами — случайные люди, которые выполняют роль пересылки. Таким образом вы знаете, что пони пришли с пользователя 1 но вы не знаете подписан ли он на поней или просто передал их. Точно так же работает Tor/i2p

А, ну если как в Tor/i2p, тогда может быть. Наверно, здесь ещё есть что закритиковать, но у меня голова не варит и я пока воздержусь от продолжения ветки)

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

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

Не совсем так, подписки у 80% пользователей в рамках одного города обычно идентичны (проверяется на том же вконтакте) => с большой вероятностью контент передаваемый через устройство будет ему интересен
с большой вероятностью контент передаваемый через устройство будет ему интересен

И это как раз и означает, что мы вычислили его интересы. Здравствуй, раскрытие информации опять. А чтобы интересы нельзя было вычислить, придется скрывать реальный трафик в потоке мусорного — в обмен на многократное увеличение нагрузки, которого мобильное приложение себе позволить не может.

Как вы его вычеслите? я пример ниже привел. вы не знаете, источник контента заинтересован ли в нем или же просто переслал его вам.
Как вы его вычеслите?

Очень просто: тот, кто с меня читает — заинтересован.

нет, с вас может читать ближайшее к вам устройство, оно же просто прочитает контент и перешлёт его далее (тк у вас и у получателя, конечного, может вообще не быть прямой видимости)
нет, с вас может читать ближайшее к вам устройство, оно же просто прочитает контент и перешлёт его далее

Если ближайшее ко мне устройство читает с меня только один канал — для кого оно его читает?

Давайте конкретный пример.

Мы с вами едем в автобусе, я хочу прочитать у вас канал «Хабрахабр», мы оба подписаны на хабрахабр.

Но кроме нас с вами в автобусе еще 5 пользователей мессенджера который вообще не вкурсе про хабрахабр.

В итоге, я могу читать его так:
Я --> 2 --> 4 --> Вы
Я --> 1 --> 3 --> Вы

или же так (при этом номер 5 — тоже заинтересован в данном канале)
Я --> 2 --> 5 --> 3 --> Вы

Таким образом, не я не вы не знаете кому информация нужна, а кто её просто передаёт.
В итоге, я могу читать его так:
Я --> 2 --> 4 --> Вы
Я --> 1 --> 3 --> Вы

В этом примере 1, 2, 3 и 4 передают информацию, которая им вообще не нужна. Это нарушает ваш постулат "с большой вероятностью контент передаваемый через устройство будет ему интересен" (потому что мы только получили вероятность интереса 1/3).


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

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

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

Battery attack? =)

Интересно, что бы вы выбрали — моментальную загрузку 100 мегабайтного видео в метро (при наличии паразитного трафика, скажем, 500 мб) или же ожидание загрузки файла в 3 минуты но экономия 500 мегабайт трафика (деньги за трафик с вас конечно не берут, только % аккумулятора)
Battery attack?

Вообще-то еще и пропускная способность канала расходуется.


Интересно, что бы вы выбрали — моментальную загрузку 100 мегабайтного видео в метро (при наличии паразитного трафика, скажем, 500 мб) или же ожидание загрузки файла в 3 минуты но экономия 500 мегабайт трафика (деньги за трафик с вас конечно не берут, только % аккумулятора)

Ну вот смотрите, вы предлагаете мне думать, что файл в 100 мегабайт грузится три минуты. Сколько будет прокачиваться 500 мегабайт паразитного трафика? (это, напомню, 500 мб входящего трафика и 500 мб исходящего)? Если хотя бы пять минут (а я думаю, что больше), то нафиг такое, я потерял на этом видео больше аккумулятора, чем если бы я сам его скачивал.

Wi-Fi n/ac? достаточно иметь лимиты для отражения атаки + лимит на передачу файла, скажем не более 500мб. при скорости 100 мб/с 500 мегабайт будут передаватся менее минуты.

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

Это как с Bitcoin и любым blockchain — для верификации транзакций и постройки дерева тратится уйма электричества, но такова архитектура системы и она даёт свои плюсы, которые нельзя получить иным способом.
достаточно иметь лимиты для отражения атаки + лимит на передачу файла, скажем не более 500мб.

Ну вот видите, еще лимиты понадобились. А где лимиты, там и ограничение сервиса для потребителей, и в самый интересный момент кому-то не дадут.


при скорости 100 мб/с 500 мегабайт будут передаватся менее минуты.

… и какое энергопотребление у устройства в таком режиме? Вот, скажем, мой планшет, когда я на него файлы по wi-fi заливаю, сильно лучше держать включенным в сеть, иначе батарейка пробивает дно.


И еще раз, вы скорее всего будете больше тратить аккумулятора чем обычно

Я вам про это и говорю — прощай, эффективность.

Ну вот видите, еще лимиты понадобились. А где лимиты, там и ограничение сервиса для потребителей, и в самый интересный момент кому-то не дадут.


Так у любого сервиса есть лимит, у телеграма есть ограничение на размер файла, длинну видео.

и какое энергопотребление у устройства в таком режиме? Вот, скажем, мой планшет, когда я на него файлы по wi-fi заливаю, сильно лучше держать включенным в сеть, иначе батарейка пробивает дно


Для сравнения посчитал сколько весит недельный объем контента от одного популярного канала с мемами в телеграме (картинки+видео) те самые 500 мб набрались за неделю. Выходит, что в день будет около 70 мегабайт или в час около 5 (будем считать, что ночью активности нет)

Далее к нам приходит тервер, с вероятностью распределения популярных каналов в обществе. В конечном итоге получается, что за час в (например) метро, трафик 1 канала составит 5 мегабайт, берем паразитный как х5 = 25 мегабайт паразитного, из статистики возьмем среднее количество каналов — 10: 250 мегабайт трафика будет передано с учетом паразитного за время поездки.

Вы думаете, что заметите трату аккумулятора при передаче 250 мегабайт?
Вы думаете, что заметите трату аккумулятора при передаче 250 мегабайт?

Я замечу пятикратное увеличение траты аккумулятора.

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

Но опять же — я не говорю, что энергоэффективность будет выше/такая же, очевижно, что затраты будут, не пятикратные конечно в конечном итоге, но будут.
Но опять же — я не говорю, что энергоэффективность будет выше/такая же, очевижно, что затраты будут, не пятикратные конечно в конечном итоге, но будут.

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

Ну вот отлично, мы до чего-то дошли в этом споре =) => вы не видите смысла использовать его при большом overhead но при его отуствии — вы бы использовали?
но при его отуствии — вы бы использовали?

Нет, потому что отсутствие оверхеда автоматически означает отсутствие конфиденциальности.

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

Вы — не видите, а я не хочу, чтобы произвольное соседнее устройство знало, что я читаю дневник Сэм Джоунс.

Значит, если аналогичный функционал будет реализован в каком-то ПО, то вы его отключите. Было бы интересно посмотреть на % людей которые:
1) Выберут не конфиденциальный режим для любых каналов
2) Выберут конфиденциальный режим
3) Полностью отключат фичу

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

Или вовсе не буду пользоваться этим ПО. Ну да. А что, собственно?


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

А вот подписчики RSS-каналов — анонимны (ну, не всех, конечно, но тем не менее). Угадайте, чего у меня больше — групп ВК или RSS-каналов в аггрегаторе?

По этому я и предоставил два примера, с промежуточным заинтересованным и без.

… в случае с промежуточным заинтересованым вероятность интереса 1/2. Это тоже очень мало для оправдания эффективности.

Есть исследования? Мне как-то странно слышать, что, например 80% москвичей в контакте подписаны на одно и то же.
конечно, называетя определение ледеров мнений, на основе этого можно определить % аудитории у того или иного канала от общей массы
Да нахрен этот уровень сигнала: когда сосед приходит/уходит узнать несложно. Время появления появления/исчезновения контента совпадает с его приходом/уходом — совпадение?
То же самое с пассажирами в транспорте.
Например, единственный человек в вагоне.
Архиутопично. Не хватает только пони и радуги.
> И что-то мне подсказывает, что я прав и эту главу начнут именно мессенджеры, а не браузеры или операционные системы…
Нет, эту главу начнут операторы, если уже не начали, а мессенджеры, и уж тем более браузеры с операционными системами, в эту сторону даже двигаться не станут. Мессенджеры — потому что это на порядки дороже, чем воткнуть свой сервер у провайдера. А остальным это и не уперлось.
> выше я описал, как с помощью незначительной доработки мессенджера
Ничего ж себе незначительная. Это просто другой сервис, совершенно.
А какой толк операторам? Это им не выгодно.

Почему вы считаете что дорого? Вот пример создания такого мессенджера используя библиотеку от Apple, весь код в пару строк, всё сетевое взаимодействие делает библиотека и разработчику переживать не нужно. www.appcoda.com/intro-multipeer-connectivity-framework-ios-programming

+ я специально упомянул случае, когда даже покупка сервера не поможет повышению скорости/удобства/доступности.
Да ладно? Может операторам еще и гугловые кеш-сервера у себя держать не выгодно?
Трафик до гугл кэша провайдером учитывается и списывается с вашего счета при доступа, тут же — никакого учета не будет. в чем их профит?
Клиенты замечают, что Гугл у оператора А работает быстрее чем у Б. И кому Гугл важен уходят от Б к А.
так вы техническую реализацию как видите то? вы говорите о классическом CDN но для мессенджера
Профит провайдера в том, что благодаря кешу он может умешьшить количество внешнего траффика, за который ему нужно платить. Например с самого начала торрента провайдеры практиковали сохранять популярные раздачи у себя и раздавать уже со своего хранилища, не выпуская траффик во «внешний мир»
И вы придумал очередной CDN =)
Операторам выгодно. При той же загруженности своего канала они смогут обеспечить большую скорость доставки (маркетинговое преимущество) или на той же скорости меньше нагружать канал (уменьшение издержек).
гм, нет — они не могут гарантировать это от слова совсем. и это совершенно не прогнозируемо…
Тут выше цифра была про 80% совпадений в пределах города. А так они и сейчас не гарантируют, технически до сотен мегабит может быть, на практике хорошо если честная сотня есть.
так технически как должна выглядеть реализация и для какого протокола/приложений?

Технически это может быть http-прокси сервер с распределенным по mesh-сети хранилищем. Socks-прокси и т. п.

и что вы там кэшировать будете? трафик зашифрован

Зашёл посмотреть на эту картинку в комментариях:


UFO just landed and posted this here
Там были не совсем mesh сети, но да, он был близок к описанному, после покупки MS — испорчен с выпиливанием этого функционала.

Кажется вы только что изобрели Фидо. Но через беспровод.

не совсем, это ближе к firechat + tor/i2p
«Но и это еще не всё — если вы находитесь в месте с плохой связью, а вам нужно передать документ вашему другу который находится рядом с вами — мессенджер может найти его и по P2P сети передать ему документ. Что в конечном итоге сэкономит интернет трафик как вам так и другу, да и даже мессенджеру!»
Хм, есть же bluetooth — от качества мобильной связи не зависит, трафик безлимитный, да и передать через него это действие в пару нажатий
Это не удобно, не все платформы это поддерживают, обычный человек привык общатся в его любимом мессенджере, а вы предлагаете мало того, что бы телефон умел передавать по bluetooth, так еще и другой метод взаимодействия (которым он возможно ранее ниразу не пользовался)
А много вы видели телефонов, которые не умеют передавать через bluetooth? Метод взаимодействия кардинально не отличается — выбираем иконку bluetooth вместо иконки мессенджера (если bluetooth выключен многие телефоны даже предложат его включить) и затем устройство, которому мы хотим этот документ передать.
К тому же в случае с мессенджером становится возможной проблема отсутствия у друга зарегистрированного аккаунта мессенджера через который я ему хочу передать документ.

Еще для примера есть scuttlebutt, который реализует gossip-протокол, тоже интересная штука.

На такой способ коммуникации пора переводить весь интернет,
а не только мессенджеры.
Также чтобы любое устройство могло выступить в роли провайдера,
даже между разными каналами связи.
Может быть даже владелец устройства мог получать плату за провод трафика,
через свое устройство.
Прошу прощение, если дублирую чью-то идею. Зачем делать p2p mesh сеть, если можно сделать проще (хоть на базе email), Пишем сервис, который умеет только:
1. получать входящее если адресат находится в этой ноде (о том, в какой ноде уже заранее известно отправителю, если адресат переходит в другую ноду и он там регистрируется — автоматически, то текущая нода говорит предыдущему, что вот юзер у меня с таким то ид), т.е. ноды это всего-лишь транспорт.
2. Клиента можно сделать каким-угодно, шифрование любым из доступных методов, ведь разворачивать умеет его только клиент, но для этого ключи придется передавать адресату каким-то способом, чтобы он смог сообщение прочитать.

Таким образом, даже если пакеты данных будут передаваться через голубей, то там виден всего лишь ид юзера и набор непонятных битов, который никак не коррелирует с логином (случайный набор символов, даже uuid сойдет), а в клиенте в контактах соотнести логин-ид, да и вообще логин можно прочитать уже внутри зашифрованного сообщения.
Простите, а Retroshare уже отменили? Я просто не понимаю к чему такие откровения когда подобные системы известны уже не одно десятилетие. Ни вотсап, но вайбер ни телеграм не пойдут на это. Их задача привязать вас к себе. Именно поэтому «шаг вперед» телеграма это шаг назад. электронная почта, jabber множестов других систем позволяют запускать свои сервера. Вы думаете Дуров просто так отказался от федеративности?
P2P хорошо для тяжелых данных. Это действительно позволяет экономить на серверах для хранения, например, видео.

P2P для сообщений — лишено смысла.

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

И не забываем, что все это мобильный (дорогой) трафик и заряд аккумулятора за то, что вы помогаете кому-то получать их сообщения.
UFO just landed and posted this here
UFO just landed and posted this here

Автор, есть ipfs, есть ethereum swarm. Оба имеют внушительные сети.
Вы сравнивали существующие решения со своим?

Это не массовые решения, и они P2P only, я говорю о гибридном варианте с уже сложившейся аудиторией.
А предлагаемое решение массовое?
На мой взгляд — да, тк не требует от пользователя ничего

Ох, если бы в распределенных системах всё было так просто.
Во-первых, нужно понимать, что практически всегда распределённые коммуникации в разы затратнее централизованных. Если в централизованных для передачи единицы данных необходимо выполнить одну посылку (условно один tcp пакет по установленному соединению), то в распределенных средах нужно сразу озадачиваться роутингом, надёжным релеем (вы же не хотите передавать данные кредитной карты через хакера Васю), и подтверждением доставки. Кстати, внезапно, часть этих проблем решена в TCP.


Во-вторых скорость и стабильность передачи данных. Благодаря сильно неоднородной среде добиться приемлемой скорости коннекта будет крайне сложно. Если где-то на 33-м хопе от меня до вас у пользователя села его нокия, то увы, придётся подождать либо обратного распространения ошибки (а оно еще и может не дойти обратно:) ), либо таймаута, либо сигнального костра.


Ну и самое главное, в-третьих, интернет и сейчас работает примерно схожим образом.


Вообще, велкам в мир распределённых систем. Здесь очень весело :)

Я знаю как работают распределенные системы =) и я не говорю, что это серебрянная пуля, я лишь говорю — что некоторые кейсы они могут решить причем очень хорошо

Итернет можно дополнить mesh сетью для расширения его доступности туда куда сигналы вышек и wifi не дотягиваются. Так же добавить p2p cdn(межпланетная файловая система например) для доставки контента в отрезанные от прямого доступа в интернет либо с нестабильной связью и маленькой скоростью участки.


Потом p2p взаимодействие может включать в себя и клиент сервер. Клиент может начать загрузку видео с сервера и в процессе искать дополнительные источники для увеличения скорости загрузки. Когда скорость загрузки от альтернативных источников будет достаточной можно отключиться либо снизить нагрузку на сервер.

А еще можно каждому медиаконтенту загруженному присвоить свой айди, но не репостнутому тогда можно синхронизировать на уровне контента а не узлов.

и это естественно тоже, в телеге так и сделано
Бухгалтеры не будут понимать как работают mesh сети, но будут часто при обрыве сигнала на телефоне использовать эту функцию :)
Как-то смешано в кучу два разных понятия — p2p и mesh — которые вполне могут работать независимо.
Первое это торренты, и для снятия нагрузки с центральных серверов используются давно, дистрибы линукса, игрушек… их даже применяет мелкософт для распространения обновлений. Добавь в торрент поиск локальных пиров (уже есть) — вот он и ездит поверх локалки или любого меша.
Имхо, к проблеме с батареей добавится расход процессора. т.к. чтобы анонсировать кучу мелких файлов в сеть (мы о мессенджерах же) это не то же самое что один большой фильм например.
Мне больше интересен вопрос именно нижнего уровня передачи. Если обычный wifi работает через точку доступа, как соединяться нескольким устройствам без нее? И как сосуществовать нескольким соединениям одновременно на одном устройстве, если например я подключен к нормальной точке доступа и хочу еще лазить в меш — адаптеры умеют такие фокусы?

В качестве резюме: все плюсы этой идеи только для пользователей, а для хозяев и майоров — одни минусы. Так что в сервисах имеющих документальное ответственное лицо такие чудеса реализованы никогда не будут.
Адаптеры вполне умеют работать в режиме Mesh + обычная точка доступа, примеру тому фреймворк от Apple…
mesh все-таки весьма затратна для мобильных гаджетов. Но даже p2p мессенджеры не могут решить проблему высокого энергопотребления. Tox вот постоянно над этим думает, но пока не сильно продвинулся. Нужно что-то несколько иное. Необходим баланс.

Tox обновлялся последний раз 2 года назад. Он может и думает над этой проблемой, но не больно сильно дело продвигается.

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


TokTok — это неофициальный форк ядра Токса. Официальная репа у токса только одна: https://github.com/irungentoo/toxcore/. И последний коммит в ней был сделан 28 сентября 2016.


Конечно qTox может переползти и на TokTok, да вот только я недавно смотрел изменения в TokTok в сравнении с оригинальной версией, ребята в основном добавили тесты, отформатировали код, поправили пару багов.


Уж я-то знаю какой это внутри франкенштейн. Очень сильно сомневаюсь в ваших знаниях.

Форк ядра Токса от TokTok вполне себе официальный.
На него переползли все клиенты, и вся разработка ведётся только там, irungentoo давно все это бросил.
Благодарю за заботу о моих знаниях, однако в отличие от вас я в теме разработки и ядра, и клиентов токса, а также развития самой сети.
Следующий шаг делать однозначно пора. Только хотелось бы чтобы в «мессенджерах» было еще больше от социальных сетей.
У меня крутится в голове простая идея распространения контента в одноранговых соцсетях: если пользователь поставил лайк к некоторому объекту — то он автоматически становится пиром, распространяющим этот объект.
Что касается именно mesh сетей — думаю это может быть один из вариантов, точнее один из модулей связи. Другими модулями могут быть прямое соединение через интернет, соединение через TOR, I2P и т.п. Пользователь сам будет решать, какие соединения использовать, причем возможно — в зависимости от распространяемого контента.
То что вы описали — уже есть в zeronet :)
Мне сразу приходит на ум аналогия с телефонами на 2 sim карты. Лет 10-15 назад, когда межоператорные звонки было реально дорогие, и люди использовали глючные микросхемы, спаянные в подвале, позволявшие перключить сим-карту, выключив и включив телефон, таких телефонов не было. Когда же и так связь подешевела, и необходимость иметь 2 симки отпала, производители вдруг одумались и сделали следующий шаг.

Лично мое мнение, что Ваша идея имеет тот же недостаток. Мобильный интернет дешевеет, в СНГ появляются безлимитные тарифы, Маск вот-вот свои спутники запустит. Постоянная гонка 3g -> 4g -> 5g идет. Проблема есть еще пока сейчас, но она будет отсутствовать к тому моменту, когда смогут появится первые стабильные версии таких мессенджеров.
А если считаете, что основной затык в серверной инфраструктуре, то, подумайте, какой будет % cache hit у толпы людей со смартфонами и у парочки современных кеширующих серверов с 10G каналом и парой десятков терабайт места на дисках (сейчас это стоит предельно дешево), стоящих в дата-центре мобильного оператора. А где будет стабильность выше? А в сколько (десятков) раз?

Подводя итог, я бы Вам посоветовал искать новые сферы бизнеса, где можно свою исключительно инженерную идею использовать (связь для военных и МЧС, мобильный интернет в открытом море)
А какая доля контента у пользовательей небольшого пространства (на сколько там достанет wi-fi мобильного) реально совпадает? Интернет то большой, вкусы у всех разные, неужели вот прям весь вагон грузит одно и то же?
Что-то мне кажется, что совпадений будет не очень много, соответственно обмениваться так получится только максимум несколькими процентами реально потребляемого контента. Есть ли в таком случае смысл?

ИМХО, такая идея хорошо будет работать только в узких тематических сообществах — студенты в аудитории, сотрудники в офисе и т.п. группы людей которым часто надо иметь доступ к одним и тем же материалам. Но и в данном случае есть более простые и надежные решения.
Что-то подобное было в сериале Кремниевая долина.

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


Также, P2P имеет тот недостаток, что переписка и данные хранятся у пользователей, а не на сервере, и их трудно сканировать, использовать для таргетинга, продавать метаданные из них итд.


Выгоды для производительности в P2P особой нет, так как там данные могут не найтись, надо делать повторные запросы и тд. Выгода есть в приватности, в том, что можно сделать защищенный мессенджер без сервера с хранением сообщений у пользователей — но непонятно, как на нем зарабатывать.

Я не предлагаю только p2p, я предлагаю совмещать p2p+client/server
Это в соц-сетях репостят одни и те же файлы, а с личными диалогами все иначе. Я вообще телеграм использую вместо дропбокса и как еще один способ забекапить личные файлы.
Есть проблема с приватностью. Я могу не хотеть, чтобы посторонние люди могли узнать, что на моем устройстве есть такие-то файлы.

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

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

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

Заметим, что объем мусора должен очень сильно превышать объем того, что я качаю для себя. Боюсь, с эффективностью у такой конструкции будет не очень…
Автор утопист.
P2p сети — очень древняя идея и её регулярно кто-то где-то использует. Можете хоть сами написать p2p-мессенджер за пару дней. Но если посмотреть на действительность, то становится видно: крупные компании наоборот стремятся всеми путями это p2p уничтожить и заменить на свои централизованные серверы (примеры: всем известное убирание p2p из скайпа, всеобщее противодействие jabber-у который хоть и не полностью p2p но распределённый). И очевидно почему: крупным компаниям, у которых есть много денег на пиар, ваши п2п с приватностью нафиг не сдались, и никогда не будут нужны. Им нужна прибыль, а для неё лучше вложиться во что-то другое, например в пиар, да и с регуляторами так проще договариваться.
Вы сильно ошибаетесь, голос например, практически у всех передаётся P2P, почему? — меньше трафика который совершенно не интересен обладателю платформы. Причем так и у телеграм и у Apple. И еще раз P2P != приватность
(примеры: всем известное убирание p2p из скайпа, всеобщее противодействие jabber-у который хоть и не полностью p2p но распределённый)


Утопист так же и вы — видите злой умысел там, где его нет.

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

Джабберу никто не противодействует. Просто он неудобен в плане разворачивания доп. серверов и их поддержка и подключение к новому серверу — делается вручную, кучей не особо заинтересованных друг в друге людей. Ну и система адресации не сквозная — если вы меняете сервер, то и ваш адрес меняется.
Не взлетит для коммерческого использования, однозначно.
1. Пусть есть у меня канал в интернет, обычно это 3G/LTE с каким-то лимитом, например 10ГБ в месяц (у меня и вовсе 30МБ в день). А сосед по вагону Вася подключается по Mesh сети ко мне и начинает мои скромные 10ГБ выкачивать. Ему хорошо, он только WiFi соединение держит, а я буду работать как точка доступа, выжирая аккумулятор. Думаете, мне, простому пользователю, не гику, это понравится? Да я сразу снесу этот мессенджер к чертям.

2. Интернет ОЧЕНЬ большой. И вероятность, что разные пользователи на расстоянии 10-30м смотрят одни и те же ролики (или даже каналы мессенджера!) очень низка. Даже у каждого пользователя VK или Youtube своя лента.

3. Кэшировать видосики на телефоне? Сколько вы готовы отдать места на флеш памяти, чтобы сосед по вагону посмотрел видосик через вас? Но сколько не отдадите, все равно будет мало из-за пункта 2.

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

Как реально решить проблему доступа к интернету — нужно просто создавать больше открытых стационарных точек доступа. В моем дворе телефон видит около 100 запароленных точек WiFi. Все они сидят на широком безлимитном канале, и энергопотребление никого не волнует. Волнует только легальность доступа.
Если решить проблему легальности, скажем открыв на точке WiFi возможность авторизации по номеру телефона через какой-нибудь единый центр авторизации, то проблемы с интернетом в городах просто не будет! Но нужно это сделать так, чтобы не пришлось слать смс каждый раз. Как-то делать запросы на сим-карту, она там своим приватным ключом зашифрует, потом сервер авторизации сможет её аутентифицировать.
1. Можно не качать ничего по просьбе Васи, но отдавать Васе то, что уже скачано

2. Есть контент, который захотят просмотреть очень многие. А есть контент, мало кому нужный. Вероятность того, что кто-нибудь из соседей захочет что-нибудь из популярного я оцениваю, как довольно высокую (ну, скажем, 50%)

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

2. Популярные каналы в подписках у многих, так же как и с youtube — раздел тренды тому пример. как и кэш гугла — он то каким образом работает? он не кэширует вообще весь ютуб если что…

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

4. Не могу сказать — надо тестировать, есть подозрение, что в зонах с плохим покрытием/медленным интернетом может быть даже экономия

Ваш пример с точками доступа — утопичен и не решит главной проблемы озвученной в посте — приложение вынуждено оплачивать внешний канал до вас, почему бы приложению не сэкономить часть денег через p2p?
Вы изначально отталкиваетесь от проблемы, которой не существует.
Много ли контента потребляют в метро? Думаю, намного меньше, чем те люди, которые крутят ленту дома через свой WiFi. То есть если даже вы сэкономите траффик компаний, то очень небольшую его часть (1%?). Стоит ли ради этого делать очень сложную разработку?
На самом деле, вот что точно не является проблемой для таких компаний, так это оплата каналов связи. Чем больше пользователей и чем больше они потребили контента, тем лучше. Инвесторы покупают акции, капитализация летит вверх.

Чем еще плох такой кэш через соседей — часть картинок/видео у вас загрузится, а часть нет. Лента будет такой пестрой. Кликаешь — не грузит, другую кликаешь — грузит. Так себе UX для простого пользователя…

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

Если ваш канал к серверу работает плохо и медленно, то так и получится: «Кликаешь — не грузит, другую кликаешь — грузит.»

А без p2p в таких условиях получится что ничего не грузит.

Спокойно убираешь телефон в карман и наслаждаешься поездкой. А мемы — ну как-нибудь проживем без них 5 минут.
Понимаете, это НЕ проблема, что вы в затрудненной ситуации не можете посмотреть некоторые популярные видеоролики и картинки. Для пользователя важно чтобы либо работало нормально, либо не работало совсем. Иначе только раздражение будет вызывать.
немного не так — телеграм обновляет каналы на фоне, вышел новый пост на канале — ищем соседей, смогли с них загрузить — хорошо, не смогли — грузим с сервера.
Вы немного не уловили мысль — он будет использовать не ваш канал, а только тот контент который уже у вас есть.


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

Проверяется легко.

Качаете обычные торренты и см. кто вам их раздает
У меня обычно с локального треккера идет отсилы 0,1%. Не редкость, когда раздача идет с противоположенной части страны.
Если вы торрент взяли не с локального трекера провайдера то логично


Какова вероятность встретить в метро того, что сидит на одном с вами сайте и интересуется ровно одними и теми же темами?

Одноклассники/одногруппники — вероятность выше. Но и тут она далека от 50%.

Случайный прохожие — забудь.

Идея автора статьи изначально утопична.
В одном поезде в метро, я уверен, что мы найдем людей читающих популярные каналы с мемами. переодические фото на пикабу с незнакомыми людьми которые тоже читают пикабу — тому подтверждение.
Идеалист-утопист.
Так тебе нужно не одну статью на Пикабу синхрить через свой телефон.
А хотя бы несколько десятков последних статей и фотографий, чтобы иметь ненулевую вероятность попасть в интересы соседей.
И это только один-едининственный сайт — Пикабу.
Фото в плане проблемы нагрузки на канал уже давно никому не интересно (а текст так и упоминания не стоит). Может быть интересным только видео.
Фото в плане проблемы нагрузки на канал уже давно никому не интересно

Дефолт сити, дефолт кантри? Не пробовали загрузить ленту фейсбука с телефона в городе Никко, Япония?

Я вот под это дело могу выделить аж 100 Мб. Ни в чём себе не отказывайте!
Больше не дам: аппарат у меня старенький, а апетиты у програм большие.

И не думаю, что много народу будут выделять десятками гигов под кэш.
Блокчейн мессенджер или мессенджер на блокчейне
Нет, а вот блокчейн мессенджер уже есть — Bitmessage но он про другое
Bitmessage не использует blockchain.

Использует, свой собственный, если они ничего не поменяли

Bitmessage nodes store the encrypted messages only for two days before erasing them, therefore, messages are not archived in the network. New nodes joining the network can only download and broadcast the pool's messages from the last two days. Any messages which did not result in a receipt acknowledgement can be re-sent by the originator of the message after the two-day period.

en.wikipedia.org/wiki/Bitmessage
Минус такого подхода — необходимость подключения к сети для проверки подлинности.
Это многое усложняет, плюс дает хороший вектор атаки на всю сеть: вклиниваться в проверку подлинности.
Лучше сегментная сеть, когда сеть может рассыпаться на сегменты, и каждый сегмент сам может контролировать свою подсеть.
Тогда в неблагоприятных условиях сеть просто рассыпется на множество изолированных, но полнофункциональных, сетей, в пределах которых пользователи смогут полноценно пользоваться всеми сервисами сети, но будут ограничены в контенте и контактах, что естественно: связи с внешними сетями просто нет, нет и внешнего контента, нет и возможности общения с внешними контактами.
А при появлении внешних каналов связи весь сегмент общается с внешней сетью через них.

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

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

У телеграмм тут минус в серверах — их можно заблокировать.
Хотя приватные чаты могут остаться работоспособны, т.к. они идут в обход серверов. После блокировки останется шифрованный аналог аськи.
необходимость подключения к сети для проверки подлинности
думаю, схема с открытым и приватным ключом проблему решит. Если у каждого клиента будет открытый ключ сервера, то можно и без подключения к серверу проверить. Но вот зачем?)

Чтоб никто левый сообщеньки от чюжого имени неотправлял. Можно как в торе. Какой ключик себе намайнил такое и имя.

Мне казалось это очевидно, а тут аж целую статью расписали…
UFO just landed and posted this here
кто должен запретить? просто этот процесс сейчас усложняется на яблоках из-за частого использования его в экосистеме и негодования людей когда что-то не работает из-за отключенного блютуза
На мой вгляд, все должно быть на своем месте. Почему какие-то мессенджеры должны лезть и делать MESH на железных интерфейсах? А если таких мессенджеров или приложений несколько?

Я считаю, что должен быть нормальный стек протоколов, где свое место занимает CJDNS или аналог, который организует IP протокол, а уже под ним, меш и роутинг распределенный.

В этом направлении двигаются ребята с LibP2P
Sign up to leave a comment.

Articles