Отдавать 4 гига не каждый захочет, тем боле на те сегменты сети/контента которые самому пользоваьелю не нужны.
Сейчас, к примеру, база Bitcoin весит с десяток гигов — и это никого не останавливает скачать ее к себе на диск и использовать для проведения транзакций даже тех «которые самому пользоваьелю не нужны»
%-)
планируется что начальный список нод будет постоянно расти и обновляться в клиентском ПО. если будет доступ хоть к одной из нод, клиент всегда получит свежую карту сети.
для блокировки сеть всеми любимому Роскомнадзору придется мгновенно реагировать на изменения в этом списке.
конечному пользователю для работы сети нет необходимости ставить какой-либо софт — таким образом, сеть в Белоруси будет работать норм.
с установкой новых нод за натом, да — будут проблемы. однако, их можно будет избежать небольшой доработкой серверного софта, о которой я писал чуть выше:
с открытыми IP адресами будут торчать только некие гейты. сами данные будут храниться на клиентских машинах (не имеющие открытых выделенных адресов). эти машины держат постоянный коннект к гейтам и отдают им запрашиваемый контент. таким образом, информация о конечном юзере, у которого храниться контент, есть только у гейтов и недоступна из вне.
чтобы перейти на подобную схему потребуются лишь небольшие доработки серверного ПО.
3. да. всё так. такой вариант, наверное, вполне возможен. установив ноду вы не контролируете заливаемый в нее контент.
конечно, в случае чего, при поступлении жалобы или чего-то такого, администратор всегда может быстренько удалить у себя весь сегмент, в котором находится запрещенный контент.
однако, чтобы таких случае даже и не возникало, есть идея на будущее:
с открытыми IP адресами будут торчать только некие гейты. сами данные будут храниться на клиентских машинах (не имеющие открытых выделенных адресов). эти машины держат постоянный коннект к гейтам и отдают им запрашиваемый контент. таким образом, информация о конечном юзере, у которого храниться контент, есть только у гейтов и недоступна из вне.
чтобы перейти на подобную схему потребуются лишь небольшие доработки серверного ПО.
2. про территориально не совсем понял. ноды никак не привязаны географически. сегменты они выбирают случайно. один сегмент может обслуживаться нодами, которые разделяет океан.
1. данные реплицируются теми нодами, которые обсулуживают один сегмент.
например,
нода-1 обслуживает сегмент D1,D2,D3
нода-2 обслуживает сегмент D2,D3,D4
нода-3 обслуживает сегмент D4,D5,D1
нода-1 и 3 реплицирует между собой сегмент D1
нода-2 и 3 реплицирует между собой сегмент D4
нода-1 и 2 реплицирует между собой сегмент D2,D3
Такие вещи нужно писать только на Си!
Желательно в виде либ, чтобы было легко растаскивать и встраивать.
Согласен. Node.js не совсем подходит для таких вещей. Платформа была выбрана исключительно для того чтобы не дублировать библиотеки на клиенте и сервере. И там и там JavaScript. Впоследствии стало понятно, что нода — далеко не лучшее решение и платформа упирается, как это ни странно, не в сеть или в диск, а в проц. Поскольку для работы с криптографией требуется выполнять много вычислений, и в данном случае больше подходят языки со статической типизацией, такие как, Си.
Однако, сейчас проект находится скорее в стадии прототипа и для таких вещей нода вполне подходит.
В будущем есть планы переписать серверную часть на Си или Го. Го в частности подкупает своей простотой создания веб-сервисов, многопоточной архитектурой, оставаясь при этой компилируемым языком со статической типизацией.
Не понятно как сеть будет защищаться от замусоривания.
Да. Ограничения от бесконтрольной заливки данных, безусловно, необходимо продумывать. На данный момент уже введены некоторые ограничения:
1. Объем записей в первых кольцах ограничены небольшим размером. Таким образом, убить сеть сразу одним большим постом не удасться. Чтобы зафлудить систему необходимо будет формировать много мелких записей и файлов, на подпись которых понадобиться также немало ресурсов (в частности подпись отъедает немало процессорного времени). Для проверки времени серверным нодам также понадобиться время.
2. Стореджи типа D, F, N доступны для записи только пользователям, имеющим подпись регистратора. Таким образом, флудеры будут сразу видны. Потенциально система может формировать черные списки флудеров и игнорировать все посты авторы, которых занесены в этот список.
Опять же, буквально в ближайших планах стоит доработка серверного ПО — добавить ограничения на кол-во записей в секунду от одного автора.
Зачем нужен регистратор, почему нельзя просто подключится к сети и запросить что надо? (клиент)
Запрос так и происходит. Клиент подключается к сети и запрашивает то «что надо».
Зачем вообще нужен регистратор? (для публикующих)
Регистратор — сейчас нужен исключительно для того чтобы хоть как-то ограничить беспорядочные регистрации доменов пользователями. Фактически регистратор осуществляет эмиссию доменов. Это единственная его функция.
Опять же, полагаю что регистратор — мера временная и впоследствии от нее удасться избавиться в пользу полностью децентрализованной системы регистрации доменов. Хочу повторить, что проект только в стадии становления
Что будет когда место в нулевом-системном кольце закончится?
Сейчас в нулевом кольце (хранилища N) располагается данные о доменах и их владельцах. Своего рода DNS. Клиент, открыв сайт, подключается к сети и запрашивает данные о домене. Он запрашивает данные в нулевом кольце. Как только кольцо переполнится (а это произойдет ой как не скоро) клиент для получения данных о домене будет искать их сперва в нулевом кольце, а затем в первом. Также со временем все данные нулевого кольца можно перетащить в первое, во второе и т.д. Полагаю, к тому времени когда нулевое кольцо переполниться (а это минимум 2 млн.записей), можно будет решить проще поступить, скопировать данные или запрашивать их в одновременно в нескольких кольцах. Уверен, что это далеко не критичная проблема.
Я бы не доверял браузеру хранить закрытый/секретный ключ.
Браузер — это самое простое и универсальное клиентское ПО, которое уже установлено у каждого пользователя практически на любой платформе. Не хочется заставлять пользователя ставить какое-то специализированное ПО. Приватный ключ храниться в localStorage всего лишь одного домена (core.base.network). Доступ к нему имеет только один скрипт — API. Скрипты с других доменов не имеют возможность получить этот закрытый ключ.
На данный момент я не вижу особых проблем в хранении его в браузере. В будущем, с ростом популярности сети можно будет подумать о других методах хранения ключа. Например, установкой специального браузерного плагина.
Почему нет информации? Да же если на выходе будет всего два варианта (да/нет), то этот метод будет вполне эффективен. Если есть хоть какая-то корреляция между ответами и конечным результатом, то метод найдет коэффициенты.
Но конечно же, и это вполне очевидно, что для получения более ли менее вменяемого результата понадобиться проводить больше испытаний.
Но вопрос в том что сам метод (как и решение СЛАУ) очень прост. Также уверен что в данном случае он будет значительно эффективнее каких-нибудь генетических алгоритмов в чистом их виде.
Против расплывчатого фитбека на помощь приходит регрессионный анализ. Аналогично, решению СЛАУ, каждый вариант ответа — это случайная величина. Задача сводится к нахождению коэффициентов линейной регрессии, например, методом наименьших квадратов. Это ничуть не сложнее, чем искать решения линейного уравнения. Лично я бы начал писать своих ботов с этого метода.
Отличить же ботовода я предложил бы анализируя время ответа или поведение на сайте (что чуть сложнее).
%-)
для блокировки сеть всеми любимому Роскомнадзору придется мгновенно реагировать на изменения в этом списке.
конечному пользователю для работы сети нет необходимости ставить какой-либо софт — таким образом, сеть в Белоруси будет работать норм.
с установкой новых нод за натом, да — будут проблемы. однако, их можно будет избежать небольшой доработкой серверного софта, о которой я писал чуть выше:
конечно, в случае чего, при поступлении жалобы или чего-то такого, администратор всегда может быстренько удалить у себя весь сегмент, в котором находится запрещенный контент.
однако, чтобы таких случае даже и не возникало, есть идея на будущее:
с открытыми IP адресами будут торчать только некие гейты. сами данные будут храниться на клиентских машинах (не имеющие открытых выделенных адресов). эти машины держат постоянный коннект к гейтам и отдают им запрашиваемый контент. таким образом, информация о конечном юзере, у которого храниться контент, есть только у гейтов и недоступна из вне.
чтобы перейти на подобную схему потребуются лишь небольшие доработки серверного ПО.
например,
нода-1 обслуживает сегмент D1,D2,D3
нода-2 обслуживает сегмент D2,D3,D4
нода-3 обслуживает сегмент D4,D5,D1
нода-1 и 3 реплицирует между собой сегмент D1
нода-2 и 3 реплицирует между собой сегмент D4
нода-1 и 2 реплицирует между собой сегмент D2,D3
Согласен. Node.js не совсем подходит для таких вещей. Платформа была выбрана исключительно для того чтобы не дублировать библиотеки на клиенте и сервере. И там и там JavaScript. Впоследствии стало понятно, что нода — далеко не лучшее решение и платформа упирается, как это ни странно, не в сеть или в диск, а в проц. Поскольку для работы с криптографией требуется выполнять много вычислений, и в данном случае больше подходят языки со статической типизацией, такие как, Си.
Однако, сейчас проект находится скорее в стадии прототипа и для таких вещей нода вполне подходит.
В будущем есть планы переписать серверную часть на Си или Го. Го в частности подкупает своей простотой создания веб-сервисов, многопоточной архитектурой, оставаясь при этой компилируемым языком со статической типизацией.
Да. Ограничения от бесконтрольной заливки данных, безусловно, необходимо продумывать. На данный момент уже введены некоторые ограничения:
1. Объем записей в первых кольцах ограничены небольшим размером. Таким образом, убить сеть сразу одним большим постом не удасться. Чтобы зафлудить систему необходимо будет формировать много мелких записей и файлов, на подпись которых понадобиться также немало ресурсов (в частности подпись отъедает немало процессорного времени). Для проверки времени серверным нодам также понадобиться время.
2. Стореджи типа D, F, N доступны для записи только пользователям, имеющим подпись регистратора. Таким образом, флудеры будут сразу видны. Потенциально система может формировать черные списки флудеров и игнорировать все посты авторы, которых занесены в этот список.
Опять же, буквально в ближайших планах стоит доработка серверного ПО — добавить ограничения на кол-во записей в секунду от одного автора.
Запрос так и происходит. Клиент подключается к сети и запрашивает то «что надо».
Регистратор — сейчас нужен исключительно для того чтобы хоть как-то ограничить беспорядочные регистрации доменов пользователями. Фактически регистратор осуществляет эмиссию доменов. Это единственная его функция.
Опять же, полагаю что регистратор — мера временная и впоследствии от нее удасться избавиться в пользу полностью децентрализованной системы регистрации доменов. Хочу повторить, что проект только в стадии становления
Сейчас в нулевом кольце (хранилища N) располагается данные о доменах и их владельцах. Своего рода DNS. Клиент, открыв сайт, подключается к сети и запрашивает данные о домене. Он запрашивает данные в нулевом кольце. Как только кольцо переполнится (а это произойдет ой как не скоро) клиент для получения данных о домене будет искать их сперва в нулевом кольце, а затем в первом. Также со временем все данные нулевого кольца можно перетащить в первое, во второе и т.д. Полагаю, к тому времени когда нулевое кольцо переполниться (а это минимум 2 млн.записей), можно будет решить проще поступить, скопировать данные или запрашивать их в одновременно в нескольких кольцах. Уверен, что это далеко не критичная проблема.
Браузер — это самое простое и универсальное клиентское ПО, которое уже установлено у каждого пользователя практически на любой платформе. Не хочется заставлять пользователя ставить какое-то специализированное ПО. Приватный ключ храниться в localStorage всего лишь одного домена (core.base.network). Доступ к нему имеет только один скрипт — API. Скрипты с других доменов не имеют возможность получить этот закрытый ключ.
На данный момент я не вижу особых проблем в хранении его в браузере. В будущем, с ростом популярности сети можно будет подумать о других методах хранения ключа. Например, установкой специального браузерного плагина.
Но конечно же, и это вполне очевидно, что для получения более ли менее вменяемого результата понадобиться проводить больше испытаний.
Но вопрос в том что сам метод (как и решение СЛАУ) очень прост. Также уверен что в данном случае он будет значительно эффективнее каких-нибудь генетических алгоритмов в чистом их виде.
Отличить же ботовода я предложил бы анализируя время ответа или поведение на сайте (что чуть сложнее).
— такую регулярку, наверное, все же лучше заменить на: