ZeroNet Blogs

Static ZeroNet blogs mirror

Кратко: Это такой новый Twister, с вменяемым интерфейсом.

Опубликована очередная альфа-версия, и я решил попробовать. Работает пока на приватном блокчейне Ethereum, клиент сам скачивает geth и ipfs, все почти будто сделано для людей.


Интерфес очень радует. Предполагаю, что пилят перфекционисты, так что уже заслуживает использования. Дело в том, что будучи чисто решением на Ethereum + IPFS, оно может быть очень просто запущено на любой совместимой с Ethereum цепочке блоков (если они, конечно, откроют код, пока обещают). В новой версии Parity поддерживается работа Proof-of-Authority цепочек блоков, в том числе эксперементально на консенсусе Tendermint. Кроме того, уже есть Ethereum, Ethereum Classic, уже планируется ещё несколько публичных блокчейнов с поддержкой EVM. AKASHA демонстрирует, что концепция приложений: блокчейн для навигации + P2P файлообменая сеть + фронтенд — подходит для создания децентрализованных приложений. Пока все упирается в низкую производительность IPFS.

Вообще такой подход мне кажется более хорошим, чем адаптация блокчейн-платформ вроде graphene, через форки. Тут у разработчиков стоит единственная задача — думать о том, что приложение должно из себя представлять, а не то, как это нужно реализовывать. Ethereum и IPFS берут всю работу с сетью и данными на себя, приложение получается полностью абстрактным (оверлейным).

Возвращаясь к AKASHA, впечатления пока только положительные. Ранее я относился скептически, из-за Ethereum, закрытого процесса разрабоки и множества Vaporware проектов в среде криптовалют. Но реализация меня переубедила. Версии отредактированных постов, выбор лицензии из СС. С вменяемой регистрацией. Ориентированна на контент. Вот что я понимаю под хорошими приложениями, в противовес современному Web, при том что интерфейс сделан на Electron. А вовсе не то, что предлагает автор Pandora.

И это все альфа. Везде бы такие альфы (с).

Формат адресов сайтов в ZeroNet полностью совместим (точно такой-же) с P2PKH адерсами Bitcoin. В ZeroNet даже есть кнопочка в боковой панели для быстрого вызова биткоин-кошелька для пожертвования. Однако, делать пожертвования таким способом, пожалуй, не стоит. Совсем.


Есть целый ряд причин этому.

  • Владелец приватного ключа может просто никогда не узнать о пожертвовании.

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

  • Возможно владелец сайта вовсе не собирается принимать пожертвования.

  • Возможно владелец сайта не желает использовать Bitcoin. Например, из-за вреда наносимого окружающей среде майнингом или по какой-то другой причине.

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

Потому, на мой взгляд, лучше не пользоваться адресами сайтов, для отправки на них биткоинов или чего-то ещё. И не следует ожидать, что вам кто-то отправит пожертвование на адрес сайта, следует отдельно указать счета для пожертвоаний в этом случае.

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


Для того, чтобы лучше понять, почему я сравниваю эти вещи, я написал этот пост.

При всем успехе, одна из главных проблем Steem на мой взгляд, это единое, несегментированное, пространство постов. Там нет ни разделов, ни сообществ, из средств категоризации только теги (первый из которых является некоторым подобием раздела) и избранное. Вероятно за основу был взят подход платформы Medium, но до его уровня категоризации не доработали. Но главное не в этом, а в подходе к начислению рейтинга постов и модерации. Классической модерации там нет, хотя сайт-шлюз может скрыть некоторый контент по своему усмотрению. Вместо нее там есть флажки — нечто вроде агрессивных дизлайков, которые, при достаточном весе приводят к сокрытию поста. Вес определяется рейтингом пользователя (общим для всей сети и количеством Steem Power на его счету). Это быстро привело к проблеме "китов", пользователей с большими суммами Steem Power, обладающими большим весом в голосовании. Как правило, это крупные инвесторы, которых интересует коммерческий успех сети, и их интересует скорее общая благовидность контента. Все это приводит к положению не блокчейн для людей, а люди для блокчейна. Это привело, например к тому, что русскоязычная аудитория терялась преобладающем англоязычном контенте и была даже создана отдельная соцсеть Golos, на том же исходном коде.

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

Тогда, например, не требовалось бы создавать отдельный  форк для русскоязычных, это могло быть бы просто отдельное сообщество. Или такой пример. NSFW контент (автоматически с тегом #nsfw) сейчас скрывается под предупреждающей надписью, подобно тому как это сделано в соцсети Diaspora*. До введения этой меры он и вовсе флаговался, некоторые продолжают делать это и после исходя из личной неприязни. В случае же разделения на сообщества, вообще никакой отдельной меры не потребовалось бы.

Допустим, у нас есть сообщества, и мы имеем такой улучшенный подход. Но все это продолжает оставаться на едином блокчейне. Пропускная способность Steem достаточно высокая, но все же это ограничивает масштабируемость, кроме того, ценой этого является достаточно быстрый рост веса блокчейна. Картинки не хранятся в блокчейне, по той же причине. В терминах ZN они опциональный контент, который может быть утерян.

Если были бы сообщества, с независимым весом в голосовании, то имеело бы смысл хранить контент сообществ в независимых цепочках блоков, вроде независимых хабов в MergerSites. Это бы устранило необходимость реплицировать весь контент сети, что дало бы горизонтальную мастабируемость. Сообщества бы оставались ограниченны лимитами одной цепочки блока, но будучи специализированными, уже этим бы ограничили объем хранимых данных и совершаемых транзакций.

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

ZeroNet и блокчейн

- Posted in AntiGNU by with comments

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


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

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

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

Чего же такого можно позаимстовать у ZeroNet? Первое: это одновременная работа с разными сайтами. ZeroNet работает с несколькими приложениями, позволяя пользователю ощущать себя в едином пространстве, почти как в классическом web. ~~Я заметил недостатки параллельной работы с несколькими сайтами, но это недостатки текущей реализации~~. Практически, на сегодня, нет ни одного решения для параллельной работы с несколькими цепочками. Есть ПО позволяющее выбирать цепочку блоков, но оно позволяет работать в одно время только с одной цепочкой. Более того, сам формат транзакций не рассчитан на работу в несколько цепочек.

Второе — это сегментированность. Концепция Merger Sites в ZeroNet позволяет объединять несколько хабов в рамках одного приложения. При хорошей организации, пользователь может работать только с нужными ему хабами. В блокчейн мире сейчас ситуация иная. В основном мы имеем либо один блокчейн — одно приложение, либо один блокчейн — много приложений. Пока пожалуй есть лишь одна демонстация приложений, работающих с несколькими цепочками блоков — это биржа BitSquare, использующая Atomic Swaps. Некоторое ПО криптовалютных бирж и мультивалютных кошельков, вероятно, тоже использует в какой-то мере унифицированную работу с несколькими цепочками.

В следующем посте, я на примерах Steem, Reddit и ZeroNet попытаюсь объяснить, что все это значит. И как могла бы выглядеть подобная система.


  

Децентрализация

- Posted in AntiGNU by with comments

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


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

1. Данные не должны находиться в одном месте

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

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

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

2. Обслуживающие узлы не должны иметь контроля над данными

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

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

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

3. Децентрализованное обновление состояния

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

4. Консенсус состояния

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

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

Приложения

Если посмотреть на существующие приложения, то:

  • Bittorrent, IPFS удовлетворяет свойствам 1 и 2;

  • BTSync, ZeroNet удовлетворяет(?) свойствам 1, 2 и 3.

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

  • Федеративные приложения, как правило не удовлетворяют ни одному из условий. В некоторых случаях обеспечивается условие 2.

Критика сети Diaspora*

- Posted in AntiGNU by with comments

Не так давно ещё раз посмотрел на соцсеть Diaspora* после длительного перерыва. Собственно, так в ней ничего не изменилось к лучшему. У меня мало надежд на её дальнейшее развитие.


Итак, в версии 0.6.2 остались все те же проблемы:

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

  2. Ужасный интерфейс. Все завязано на JS. Бесконечная прокрутка. Отсутствие возможности какой-либо фильтрации, кроме игнора и избранного.

  3. Отсутсвие API, невозможность реализации клиента с альтернативным интерфейсом.

  4. Несегментированность. Отсутсвие сообществ.

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

  6. Комментарии все так же не поддерживают загрузку картинок, только включение внешних.

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

  8. Все так же узлы просят пожертвований, при этом совершенно бессмысленном дизайне сети.

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

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

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

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


Что же должно быть иначе:

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

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

  3. Само ПО ZN должно быть выполнено в виде демона, занимающегося только загрузкой, хранением, синхронизацией и обновлением состояния приложений, а так же предоставлять API для фронтэнда. Приложения должны быть реализуемы призвольно, а не только в виде JS сайтов во фрейме.

А так же прочие мелочи и следствия из этого:

  1. Не будет необходимости в Namecoin. Регистратор имен можно будет реализовать как нативное приложение.

  2. Создание сложных приложений, подобных Merger Sites. Например форума, где каждый тред является отдельным каналом зарегистрированным в главном канале.

  3. Создание систем модерации и противодействия спаму, например, на основе репутации пользователей.

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

Недавно был опубликован неофициальный десктопный клиент для соцсети Steem. Он сейчас ещё довольно сырой, но уже работоспобный. В частности, он позволяет подключиться к другим нодам, помимо steemit.com, есть даже нода steem доступная через сервис Tor.


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

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

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

Но при этих довольно хороших качествах, Steem имеет недостатки в том, как она сделана. В частности это касается системы репутации. Пространство пользователей и их постов едино, каждый может влиять на это и при наличии достаточного количества средств, может цензурировать сеть. Куда лучше было бы иметь сообщества, где у каждого сообщества был свой внутренний вес пользователя при голосовании. Чтобы пользователи имели влияние только в интересующих их сообществах, а не могли влиять на репутацию всего, что им попадется под руку. То есть больше в стиле Reddit. Хотя, у сети нет достаточной масштабируемости, чтобы быть заменой Reddit. Как и у блокчейна в таком виде вообще.

Кроме этого, регистрация. Это ужас унаследованный от BitShares, где зарегистрировать аккаунт может только существующий в сети пользователь. И премайн специально для того, чтобы осуществлять регистрацию новых пользователей. Лучше в этом плане подход Lisk, где никнеймы опциональны, но существуют и неименованные аккаунты.

Qubes OS для десктопа

- Posted in AntiGNU by with comments

К настоящему времени плотно присел на Qubes OS. Пожалуй даже не смогу в ближайшее время уйти на классические дистрибутивы. Вот несколько основных причин.


Гибкая работа с подключением к сети

Благодаря возможности создавать ProxyVM, возможно настроить как угодно, причем одновременно иметь подключение с реальным IP, через несколько VPN, Tor и тому подобное. Все это в желаемых комбинациях с более менее уверенностью в отсутствии утечек. Пожалуй это основная причина использования.

Возможность быстро создать чистое окружение

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

Относительно безопасная работа с неизвестными приложениями

Хотя уязвимости в Xen и ядре могут быть эксплуатированны, все равно это куда меньше возможности для атак, чем без всякой изоляции. Довольно просто запустить приложение в новом окружении, для чего даже есть удобный механизм одноразовых DisposableVM.

Создание окружения с нуля

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

Лучше работает чем контейнеры

У меня c Docker и Flatpak все довольно часто подвисает, на разных машинах. В Qubes OS то что происходит внутри VM меньше влияет на работу системы вцелом и других VM.

Но все же есть недостатки

Пока ещё не придумал хороший способ расшаривания дискового пространства между несколькими окружениями. Это пожалуй основной неудобный момент.

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

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

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