Комментарии 43
НЛО прилетело и опубликовало эту надпись здесь
отвечаю по порядку:
Однако, сейчас проект находится скорее в стадии прототипа и для таких вещей нода вполне подходит.
В будущем есть планы переписать серверную часть на Си или Го. Го в частности подкупает своей простотой создания веб-сервисов, многопоточной архитектурой, оставаясь при этой компилируемым языком со статической типизацией.
1. Объем записей в первых кольцах ограничены небольшим размером. Таким образом, убить сеть сразу одним большим постом не удасться. Чтобы зафлудить систему необходимо будет формировать много мелких записей и файлов, на подпись которых понадобиться также немало ресурсов (в частности подпись отъедает немало процессорного времени). Для проверки времени серверным нодам также понадобиться время.
2. Стореджи типа D, F, N доступны для записи только пользователям, имеющим подпись регистратора. Таким образом, флудеры будут сразу видны. Потенциально система может формировать черные списки флудеров и игнорировать все посты авторы, которых занесены в этот список.
Опять же, буквально в ближайших планах стоит доработка серверного ПО — добавить ограничения на кол-во записей в секунду от одного автора.
Опять же, полагаю что регистратор — мера временная и впоследствии от нее удасться избавиться в пользу полностью децентрализованной системы регистрации доменов. Хочу повторить, что проект только в стадии становления
На данный момент я не вижу особых проблем в хранении его в браузере. В будущем, с ростом популярности сети можно будет подумать о других методах хранения ключа. Например, установкой специального браузерного плагина.
Такие вещи нужно писать только на Си!Согласен. Node.js не совсем подходит для таких вещей. Платформа была выбрана исключительно для того чтобы не дублировать библиотеки на клиенте и сервере. И там и там JavaScript. Впоследствии стало понятно, что нода — далеко не лучшее решение и платформа упирается, как это ни странно, не в сеть или в диск, а в проц. Поскольку для работы с криптографией требуется выполнять много вычислений, и в данном случае больше подходят языки со статической типизацией, такие как, Си.
Желательно в виде либ, чтобы было легко растаскивать и встраивать.
Однако, сейчас проект находится скорее в стадии прототипа и для таких вещей нода вполне подходит.
В будущем есть планы переписать серверную часть на Си или Го. Го в частности подкупает своей простотой создания веб-сервисов, многопоточной архитектурой, оставаясь при этой компилируемым языком со статической типизацией.
Не понятно как сеть будет защищаться от замусоривания.Да. Ограничения от бесконтрольной заливки данных, безусловно, необходимо продумывать. На данный момент уже введены некоторые ограничения:
1. Объем записей в первых кольцах ограничены небольшим размером. Таким образом, убить сеть сразу одним большим постом не удасться. Чтобы зафлудить систему необходимо будет формировать много мелких записей и файлов, на подпись которых понадобиться также немало ресурсов (в частности подпись отъедает немало процессорного времени). Для проверки времени серверным нодам также понадобиться время.
2. Стореджи типа D, F, N доступны для записи только пользователям, имеющим подпись регистратора. Таким образом, флудеры будут сразу видны. Потенциально система может формировать черные списки флудеров и игнорировать все посты авторы, которых занесены в этот список.
Опять же, буквально в ближайших планах стоит доработка серверного ПО — добавить ограничения на кол-во записей в секунду от одного автора.
Зачем нужен регистратор, почему нельзя просто подключится к сети и запросить что надо? (клиент)Запрос так и происходит. Клиент подключается к сети и запрашивает то «что надо».
Зачем вообще нужен регистратор? (для публикующих)Регистратор — сейчас нужен исключительно для того чтобы хоть как-то ограничить беспорядочные регистрации доменов пользователями. Фактически регистратор осуществляет эмиссию доменов. Это единственная его функция.
Опять же, полагаю что регистратор — мера временная и впоследствии от нее удасться избавиться в пользу полностью децентрализованной системы регистрации доменов. Хочу повторить, что проект только в стадии становления
Что будет когда место в нулевом-системном кольце закончится?Сейчас в нулевом кольце (хранилища N) располагается данные о доменах и их владельцах. Своего рода DNS. Клиент, открыв сайт, подключается к сети и запрашивает данные о домене. Он запрашивает данные в нулевом кольце. Как только кольцо переполнится (а это произойдет ой как не скоро) клиент для получения данных о домене будет искать их сперва в нулевом кольце, а затем в первом. Также со временем все данные нулевого кольца можно перетащить в первое, во второе и т.д. Полагаю, к тому времени когда нулевое кольцо переполниться (а это минимум 2 млн.записей), можно будет решить проще поступить, скопировать данные или запрашивать их в одновременно в нескольких кольцах. Уверен, что это далеко не критичная проблема.
Я бы не доверял браузеру хранить закрытый/секретный ключ.Браузер — это самое простое и универсальное клиентское ПО, которое уже установлено у каждого пользователя практически на любой платформе. Не хочется заставлять пользователя ставить какое-то специализированное ПО. Приватный ключ храниться в localStorage всего лишь одного домена (core.base.network). Доступ к нему имеет только один скрипт — API. Скрипты с других доменов не имеют возможность получить этот закрытый ключ.
На данный момент я не вижу особых проблем в хранении его в браузере. В будущем, с ростом популярности сети можно будет подумать о других методах хранения ключа. Например, установкой специального браузерного плагина.
НЛО прилетело и опубликовало эту надпись здесь
Есть Tox, и неожиданно он у меня и в портах на фре и в миранде плагином, и на винде тоже клиент есть.
Есть libutp у битторента, не уверен что её в изначальном виде целиком встраивают, но дёргать куски из сишного кода куда либо ещё проще.
В данном случае речь идет о клиенте. Клиентские либы сейчас вообще написаны на JavaScript, поскольку клиентом является обычный браузер, других клиентов пока нет. Но планируются…
Тут лежат мои ECDSA + ГОСТ 2001/2012 и sha2, на сях.Это все классно. Написать на Си небольшую либу, работающую с криптографией. Но если говорить о серверной ноде, которая, по-мимо работы с криптографией, должна еще работать и как веб-сервер, реализовывать все тонкости http-протокола, работать с базой, осуществлять в фоне постоянные репликации с такими же нодами, держать с клиентами SSE-соединения и бог знает еще чего делать, то для простоты разработки, возможно, стоит использовать высокоуровневый язык, который как раз для этого и предназначен? В принципе, GO не сильно уступает по скорости выполнения, также компилируемый, со статической типизацией и пр.
Просто добавляешь include… и вызываешь нужное. Примеры как вызывать в seltest() функциях.
Не думаю что для мусорных данных нужен правильный хэш.
На сервере каждый хеш проверяется на валидность.
В чём отличия от других схожих технологий файлообмена?
Ну, это же не система файлообмена. это система с динамическим контентом. Сайт в base.network — это же не набор статических файлов. это же система с динамически генерируемым контентом. В этом и основное отличие. Что на базе системы можно строить динамические сайты, с произвольным функционалом, собственные мобильные приложения, и даже соц.сети не уступающие своим централизованным аналогам.
Нафик слать инвайты почтой, когда тот же токс пашет просто так, из коробки?Чтобы использовать сеть не нужны инвайты. Любой (анонимно) может взять и оставить комментарий на сайте. Например, test.base.network/chat
Инвайт нужен исключительно для регистрации пользователями новых доменов. Это система ограничения бесконтрольной регистрации доменов. Считается что gmail-аккаунтов ограниченное число и изначально (исключительно для представления начальной версии сети) было принято решение ограничить регистрацию доменных имен инвайтами высылаемыми на gmail. на каждый адрес один инвайт.
В будущем для регистраций доменов могут использоваться и другие ограничители.
Тут лежат мои ECDSA + ГОСТ 2001/2012 и sha2, на сях.Иван, я вижу, что ты — отличный спец в криптографии. Не хотел бы ты принять участие в развитии проекта?
В частности у меня есть некоторые сомнения в функциях кодирования, декодирования данных на клиенте ассиметричным алгоритом. Поскольку я не нашел готовых либ на JavaScript, пришлось писать их самому:
github.com/basenetwork/client-js/blob/master/lib/base/Certificate.js#L122-L156
— тут уж извини, только JavaScript, ибо это браузерная логика и Си-шные либы там сложно использовать.
На самом деле нода, а точнее JavaScript — отличный выбор. Это дает возможность реализовать сервер в виде плагина для браузера (в первую очередь, естественно, Chrome), что в свою очередь снимает основное препятствие, мешающее распространению сети — необходимость скачивать и запускать сервер. В качестве бонуса получаем возможность использовать WebRTC в качестве транспорта, со встроенными в него средствами обхода NAT. Это поможет обойти второе препятствие — необходимость серверному узлу иметь белый IP. Криптография не проблема — ее можно реализовать в нативном коде, воспользовавшись window.crypto (в крайнем случае портировать сишный код через NaCL).
Ожидал увидеть другой стиль изложения и подпись Mithgol
Дабл-пост в чате, хотя честно жал 1 раз всего: i.imgur.com/wF2Nyx4.png
Возможно, по Enter получается не только перевод строки, но и пост.
Как зарегистрировать адрес в этой сети?
Возможно, по Enter получается не только перевод строки, но и пост.
Как зарегистрировать адрес в этой сети?
Тема очень интересная и актуальная. Однако остаются кое-какие вопросы:
1) каким образом выбирается какие данные с каких нод реплицируются и на какие?
2) при кольцевом устройстве получается, что в итоге связанные сегменты сети территориально будут расположены на одной территории? Исходя из того, что данные реплицируются только в пределах своего кольца.
3) в сети свободно видны белые адреса нод. У нас такие сейчас замечательные законы, что за то, что у тебя лежит копия запрещенной информации, тебя могут нагнуть. Ты можешь даже и не знать, что она у тебя есть — тебе ее сеть отреплицировала.
И, как уже написали выше — нет системы рейтингования контента, чистки реплик, что может привести к замусориванию.
1) каким образом выбирается какие данные с каких нод реплицируются и на какие?
2) при кольцевом устройстве получается, что в итоге связанные сегменты сети территориально будут расположены на одной территории? Исходя из того, что данные реплицируются только в пределах своего кольца.
3) в сети свободно видны белые адреса нод. У нас такие сейчас замечательные законы, что за то, что у тебя лежит копия запрещенной информации, тебя могут нагнуть. Ты можешь даже и не знать, что она у тебя есть — тебе ее сеть отреплицировала.
И, как уже написали выше — нет системы рейтингования контента, чистки реплик, что может привести к замусориванию.
1. данные реплицируются теми нодами, которые обсулуживают один сегмент.
например,
нода-1 обслуживает сегмент D1,D2,D3
нода-2 обслуживает сегмент D2,D3,D4
нода-3 обслуживает сегмент D4,D5,D1
нода-1 и 3 реплицирует между собой сегмент D1
нода-2 и 3 реплицирует между собой сегмент D4
нода-1 и 2 реплицирует между собой сегмент D2,D3
например,
нода-1 обслуживает сегмент D1,D2,D3
нода-2 обслуживает сегмент D2,D3,D4
нода-3 обслуживает сегмент D4,D5,D1
нода-1 и 3 реплицирует между собой сегмент D1
нода-2 и 3 реплицирует между собой сегмент D4
нода-1 и 2 реплицирует между собой сегмент D2,D3
2. про территориально не совсем понял. ноды никак не привязаны географически. сегменты они выбирают случайно. один сегмент может обслуживаться нодами, которые разделяет океан.
3. да. всё так. такой вариант, наверное, вполне возможен. установив ноду вы не контролируете заливаемый в нее контент.
конечно, в случае чего, при поступлении жалобы или чего-то такого, администратор всегда может быстренько удалить у себя весь сегмент, в котором находится запрещенный контент.
однако, чтобы таких случае даже и не возникало, есть идея на будущее:
с открытыми IP адресами будут торчать только некие гейты. сами данные будут храниться на клиентских машинах (не имеющие открытых выделенных адресов). эти машины держат постоянный коннект к гейтам и отдают им запрашиваемый контент. таким образом, информация о конечном юзере, у которого храниться контент, есть только у гейтов и недоступна из вне.
чтобы перейти на подобную схему потребуются лишь небольшие доработки серверного ПО.
конечно, в случае чего, при поступлении жалобы или чего-то такого, администратор всегда может быстренько удалить у себя весь сегмент, в котором находится запрещенный контент.
однако, чтобы таких случае даже и не возникало, есть идея на будущее:
с открытыми IP адресами будут торчать только некие гейты. сами данные будут храниться на клиентских машинах (не имеющие открытых выделенных адресов). эти машины держат постоянный коннект к гейтам и отдают им запрашиваемый контент. таким образом, информация о конечном юзере, у которого храниться контент, есть только у гейтов и недоступна из вне.
чтобы перейти на подобную схему потребуются лишь небольшие доработки серверного ПО.
НЛО прилетело и опубликовало эту надпись здесь
Уже есть github.com/HelloZeroNet/ZeroNet
В клиент при добавлении комментария в блок — он дублируется, после перезагрузки исчезает.
и раз уж на base.network клиент — запили там страничку со списком нод. И где API?
Так список главных нод, точнее их IP, Роскомнадзор внесёт в чёрный список и на этом всё закончится. У 99% всех пользователей IP динамический. В зависимости от провайдера и страны, ситуация с NAT радикально отличается. Если бы вы пытались запустить сугубо территориальный сайт в своей сети у нас в Беларуси, у вас бы ничего не вышло. У нас огромный % пользователей за нат. Даже крупнейший государственный провайдер Белтелеком выдаёт своим ADSL абонентам локальныные IP адреса, а про Ethernet и говорить нечего — практически сплошной нат. Но даже если у человека и белая динамика, то пробрасывать порты для неизвестно кого и чего будет очень малое количество человек. В торрентах пробрасывают для того, что бы качало, а тут для чего? Нужно будет добавлять в программу UPnP и пр.
Отдавать 4 гига не каждый захочет, тем боле на те сегменты сети/контента которые самому пользоваьелю не нужны.
Отдавать 4 гига не каждый захочет, тем боле на те сегменты сети/контента которые самому пользоваьелю не нужны.
планируется что начальный список нод будет постоянно расти и обновляться в клиентском ПО. если будет доступ хоть к одной из нод, клиент всегда получит свежую карту сети.
для блокировки сеть всеми любимому Роскомнадзору придется мгновенно реагировать на изменения в этом списке.
конечному пользователю для работы сети нет необходимости ставить какой-либо софт — таким образом, сеть в Белоруси будет работать норм.
с установкой новых нод за натом, да — будут проблемы. однако, их можно будет избежать небольшой доработкой серверного софта, о которой я писал чуть выше:
для блокировки сеть всеми любимому Роскомнадзору придется мгновенно реагировать на изменения в этом списке.
конечному пользователю для работы сети нет необходимости ставить какой-либо софт — таким образом, сеть в Белоруси будет работать норм.
с установкой новых нод за натом, да — будут проблемы. однако, их можно будет избежать небольшой доработкой серверного софта, о которой я писал чуть выше:
с открытыми IP адресами будут торчать только некие гейты. сами данные будут храниться на клиентских машинах (не имеющие открытых выделенных адресов). эти машины держат постоянный коннект к гейтам и отдают им запрашиваемый контент. таким образом, информация о конечном юзере, у которого храниться контент, есть только у гейтов и недоступна из вне.
чтобы перейти на подобную схему потребуются лишь небольшие доработки серверного ПО.
Отдавать 4 гига не каждый захочет, тем боле на те сегменты сети/контента которые самому пользоваьелю не нужны.Сейчас, к примеру, база Bitcoin весит с десяток гигов — и это никого не останавливает скачать ее к себе на диск и использовать для проведения транзакций даже тех «которые самому пользоваьелю не нужны»
%-)
Всё-таки тематические блоки, возможно, имели бы смысл. Например, сейчас есть такая проблема — т. наз. фанфики авторам приходится прятать от незарегистрированных пользователей из боязни роскомпозоров. Не исключено, что сообщество фикописателей с энтузиазмом воспримет идею поднять соответствующие ноды. Далее — децентрализованный аналог Хабра…
И ещё к слову о том, зачем хранить базы. По ним же можно искать! А тот, кто сделает поисковик — тот может и показывать рекламу. Как Гугль. Это уже коммерческий потенциал.
Практика китайских блокировок показывает, что при большом желании можно оперативно следить и закрывать вновь появляющиеся лазейки.
Список нод можно получить так же в локальной сети мультикастом, если провайдер его не блокирует, например как сделано в торрент-клиентах «Поиск локальных пиров».
Bitcoin это скорее пока гиковский проект, с возможностью, хоть и условной, материальной выгоды. Простой пользователь скорее всего задаст себе вопрос: «зачем мне i2p и прочие костыли, когда и так всё пока работает ?»
Реклама погубит такие проекты на корню.
Список нод можно получить так же в локальной сети мультикастом, если провайдер его не блокирует, например как сделано в торрент-клиентах «Поиск локальных пиров».
Bitcoin это скорее пока гиковский проект, с возможностью, хоть и условной, материальной выгоды. Простой пользователь скорее всего задаст себе вопрос: «зачем мне i2p и прочие костыли, когда и так всё пока работает ?»
Реклама погубит такие проекты на корню.
А что насчёт внутренней криптовалюты? Proof-of-Capacity не хватает? Так не проблема. В каждый блок должен быть добавлен фрагмент одного из хранимых файлов (с указанием идентификатора файла и координат фрагмента). Больше файлов храним — быстрее майним. Проблема, правда, будет тогда ли выгодно файлы раздавать?
Нужна интеграция с I2P и TOR. Дальше — Гиперборея. По моему скромному разумению, модификации серверного ПО минимальны.
А что насчёт WebSockets? Может быть, получится превратить пользовательскую ноду к хоть какой-то промежуточный узел кэширования? Хоть для запрошенного ей контента?
Прошу прощения, вероятно, перепутал с WebRTC, по которому работает Firefox Hello.
да. идея есть. это как раз о чем я и писал в статье. потенциально функционал сети можно расширять новыми типами стореджей.
например сторедж, через который будут раздаваться подписчикам медийные потоки (скажем, через WebRTC).
или например, сторедж, который хранит файлы лишь временно — своего рода кеш файлов. один пользователь залил файл, его скачали остальные, через какое-то время файл удалился.
или сторедж который на диске вообще ничего не хранит, а является своего рода огромным мемкешом. очень будет полезен для передачи каких-то второстепенных данных: онлайн/не онлайн, различных статусов, например, «Юзер печатает вам сообщение...»
например сторедж, через который будут раздаваться подписчикам медийные потоки (скажем, через WebRTC).
или например, сторедж, который хранит файлы лишь временно — своего рода кеш файлов. один пользователь залил файл, его скачали остальные, через какое-то время файл удалился.
или сторедж который на диске вообще ничего не хранит, а является своего рода огромным мемкешом. очень будет полезен для передачи каких-то второстепенных данных: онлайн/не онлайн, различных статусов, например, «Юзер печатает вам сообщение...»
А можно ли как-то превратить страницу браузера в запущенную p2p-ноду, которая бы тоже раздавала контент?
в будущем, возможно, ДА. можно будет )
В недалеких планах доработать клиентскую логику так чтобы она работала, как серверная нода и обслуживала хотя бы один сегмент данных.
Клиенты, даже те которые находятся за NATом, будут коннектиться к серверным нодам, сообщать им о себе, какие сегменты они обслуживают, реплицировать данные, и по запросу сервера возвращать их. Планируется что данные на клиенте будут храниться в IndexedDB, который позволяет выделить пространство даже в несколько гигобайт.
Однако, надо иметь ввиду что при подобной схеме хранения, доступ к данным будет происходить с чуть большими задержками по времени.
В недалеких планах доработать клиентскую логику так чтобы она работала, как серверная нода и обслуживала хотя бы один сегмент данных.
Клиенты, даже те которые находятся за NATом, будут коннектиться к серверным нодам, сообщать им о себе, какие сегменты они обслуживают, реплицировать данные, и по запросу сервера возвращать их. Планируется что данные на клиенте будут храниться в IndexedDB, который позволяет выделить пространство даже в несколько гигобайт.
Однако, надо иметь ввиду что при подобной схеме хранения, доступ к данным будет происходить с чуть большими задержками по времени.
Очень хорошо! Хотелось бы поддержать проект, как разработчику, только пока непонятно, как именно. Планируется ли какая-нибудь документация, есть ли roadmap по развитию проекта?
А test.base.network, к сожалению, не работает. В чём причина?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Пиринговая сеть base.network