Неужели децентрализованная сеть может быть полезной?

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

Действительно полезная децентрализованная сеть должна быть, по крайней мере, резервной копией обычного Интернета и использовать URL-адрес простого Интернета для идентификации ресурсов. Например, в этой гипотетической DecNet есть расширение Chrome, которое отправляет каждый URL-адрес, который пользователь посещает в локальное одноранговое приложение DecNet пользователя, которое сохраняет локальную копию этого ресурса. Время от времени DecNet обновляет информацию обо всех URL-адресах, поэтому пользователь всегда имеет фактическую копию необходимой ему информации. Когда обычный Интернет становится недоступным, пользователь может получать обновления как учасник DecNet сети. Проблема источника истины существует в этой модели, но доступность информации важнее аутентичности. Для проверки подлинности может существовать десятки надстроек на этой DecNet.

Фактически я говорю о персональном archive.org с возможностями децентрализованой сети

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Ctrl + Enter
Ctrl + Enter
пока у него нет проблем с подключением к Интернету, и правительство не блокирует необходимые ресурсы

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

Думаю зараз для РФ та і скоро для України тема значно цікавіша чим раніше. Нажаль ZeroNet неактивне

Может что-то такое интересно будет? Swarm Orange Summit 2018. Будет в Любляне в мае, альфу обещают в 2019. Или не оно?

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

Это же для статического контента

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

Да не нужно это мне. Я обсуждаю концепцию, а не решаю задачу. Свою задачу сохранения ресурсов, которые могут пропасть или измениться я уже решил — написал расширения к хрому, которое сохраняет все URL которые вы посещаете на archive.org — github.com/kissarat/never-lose . Можно доделать чтобы оно отправляло ссылки на сервер пользователя, в том числе могло сохранять видео с ютуба, к примеру. Последние весьма полезно так как некоторые ресурсы не нужно чтобы попадали в archive.org, а я могу забыть добавить в фильтр в настройках

Візьмемо сайт, контент якого зберігається в базі даних (скажімо, rada.gov.ua). Якщо користувач здійснив той самий запит, що й інший користувач децентралізованої мережі, тоді контент буде закешований, інакше — ні. Виходить, що розробники сайтів повинні враховувати користувачів із децентралізованих мереж?

i2p очень полезная сеть я считаю

И там есть решения для хранинения сайтов локально?

Точно не знаю надо доки читать. Я как пользователь это сети очень доволен.

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

Ні. Свою задачу я можу рішити squid + nfs . Я задався тим питанням і зрозумів шо можна переосмислити веб-розробку динамічних сайтів (а особливо single page application) так, щоб вони запускались в інших місцях (не на вашому домені) і не ламались при цьому

не на вашому домені

І щоб проблем з безпекою не було ;-)

То вже тема скоріше прямих рук і обізнаністю з питаннями безпеки. Безпосереднього відношення до того, що обговорюється немає

Проблема в сайтах, бОльшая часть динамики реклама и смм.

конечно может. после ядреного акопалипсиса

Приложения обычного веба могут делатся так чтобы они работали в офлайне и чтобы навигация по них не была седленной если скорость подключения небольшая или пинг как минимум несколько секунд. А если бы ресурсы по URL обычного веба были доступны в ZeroNet в независимости от доступности сервера на котором они хранятся — цены бы небыло такому решению. В Китае ядерный апокалипсис?

Приложения обычного веба могут делатся так чтобы они работали в офлайне

не могут

Для этого есть фоновые сервисы (кажется ServiceWorker) в которых можно переопределять fetch. Что вы знаете об этом?

я знаю о тех, кто это будет писать. не могут

Ну воркер это конечно зашибись. Но если приложению требуется бекенд для реализации бизнес-логики — это не обойти никак. А кеширование статики придумали в-принципе довольно давно. Можно веб-приложение в node-webkit или electron обернуть и тогда оно будет вообще как обычное десктопное — скачал один раз и радуйся всю жизнь. Но ровно до тех пор пока не требуется централизованное хранение данных, взаимодействие между пользователями или выполнение какой-либо работы (вычисление или сбор данных) даже в то время когда клиент не работает.

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

Да и его достаточно для того, о чем я говорю. В ZeroNet сайт не обновится пока его владелец не подпишет изменения. Чтобы открыть страницу если соеденения нет без ServiceWorker не обойтись, как я понимаю. Разве что вы открываете локально сохраненный html файл, но тогда у вас нет домена и связанных с ним прав доступа. Когда-то был AppCache но от этого отказались

Чтобы открыть страницу если соеденения нет без ServiceWorker не обойтись, как я понимаю

Не уверен что воркер поможет открыть приложение на самой ранней стадии. Если это PWA и оно было добавлено на главный экран — наверное, но сработает все равно только на андроиде.

Однако я не вижу необходимости в том, что вы описываете. Чтобы прям не было интернета совсем-совсем и он жизненно нужен — я таких случаев даже не знаю. Кому нужен доступ к сети всегда имеют резервный канал. Я например безлимит от Киевстара на смартфоне держу на случай если проводной интернет пропадет, а мне сильно надо. При этом если мне нужен интернет — это значит что мне нужен доступ к серверам/репозиториям и месенджеру для работы или доступ к игровым серверам для игры. А описываемый вами зеронет может обеспечить только сайты почитать и поработать с веб-приложением без сохранения данных на бекенд. И зачем оно надо?

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

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

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

Проблема не в децентрализованных сетях, а в преступлениях. Когда государство объявляет себя врагом народа — население оказывается с преступностью по одну сторону баррикад, и бороться с преступностью больше некому.

Сказать что преступность есть — не сказать ничего. Сайтов с опасным для пользователя контентом, реально опасным — с вируснёй, а не с «неправильной» инфой, больше чем безопасных. Результат? Монополизация трафика и потеря интереса (особенно маркетингового) к абсолютному большинству стоящих проектов, если только их не собирается купить Гугл или Фейсбук.

То есть проблема не в сети. Проблема в отсутствии государства.

Того не треба нічого робити, ідемо жити в ліс

Підписатись на коментарі