base.network
«Свобода — это возможность сказать, что дважды два – четыре. Если дозволено это, всё остальное отсюда следует.»
Джордж Оруэлл — «1984»

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

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

Предлагаемая система base.network призвана устранить подобные недостатки пиринговых сетей и объединить в себе все технические преимущества централизованных систем со свободой обмена информации в распределенных сетях.
Это своего рода попытка создать защищённую децентрализованную сеть с малым временем отклика и свойствами автономности, отказоустойчивости и масштабируемости. Ключевой целью проекта является способность функционировать даже под давлением организаций, осуществляющих контроль, пресечение публикации, а также ограничение доступа к информации в Интернете. Все аспекты проекта доступны в виде открытого исходного кода и бесплатны. Это позволяет убедиться, что программное обеспечение делает именно то, что заявлено, и дает возможность всем разработчикам совершенствовать защиту сети от попыток ограничить свободное распространение информации.


base.network — Что это?


Это одноранговая сеть предназначенная для децентрализованного распределённого хранения данных без возможности их цензурирования. Система не имеет центральных серверов и не находится под контролем каких-либо частных лиц или организаций. Создана с целью предоставить пользователям свободу слова в онлайн-пространстве. Система работает на основе объединения в общий кластер серверных нод, предоставляемых членами сети на безвозмездной основе. Все данные равномерно распределены между серверными нодами и не требуют центрального хранилища. Участники предоставляют полосу пропускания и дисковое пространство своих серверов для публикации или получения в Сети разного рода информации. Например, файлы, структуры данных и упорядоченные списки.

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

Все данные залитые в систему обязательно подписываются автором, используя для этого криптосистемы с открытым ключом. Проверить авторство тех или иных данных всегда можно зная публичный ключ автора. В качестве криптографического алгоритма для создания цифровой подписи и шифрования данных в системе используется асимметричный алгоритм шифрования с открытым ключом основанный на ECDSA (Elliptic Curve Digital Signature Algorithm) с длиной ключа 256 бит (в частности, используется кривая secp256k1) и хеш функция SHA-256.

Как устроена сеть


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

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

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

Хранение данных


Для начала, чтобы понять организацию хранения данных, представим, что все пространство сети ограничено строго заданным объемом, скажем, в 32 ГБ. Таким образом, сеть превращается в огромную хеш-таблицу, где каждый документ по его хеш-адресу будет строго иметь свое место в виртуальном пространстве сети. Чтобы не хранить все данные сети на одной физической машине (как это сделано, например, в системе Bitcoin) разделим всё наше виртуальное пространство на некоторое количество сегментов. Для начала, поделим его, скажем, на 8 сегментов. Каждый сегмент по 4ГБ. Теперь выделенные физические машины могут по отдельности обслуживать отдельные сегменты, без необходимости хранить полную копию базы, а лишь её кусочек. Каждая такая серверная нода может поддерживать несколько сегментов сети. Один же сегмент будет обслуживаться несколькими независимыми нодами. Зная физические адреса машин, и имея информацию о том какие сегменты какими машинами обслуживаются, мы всегда можем получить доступ к отдельному документу по его адресу. Доступ к нодам осуществляется посредством стандартного http-протокола.

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

base.network - scheme

Кольца


Выше было оговорено, что пространство сети ограничено определённым объемом (32 ГБ) и сеть таким образом работает как огромная хеш-таблица. Все это верно для виртуального пространства, ограниченного в рамках одного так называемого Кольца.

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

Например, для хранения файлов количество сегментов в первом кольце равно 8. Во втором 64. и т.д. Размеры сегментов увеличиваются в 2 раза. Объем каждого следующего кольца, таким образом, увеличивается в 16 раз. И, к примеру, для третьего кольца он составит 16 ТБ. А для 5-го уже 4 ПБ!

base.network - rings

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

Ноды


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

curl http://5.9.123.140:8080/-/nodes

{"nid":"5.9.123.140/8080","ver":1,"seg":"D,N,F,P,D0,D1,D2,D3,D4,D5,D6,D7,F0,F1,F2,F3,F4,F5,F6,F7,P0,P1,P2,P3,P4,P5,P6,P7,D06,D64,F50,P00,P55,P77"}
{"nid":"46.4.76.98/8081","ver":1,"seg":"D,N,F,P,D0,D1,D2,D3,D4,D5,D6,D7,F0,F1,F2,F3,F4,F5,F6,F7,P0,P1,P2,P3,P4,P5,P6,P7,D57,D66,F41,F54,P04"}

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

curl http://5.9.123.140:8080/-/about

{"ver":1,"nid":"5.9.123.140/8080","segments":{"D":{"usage":0},"N":{"usage":0},"F":{"usage":0},"P":{"usage":0},"D0":{"usage":0},"D1":{"usage":0},"D2":{"usage":0},"D3":{"usage":0}," 
... ,
"updated":1441639911027}

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

Адресация документов


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

document URI:

 	D2/my-domain.base/path/document.txt

path:

 	my-domain.base/path/document

uid — sha256(path) (hex):

 	49ea72cbd1de7f2d...3cf23d49778

uid (oct):

 	2236516262750736...44365113570 

document`s coordinates:

 	storage:	D
 	ring:  		2
 	uid:		49ea72cbd1de7f...f23d49778
 	segment:	D22

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

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

Все документы в системе характеризуются следующими параметрами:
  • storage — Тип хранилища. Указывается в виде одного символа. Например F,N,D,P
  • ring — номер кольца в хранилище (integer)
  • uid — уникальный идентификатор ресурса (hex64)

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

              <storage:char><ring:int>/<uid:hex64>


Для некоторых типов хранилищ, такие как файловое хранилище, список параметров будет чуть шире. Например:
  • extention — расширение файла. Говорит о типе содержимого.
  • aid — уникальный идентификатор автора (хеш от его публичного сертификата длиной 20 символов), необходим в случае, когда мы запрашиваем информацию только конкретного автора для указанного адреса.

Пример ссылок:

F1/ef43c9adc8aeec6910b4373ba0d9fbf28048ed53ec631ab9fd6fa8ad00a8a3a0.txt

D4/930bbc0fa952dcc8eb7e8a711ac953c61f76f86fecd1ba7b0b5c4e74834e12bf?aid=Ipf8SOrpxbgYnNMXszFk 

Типы хранилищ


На текущий момент система реализует 4 типа хранилищ данных, каждое из которых позволяет хранить различные структуры информации.
  • F — файловое хранилище
  • N — хранилище доменных имен, сертификаты
  • D — списки данных одного автора
  • P — публичные списки данных

Расскажем немного подробнее о каждом из них.

Файловое хранилище (тип хранилища F)

Файлы, в отличие от строковых данных, имеют некоторую специфику в адресации. Адресом файла (его uid-ом) выступает хеш sha-256 от его содержимого. Таким образом, один и тот же файл, залитый в сеть различными пользователями, будет иметь один и тот же адрес. Убедиться в том, что по заданному адресу возвращается корректное содержимое, можно проверив его хеш. Тип содержимого (Content-Type) файла указывается непосредственно в ссылке в виде расширения (extention).

Например, следующей ссылке
   F1/ef43c9adc8aeec6910b4373ba0d9fbf28048ed53ec631ab9fd6fa8ad00a8a3a0.txt
будет соответствовать документ с параметрами:
  • storage=F — тип хранилища “Files”,
  • ring=1 — первое кольцо,
  • uid=ef43...a3a0 — уникальный идентификатор файла,
  • extention=txt — расширение файла, которому соответствует тип содержимого (content-type) “text/plain”

По заданному uid, переведя его в 8-ричную систему, по первой цифре получим номер сегмента. Ему соответствует “7”. Теперь, зная все ноды, которые обслуживают сегмент с именем “F7”, а также физические адреса нод, мы можем получить сам документ:

curl -i http://5.9.123.140:8080/-/F7/data/ef43c9adc8aeec6910b4373ba0d9fbf28048ed53ec631ab9fd6fa8ad00a8a3a0.txt

HTTP/1.1 200 OK
Content-Type: text/plain; charset=utf-8
Cache-Control: max-age=315360000, public
Expires: Sun, 17 Aug 2025 15:18:30 GMT
Access-Control-Expose-Headers: x-base-author
x-base-author: AA3Evvx1AR...i8UONOm92Q==
Connection: keep-alive
Transfer-Encoding: chunked

TEST FILE

Теперь проверим хеш от содержимого полученного документа:

curl http://5.9.123.140:8080/-/F7/data/ef43c9adc8aeec6910b4373ba0d9fbf28048ed53ec631ab9fd6fa8ad00a8a3a0.txt|shasum -a 256

ef43c9adc8aeec6910b4373ba0d9fbf28048ed53ec631ab9fd6fa8ad00a8a3a0 -

Все в порядке: он соответствует нашему запрашиваемому uid.

Ниже приведена таблица соответствий количества сегментов и размера кольца в зависимости от его номера для файлового типа хранилища.

Params of F-storage
ring Size of segment GB Count of segments TOTAL SIZE OF RING Max Size of Data Pack, KB Min count of records
0 2 1 2 GB 2 1.05E+06
1 4 8 32 GB 16 2.10E+06
2 8 64 512 GB 128 4.19E+06
3 16 512 8 TB 1 024 8.39E+06
4 32 4 096 128 TB 8 192 1.68E+07
5 64 32 768 2 PB 65 536 3.36E+07
6 128 262 144 32 PB 524 288 6.71E+07
7 256 2 097 152 512 PB 4 194 304 1.34E+08


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

Доменные имена (тип хранилища N)
Данный тип хранилища необходим для хранения информации о доменных именах, владельцах доменов и публичных сертификатах зарегистрированных пользователей. Этот тип хранилища доступен на запись исключительно регистраторам доменных зон. На данный момент он один — это регистратор виртуальной доменной зоны .base. Публичный ключ регистратора известен всем участникам сети и жестко прошивается непосредственно в клиентском и серверном ПО.
Размер сегмента нулевого кольца хранилища составляет 8 ГБ. Этого размера теоретически должно надолго хватить чтобы хранить все данные о доменах и сертификатах исключительно в одном сегменте нулевого кольца. Таким образом, получение информации по имени домена будет происходить без поиска в разных кольцах.
Итак, хранилище типа N представляет собой своего рода огромную хеш-таблицу. По имени домена можно запросить информацию о владельце домена и его публичный ключ.
Например, для домена test.base.network нам будут возвращены следующие данные:

curl 'http://5.9.123.140:8080/-/N/data/test.base'

{"ver":0,"author":"AA3Evvx1ARDVVyiPWZ1197l3MAOPe2U1FR7hjxQpL6TQmqf8dxEEoB/AV19Um49u9U7Lb8Lx9ujX2MurTd6qnWw=","hash":"yU6mMInrZqN43/ggsj+0J/g1rpsMs+lFiO7LuoXGwRo=","sign":"vB00Eewv7hzVrvtGUhUtjOHvU8u7uM0KujyId+py6GvJdwBNkInw8FeUX1+DYYFtygFX5QyB70BShhDv9Gd9ZA==","data":"eyJvd25lciI6IkFBM0V2dngxQVJEVlZ5aVBXWjExOTdsM01BT1BlMlUxRlI3aGp4UXBMNlRRbXFmOGR4RUVvQi9BVjE5VW00OXU5VTdMYjhMeDl1algyTXVyVGQ2cW5XeHVFeHhhdExQb1BadWtPdS9iTktkZEVqbm9VeDljZ0UzMzlnWkdzQUJWRGMvWDFGS1dPMjJGOElJejVxamF5b2R2ZklZZHZ0WmRjUEdXVm1rWUxYdngifQ=="}


Эта информация подписывается корневым сертификатом регистратора и клиенту всегда можно проверить ее валидность. Декодировав данные из base64, мы получим следующую информацию о домене в виде JSON. В качестве owner указан публичный сертификат владельца домена.
{"owner":"AA3Evvx1ARDVVyiPWZ1197l3MAOPe2U1FR7hjxQpL6TQmqf8dxEEoB/AV19Um49u9U7Lb8Lx9ujX2MurTd6qnWxuExxatLPoPZukOu/bNKddEjnoUx9cgE339gZGsABVDc/X1FKWO22F8IIz5qjayodvfIYdvtZdcPGWVmkYLXvx"}

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

Списки данных (тип хранилища D)
Помимо одиночных документов, в сети существует возможность работать со списками данных, формировать так называемые ленты. Списки, как и одиночные документы, располагаются по определенному уникальному идентификатору uid. Uid-ом для списков является хеш sha256 от его строкового адреса. Однако для данного типа хранилища, в отличии от первых двух, существует возможность запрашивать списки документов заданного автора с заданным порядком сортировки и смещениями. Фактически данное хранилище реализует простейший индекс, который позволяет возвращать упорядоченные данные.
Например адресу списка test.base.network/blog будет соответствовать следующий uid
sha256(“test.base/blog/”) ->
e1d8f9c396164dbbb8debf9c0ce08805bcf4bd8d98c2cc462c8bc21c21f27438


Теперь мы можем запросить список документов, автором которых в данном случае является владелец сайта test.base.network (с aid=Ipf8SOrpxbgYnNMXszFk). По умолчанию сортировка записей осуществляется в обратном порядке по времени добавления.

curl -i 'http://5.9.123.140:8080/-/D7/data/e1d8f9c396164dbbb8debf9c0ce08805bcf4bd8d98c2cc462c8bc21c21f27438?aid=Ipf8SOrpxbgYnNMXszFk'

HTTP/1.1 200 OK
Content-Type: text/plain; charset=UTF-8
Access-Control-Allow-Origin: http://core.base.network
Date: Tue, 25 Aug 2015 11:38:44 GMT
Connection: keep-alive
Transfer-Encoding: chunked

{"pos":"MjAxNTA3MTkwOTI1NDU5ODg=","ver":3,"author":"AA3Evvx1ARDVVyiPWZ1197l3MAOPe2U1FR7hjxQpL6TQmqf8dxEEoB/AV19Um49u9U7Lb8Lx9ujX2MurTd6qnWxuExxatLPoPZukOu/bNKddEjnoUx9cgE339gZGsABVDc/X1FKWO22F8IIz5qjayodvfIYdvtZdcPGWVmkYLXvx","hash":"MWEyLxrkDosW2FU3+GTYXk045PN8TBhsiloovkxuTvA=","sign":"rgtR7qJXc5GMbm7TxZijbQiKOtH9gpWhUUt7z6L2yetEcRR7bUdVxmW9UvUPVaMfq1LpVEcZ4IF2CuQf4NVvHw==","data":"eyJ0aXRsZSI6...sbCJ9"}

{"pos":"MjAxNTA3MTkwOTEzNTY0NzE=","ver":3,"author":"AA3Evvx1ARDVVyiPWZ1197l3MAOPe2U1FR7hjxQpL6TQmqf8dxEEoB/AV19Um49u9U7Lb8Lx9ujX2MurTd6qnWxuExxatLPoPZukOu/bNKddEjnoUx9cgE339gZGsABVDc/X1FKWO22F8IIz5qjayodvfIYdvtZdcPGWVmkYLXvx","hash":"7r+ZfOVi+2/ZkRFeHwNytk20j6xTZKvJ73m1GCuXsFY=","sign":"ZpZBWLrUT1RZ/s+5ea8o6ckG2dfqqzUkKkQMUjAnVoC3pRzaGW4Q3lV8/rUjDpCdCWPum9juA2tDNBLG+qqL1g==","data":"eyJkZXNjcm...iYWxsIn0="}

...


Валидность и авторство каждой такой записи можно проверить по ее хешу (hash) и подписи (sign), сформированной автором при добавлении документа.

Помимо всего, хранилища типа D и P дают клиентам возможность осуществлять подписку на добавление записей в ленту, используя для этого технологию SSE (Server-Sent Events). Например, следующим запросом можно подписаться на добавление данных в нашу ленту. Клиент откроет соединение и будет ожидать появления серверного события.
http://5.9.123.140:8080/-/D7/listen/e1d8f9c396164dbbb8debf9c0ce08805bcf4bd8d98c2cc462c8bc21c21f27438?aid=Ipf8SOrpxbgYnNMXszFk

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

Публичные списки данных (тип хранилища P)

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

Например, http-адресу списка http://test.base.network/chat/ будет соответствовать следующий uid (=SHA256(“test.base/chat/”))
be977147bd78d5a4db7d09aa3a48b3f24c8578c3ea06806d8ff4210f08a2c5a4

curl -i 'http://5.9.123.140:8080/-/P5/data/be977147bd78d5a4db7d09aa3a48b3f24c8578c3ea06806d8ff4210f08a2c5a4'
HTTP/1.1 200 OK
Content-Type: text/plain; charset=UTF-8
Access-Control-Allow-Origin: http://core.base.network
Date: Tue, 25 Aug 2015 11:29:47 GMT
Connection: keep-alive
Transfer-Encoding: chunked
{"pos":"MjAxNTA4MTQwODQ5MzYyOTA=","ver":1,"author":"AMywBHKulTlmRXYZ2P+Bl/naYVh9Gx6MACcKYXWd1ypuPrWnJrd0mu7xgAUxrfeArq43zaM9BeQp+fQty6fHcjU=","hash":"JgRFIFD3AyzsATMNCeAnyxvGgjU7TMmW/ODlXARG8Pk=","sign":"+LG5/taPav00KoRqScABctzjxTlvZIV7nykpqKtxn7AVx6fY4itn7Mtrbisiw5yhf0pC8DLd4akTHYO5C8iWtA==","data":"eyJ0ZXh0IjoidGVzdCAzMzMifQ=="}
{"pos":"MjAxNTA4MTQwODQ5MDI0MjQ=","ver":1,"author":"AMywBHKulTlmRXYZ2P+Bl/naYVh9Gx6MACcKYXWd1ypuPrWnJrd0mu7xgAUxrfeArq43zaM9BeQp+fQty6fHcjU=","hash":"llOP+Sq5BfIJMZKGfqdCJ5ERq8gPITanj9yDH75PAR4=","sign":"EsUH37lW4qF+N/4r0DcgSJKVf4j3UN0uWGHuh6asBbOER539K98o2/DBSCL10YKrA3KCOEHsTE2tsAGf9B/zSQ==","data":"eyJ0ZXh0IjoidGVzdDIyMiJ9"}
{"pos":"MjAxNTA4MTQwODA3Mzg1NTI=","ver":1,"author":"AMywBHKulTlmRXYZ2P+Bl/naYVh9Gx6MACcKYXWd1ypuPrWnJrd0mu7xgAUxrfeArq43zaM9BeQp+fQty6fHcjU=","hash":"XrRlv2sF9ae2GOWehfem6ovLJomZIXtLk27ir+6q+gs=","sign":"aYF7kB0OVc8gvg5U7TrsBB25+tF/HwpCePHkyyWPVvuS5ylgbxJV5Tb06eb/VIaeEK2Y2gMY23hHcRw4SDT1jQ==","data":"eyJ0ZXh0IjoidGVzdCJ9"}
...

Характеристики колец для публичных списков очень похожи на характеристики хранилища типа D:

P-storage
ring Size of segment GB Count of segments TOTAL SIZE OF RING Max Size of Data Pack, KB Min count of records
0 2 1 2 GB 2 1.05E+06
1 4 8 32 GB 16 2.10E+06
2 8 64 512 GB 128 4.19E+06
3 16 512 8 TB 1 024 8.39E+06
4 32 4 096 128 TB 8 192 1.68E+07
5 64 32 768 2 PB 65 536 3.36E+07
6 128 262 144 32 PB 524 288 6.71E+07
7 256 2 097 152 512 PB 4 194 304 1.34E+08

Хранилище также дает возможность клиентам подписываться на события добавления записей в определенную ленту через Server-Sent Events.

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

Как сеть работает для пользователя


Для обычного пользователя работа с системой начинается без установки какого-либо специального ПО. Для этого достаточно лишь использовать обычный браузер. Для ВСЕХ адресов *.base.network/* возвращается статичная html-страница, которая включает в себя код клиентского ядра, написанный на JavaScript.

image

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

Клиентское ядро содержит в себе начальный список нод (их IP-адреса и порты). При первой загрузке движка, скрипт пытается подключиться к любой ноде из этого списка и получить от нее свежую карту сети, которую он в последствии будет хранить в LocalStorage браузера. Скрипт периодически будет опрашивать ноды из его списка и обновлять информацию о сети. Карта сети содержит в себе список всех нод, их адреса и порты, версию серверного ПО, а также список сегментов обслуживаемых каждой нодой. Теперь на клиенте достаточно информации для того чтобы получить любой документ из сети. Для любого адреса документа мы знаем в каком сегменте он находится и какими нодами этот сегмент обслуживается. Для более быстрой загрузки данных из сети, клиент выбирает ближайшую к нему ноду. Подлинность скачанных данных клиент может проверить по хешу и сверив подпись автора, используя его открытый ключ.

При первом входе в сеть для пользователя генерируется анонимный сертификат, содержащий закрытый и открытый ключ. Этот сертификат хранится в LocalStorage браузера в пространстве имен домена core.base.network. Скрипты других доменов не имеют прямого доступа к этому пространству и не могут получить информацию о закрытом ключе.

base.network API

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

base.netwrok client side

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

Регистрация


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

base.network core iframe

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

base.network registration

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

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

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

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

Знакомство. Демо


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

Итак, после регистрации пользователем своего домена, он может зайти на свой персональный сайт, сменить настройки, указать тему, дизайн, потенциально установить сторонний движок, создавать и редактировать разделы сайта. Пример подобного сайта, а также демонстрация возможностей системы предлагаются по примеру тестового сайта: http://test.base.network/.

base.network demo site

В качестве примера текущий движок позволяет добавлять такие сервисы как:
  • блоги
  • фотоальбомы
  • музыкальные и видео плейлисты

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

base.network edit page

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

base.network mobile

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

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

Инфраструктура проекта


Установка серверного ПО


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

  1. Перед установкой ноды необходимо убедиться, что на сервере уже установлена платформа Node.js или установить ее в соответствии с инструкцией
  2. Скачать репозиторий с github

    git clone https://github.com/basenetwork/base.server-node
    

  3. Установить модуль sqlite3 для Node.js

    cd base.server-node && npm install sqlite3 --build-from-source && cd ..
    

  4. запустить ноду
    nohup base.server-node/base.node.js --size=32  >/var/log/base.node.log &
    

В качестве параметра size необходимо указать свободный объем на диске (в ГБ), который вы готовы выделить под ноду.
Для работы ноды необходимо выделить внешний IP адрес и свободный порт. По умолчанию система попытается автоматически использовать один из внешних IP адресов в списке network interfaces операционной системы. Возможно вручную указать IP-адрес и порт, используя параметры запуска --host и --port:

nohup base.server-node/base.node.js --size=32 --host=41.34.55.66 --port=2222  >/var/log/base.node.log &

Проверить работоспособность ноды можно, сделав http-запрос к веб-серверу:

curl http://41.34.55.66:2222/-/about

Исходный код


Со всеми исходниками проекта можно ознакомится на GitHub — github.com/basenetwork. Аккаунт содержит несколько репозиториев:
  • base.server-node
    Собственно, сама серверная нода. Репозиторий написан на Node.js. Инструкция по установке base-ноды на свой сервер была представлена выше.
  • client-js
    Клиентское ядро. Проект написан на JavaScript. Включает в себя базовые функции по работе с системой. Это непосредственно тот самый код, который подгружается при открытии любого сайта системы — http://base.network/core.js Сайтовым движкам для работы с сетью ядро предоставляет специальный API — baseAPI
  • site-engine-js
    Сайтовый движок. Написан на JavaScript с использованием библиотеки React.js. В качестве фреймворка для верстки и стилей использует Bootstrap v3. Это собственно тот код, который организует структуру сайтов, их внешнее представление. Реализует систему редактирования контента для владельцев сайтов. В данный момент в качестве теста движком реализованы такие сервисы как блоги, фотоальбомы и списки медиа, а также систему комментариев к постам и фотографиям. Движок не работает напрямую с сетью, а использует для этого специально предоставленный ядром API.
  • static-builder
    Специально разработанный билдер статических файлов. Билдер написан на Node.js. Работа билдера заключается в компиляции всех статических файлов в один единственный javascript-файл. Необходим для компиляции ядра и движка сайта. Скомпилированный файл включает в себя полностью весь функционал для работы с сайтом: программный код, логику, формы, стили, шрифты и иконки, используемые в оформлении сайта. Полученный файл выкладывается в сеть и подгружается пользователем в качестве движка один единственный раз, при посещении сайта.
    Билдер в css-файлах стилей непосредственно вместо ссылок на шрифты и иконки вставляет закодированное в base64 их содержимое. А уже полученные css-файлы, а также скомпилированные js и jsx объединяет в один единственный js-файл.

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

Планы


  • Доработать сайтовый движок. Переработать дизайн и повысить юзабилити существующего функционала. Добавить ряд полезных функций, чтобы по функционалу не уступать современным социальным сетям.
  • Локализовать веб-интерфейс для популярных языков.
  • Добавить сервис личных сообщений с обеспечением полной анонимности. Сервис помимо шифрования непосредственно содержимого сообщений будет скрывать сам факт переписки двух лиц, чего сложно добиться с использованием централизованной системы. Реализация такого сервиса требует лишь небольших доработок сайтового движка на стороне клиента. Серверная часть уже сейчас вполне готова для воплощения подобного функционала.
  • Переписать серверное ПО на языке GO, поскольку скорость работы с криптографического алгоритмами на Node.js оставляет желать лучшего.
  • Покрыть весь функционал тестами.
  • Составить подробную документацию к проекту, API и протоколам общения клиент-сервер.
  • Создать своего рода Store сайтовых движков, сервисов и плагинов, а также стилей и дизайн-тем.

Поддержка проекта


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

Кроме того, если у вас в распоряжении имеются сервера, либо на ваших персональных машинах есть выделенный канал, вы можете предоставить небольшую часть своих машинных ресурсов для развития сети. С инструкцией по установке серверной ноды вы можете ознакомится выше или на github. Также будут крайне важны ваши отзывы о работе установленного серверного ПО.
Веб-разработчики, владеющие Node.js, могут предложить свои доработки и советы по оптимизации серверного ПО.

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

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

Спасибо за поддержку!

Заключение


И в заключение немного лирики. Цензура в современном мире — это большая глупость. Любые идеи, неважно технические или гуманитарные, развиваются одинаково? — ?они растут одна из другой, бесконечной цепочкой. Идея имеет право быть высказанной и услышанной в её оригинальном виде, без искажений и цензуры. Однако в современных реалиях рукописи вполне неплохо горят и написанное пером нещадно вырубается топорами. И, как ни печально осознавать это, но задуманный как рупор свободы, Интернет в руках правительств стран и государств превратился в инструмент всеохватывающего контроля. Причем контроля настолько неприкрытого, что все чаще продвинутая часть общества задается вопросом: а есть ли свобода слова в интернете? Можем ли мы с его помощью открыто заявлять о чем-то действительно важном? Видим ли на его просторах всю палитру разнохарактерных независимых мнений?

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

Комментарии (42)


  1. Ivan_83
    07.09.2015 19:33
    -3

    Такие вещи нужно писать только на Си!
    Желательно в виде либ, чтобы было легко растаскивать и встраивать.

    Не понятно как сеть будет защищаться от замусоривания.
    Зачем нужен регистратор, почему нельзя просто подключится к сети и запросить что надо? (клиент)
    Зачем вообще нужен регистратор? (для публикующих)
    Что будет когда место в нулевом-системном кольце закончится?

    Я бы не доверял браузеру хранить закрытый/секретный ключ.


    1. denisskin
      07.09.2015 23:29
      +3

      отвечаю по порядку:

      Такие вещи нужно писать только на Си!
      Желательно в виде либ, чтобы было легко растаскивать и встраивать.
      Согласен. Node.js не совсем подходит для таких вещей. Платформа была выбрана исключительно для того чтобы не дублировать библиотеки на клиенте и сервере. И там и там JavaScript. Впоследствии стало понятно, что нода — далеко не лучшее решение и платформа упирается, как это ни странно, не в сеть или в диск, а в проц. Поскольку для работы с криптографией требуется выполнять много вычислений, и в данном случае больше подходят языки со статической типизацией, такие как, Си.
      Однако, сейчас проект находится скорее в стадии прототипа и для таких вещей нода вполне подходит.
      В будущем есть планы переписать серверную часть на Си или Го. Го в частности подкупает своей простотой создания веб-сервисов, многопоточной архитектурой, оставаясь при этой компилируемым языком со статической типизацией.

      Не понятно как сеть будет защищаться от замусоривания.
      Да. Ограничения от бесконтрольной заливки данных, безусловно, необходимо продумывать. На данный момент уже введены некоторые ограничения:
      1. Объем записей в первых кольцах ограничены небольшим размером. Таким образом, убить сеть сразу одним большим постом не удасться. Чтобы зафлудить систему необходимо будет формировать много мелких записей и файлов, на подпись которых понадобиться также немало ресурсов (в частности подпись отъедает немало процессорного времени). Для проверки времени серверным нодам также понадобиться время.
      2. Стореджи типа D, F, N доступны для записи только пользователям, имеющим подпись регистратора. Таким образом, флудеры будут сразу видны. Потенциально система может формировать черные списки флудеров и игнорировать все посты авторы, которых занесены в этот список.

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

      Зачем нужен регистратор, почему нельзя просто подключится к сети и запросить что надо? (клиент)
      Запрос так и происходит. Клиент подключается к сети и запрашивает то «что надо».
      Зачем вообще нужен регистратор? (для публикующих)
      Регистратор — сейчас нужен исключительно для того чтобы хоть как-то ограничить беспорядочные регистрации доменов пользователями. Фактически регистратор осуществляет эмиссию доменов. Это единственная его функция.
      Опять же, полагаю что регистратор — мера временная и впоследствии от нее удасться избавиться в пользу полностью децентрализованной системы регистрации доменов. Хочу повторить, что проект только в стадии становления

      Что будет когда место в нулевом-системном кольце закончится?
      Сейчас в нулевом кольце (хранилища N) располагается данные о доменах и их владельцах. Своего рода DNS. Клиент, открыв сайт, подключается к сети и запрашивает данные о домене. Он запрашивает данные в нулевом кольце. Как только кольцо переполнится (а это произойдет ой как не скоро) клиент для получения данных о домене будет искать их сперва в нулевом кольце, а затем в первом. Также со временем все данные нулевого кольца можно перетащить в первое, во второе и т.д. Полагаю, к тому времени когда нулевое кольцо переполниться (а это минимум 2 млн.записей), можно будет решить проще поступить, скопировать данные или запрашивать их в одновременно в нескольких кольцах. Уверен, что это далеко не критичная проблема.

      Я бы не доверял браузеру хранить закрытый/секретный ключ.
      Браузер — это самое простое и универсальное клиентское ПО, которое уже установлено у каждого пользователя практически на любой платформе. Не хочется заставлять пользователя ставить какое-то специализированное ПО. Приватный ключ храниться в localStorage всего лишь одного домена (core.base.network). Доступ к нему имеет только один скрипт — API. Скрипты с других доменов не имеют возможность получить этот закрытый ключ.
      На данный момент я не вижу особых проблем в хранении его в браузере. В будущем, с ростом популярности сети можно будет подумать о других методах хранения ключа. Например, установкой специального браузерного плагина.


      1. Ivan_83
        08.09.2015 19:59

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

        GO — хз как такое куда то встраивать.
        Есть GoVPN и автор похоже в одиночку им пользуется.
        Есть Tox, и неожиданно он у меня и в портах на фре и в миранде плагином, и на винде тоже клиент есть.
        Есть libutp у битторента, не уверен что её в изначальном виде целиком встраивают, но дёргать куски из сишного кода куда либо ещё проще.
        Те сишный код можно взять и собрать хоть под TL3020 проксю и оно там спокойно будет пахать.

        Тут лежат мои ECDSA + ГОСТ 2001/2012 и sha2, на сях.
        Просто добавляешь include… и вызываешь нужное. Примеры как вызывать в seltest() функциях.
        http://netlab.linkpc.net/download/software/SDK/core/include/

        А почему не Ed25519 + blake или что то ещё (хэш) от криптоанархистов?)

        «Чтобы зафлудить систему необходимо будет формировать много мелких записей и файлов, на подпись которых понадобиться также немало ресурсов (в частности подпись отъедает немало процессорного времени).» — Мой исходник выше выдавал более 1к в секунду на одном ядре Е8400, на каком нибудь i5 можно выжать до 10к подписей в секунду.
        Я бы не сказал что это мало, скорее при такой скорости процесс упрётся в сеть и тормоза серверов/клиентов на джаве, и даже сях но железе по слабее.
        Не думаю что для мусорных данных нужен правильный хэш.

        Пусть все регистрируют что хотят, кому какое дело?)

        В браузерах дыры, впрочем сейчас всё равно.

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


        1. denisskin
          09.09.2015 13:18

          Есть Tox, и неожиданно он у меня и в портах на фре и в миранде плагином, и на винде тоже клиент есть.
          Есть libutp у битторента, не уверен что её в изначальном виде целиком встраивают, но дёргать куски из сишного кода куда либо ещё проще.

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


        1. denisskin
          09.09.2015 13:18

          Тут лежат мои ECDSA + ГОСТ 2001/2012 и sha2, на сях.
          Просто добавляешь include… и вызываешь нужное. Примеры как вызывать в seltest() функциях.
          Это все классно. Написать на Си небольшую либу, работающую с криптографией. Но если говорить о серверной ноде, которая, по-мимо работы с криптографией, должна еще работать и как веб-сервер, реализовывать все тонкости http-протокола, работать с базой, осуществлять в фоне постоянные репликации с такими же нодами, держать с клиентами SSE-соединения и бог знает еще чего делать, то для простоты разработки, возможно, стоит использовать высокоуровневый язык, который как раз для этого и предназначен? В принципе, GO не сильно уступает по скорости выполнения, также компилируемый, со статической типизацией и пр.


        1. denisskin
          09.09.2015 13:18

          Не думаю что для мусорных данных нужен правильный хэш.

          На сервере каждый хеш проверяется на валидность.


          1. denisskin
            09.09.2015 13:23

            -


        1. denisskin
          09.09.2015 13:24

          В чём отличия от других схожих технологий файлообмена?

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


        1. denisskin
          09.09.2015 13:31

          Нафик слать инвайты почтой, когда тот же токс пашет просто так, из коробки?
          Чтобы использовать сеть не нужны инвайты. Любой (анонимно) может взять и оставить комментарий на сайте. Например, test.base.network/chat
          Инвайт нужен исключительно для регистрации пользователями новых доменов. Это система ограничения бесконтрольной регистрации доменов. Считается что gmail-аккаунтов ограниченное число и изначально (исключительно для представления начальной версии сети) было принято решение ограничить регистрацию доменных имен инвайтами высылаемыми на gmail. на каждый адрес один инвайт.
          В будущем для регистраций доменов могут использоваться и другие ограничители.


        1. denisskin
          09.09.2015 13:38

          Тут лежат мои ECDSA + ГОСТ 2001/2012 и sha2, на сях.
          Иван, я вижу, что ты — отличный спец в криптографии. Не хотел бы ты принять участие в развитии проекта?
          В частности у меня есть некоторые сомнения в функциях кодирования, декодирования данных на клиенте ассиметричным алгоритом. Поскольку я не нашел готовых либ на JavaScript, пришлось писать их самому:
          github.com/basenetwork/client-js/blob/master/lib/base/Certificate.js#L122-L156
          — тут уж извини, только JavaScript, ибо это браузерная логика и Си-шные либы там сложно использовать.


      1. random
        10.09.2015 09:38

        На самом деле нода, а точнее JavaScript — отличный выбор. Это дает возможность реализовать сервер в виде плагина для браузера (в первую очередь, естественно, Chrome), что в свою очередь снимает основное препятствие, мешающее распространению сети — необходимость скачивать и запускать сервер. В качестве бонуса получаем возможность использовать WebRTC в качестве транспорта, со встроенными в него средствами обхода NAT. Это поможет обойти второе препятствие — необходимость серверному узлу иметь белый IP. Криптография не проблема — ее можно реализовать в нативном коде, воспользовавшись window.crypto (в крайнем случае портировать сишный код через NaCL).


  1. spanasik
    07.09.2015 23:30
    +3

    Ожидал увидеть другой стиль изложения и подпись Mithgol


  1. spanasik
    07.09.2015 23:34

    Дабл-пост в чате, хотя честно жал 1 раз всего: i.imgur.com/wF2Nyx4.png
    Возможно, по Enter получается не только перевод строки, но и пост.

    Как зарегистрировать адрес в этой сети?


    1. Haoose
      08.09.2015 00:20

      Если обновить страницу, то второго поста нет. Остается один.


      1. Vinchi
        08.09.2015 13:17

        Да, но это все таки баг в клиенте и надо бы поправить


        1. denisskin
          08.09.2015 14:01
          +1

          ок. спасибо. исправлю


  1. futurelink
    08.09.2015 03:58

    Тема очень интересная и актуальная. Однако остаются кое-какие вопросы:

    1) каким образом выбирается какие данные с каких нод реплицируются и на какие?
    2) при кольцевом устройстве получается, что в итоге связанные сегменты сети территориально будут расположены на одной территории? Исходя из того, что данные реплицируются только в пределах своего кольца.
    3) в сети свободно видны белые адреса нод. У нас такие сейчас замечательные законы, что за то, что у тебя лежит копия запрещенной информации, тебя могут нагнуть. Ты можешь даже и не знать, что она у тебя есть — тебе ее сеть отреплицировала.

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


    1. denisskin
      08.09.2015 14:05

      1. данные реплицируются теми нодами, которые обсулуживают один сегмент.
      например,
      нода-1 обслуживает сегмент D1,D2,D3
      нода-2 обслуживает сегмент D2,D3,D4
      нода-3 обслуживает сегмент D4,D5,D1

      нода-1 и 3 реплицирует между собой сегмент D1
      нода-2 и 3 реплицирует между собой сегмент D4
      нода-1 и 2 реплицирует между собой сегмент D2,D3


    1. denisskin
      08.09.2015 14:07

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


    1. denisskin
      08.09.2015 14:48

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

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


  1. StrangerInRed
    08.09.2015 09:50

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



  1. Vinchi
    08.09.2015 13:08

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


    1. denisskin
      08.09.2015 14:50

      спасибо. исправлю


  1. Vinchi
    08.09.2015 13:16

    и раз уж на base.network клиент — запили там страничку со списком нод. И где API?


  1. grey_rat
    08.09.2015 13:55

    Так список главных нод, точнее их IP, Роскомнадзор внесёт в чёрный список и на этом всё закончится. У 99% всех пользователей IP динамический. В зависимости от провайдера и страны, ситуация с NAT радикально отличается. Если бы вы пытались запустить сугубо территориальный сайт в своей сети у нас в Беларуси, у вас бы ничего не вышло. У нас огромный % пользователей за нат. Даже крупнейший государственный провайдер Белтелеком выдаёт своим ADSL абонентам локальныные IP адреса, а про Ethernet и говорить нечего — практически сплошной нат. Но даже если у человека и белая динамика, то пробрасывать порты для неизвестно кого и чего будет очень малое количество человек. В торрентах пробрасывают для того, что бы качало, а тут для чего? Нужно будет добавлять в программу UPnP и пр.
    Отдавать 4 гига не каждый захочет, тем боле на те сегменты сети/контента которые самому пользоваьелю не нужны.


    1. denisskin
      08.09.2015 15:55

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

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

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


    1. denisskin
      08.09.2015 19:16

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


      1. NickKolok
        08.09.2015 20:21

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


        1. denisskin
          09.09.2015 13:40

          далее децентрализованный аналог Википедии, которую порой пугают прикрыть… )


      1. NickKolok
        08.09.2015 20:49

        И ещё к слову о том, зачем хранить базы. По ним же можно искать! А тот, кто сделает поисковик — тот может и показывать рекламу. Как Гугль. Это уже коммерческий потенциал.


      1. grey_rat
        08.09.2015 20:55

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

        Реклама погубит такие проекты на корню.


      1. NickKolok
        08.09.2015 21:14

        А что насчёт внутренней криптовалюты? Proof-of-Capacity не хватает? Так не проблема. В каждый блок должен быть добавлен фрагмент одного из хранимых файлов (с указанием идентификатора файла и координат фрагмента). Больше файлов храним — быстрее майним. Проблема, правда, будет тогда ли выгодно файлы раздавать?


        1. denisskin
          09.09.2015 13:50

          тут скорее надо думать о чем-то таком как Proof-of-Capacity-per-Second
          мало того, что вы храните данные, важно что вы их еще и раздаете.
          Да. такая система бы подстегнула активнее участников устанавливать ноды и раздавать контент.


          1. NickKolok
            13.09.2015 19:34

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


    1. NickKolok
      08.09.2015 20:24

      Нужна интеграция с I2P и TOR. Дальше — Гиперборея. По моему скромному разумению, модификации серверного ПО минимальны.


  1. NickKolok
    08.09.2015 21:16

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


    1. NickKolok
      08.09.2015 21:29

      Прошу прощения, вероятно, перепутал с WebRTC, по которому работает Firefox Hello.


      1. denisskin
        09.09.2015 13:58

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

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

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


        1. NickKolok
          13.09.2015 19:30

          А можно ли как-то превратить страницу браузера в запущенную p2p-ноду, которая бы тоже раздавала контент?


          1. denisskin
            15.09.2015 19:04

            в будущем, возможно, ДА. можно будет )

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

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


  1. unel
    09.09.2015 19:19

    Очень хорошо! Хотелось бы поддержать проект, как разработчику, только пока непонятно, как именно. Планируется ли какая-нибудь документация, есть ли roadmap по развитию проекта?