Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 12
Какова цена за хранение одного гигабайта данных таким образом и что с доступностью?
Так а какое принципиальное отличие от того же IPFS или от других аналогичных проектов?
Кроме того, самое «узкое» (следовательно, самое интересное) место в проекте, как я уже писал в комментариях к прошлой статье, это борьба со спамом / флудом в таблице «название файла — хэш». Если тут устраивать централизованную модерацию, то это получаются торренты (причём в варианте сайта-форума, а не DHT). А вот децентрализованная модерация — это очень непросто.
Кроме того, самое «узкое» (следовательно, самое интересное) место в проекте, как я уже писал в комментариях к прошлой статье, это борьба со спамом / флудом в таблице «название файла — хэш». Если тут устраивать централизованную модерацию, то это получаются торренты (причём в варианте сайта-форума, а не DHT). А вот децентрализованная модерация — это очень непросто.
Я таких проектов не так уж и много знаю. Все либо привязано к криптовалютам, либо слишком специфичное. Можете накидать ссылок, если я упускаю что-то реально интересное.
Отличий я уже много написал в этой и предыдущей статье. Если они не совсем очевидны, то скорее всего нужно просто начать делать что-то конкретное, используя оба варианта.
По поводу спама:
Spreadable (низший слой) содержит механизмы по мониторингу и управлению поведением узлов и клиентов. Их можно расширять и улучшать при необходимости. Через пару статей я опишу это все подробнее.
Что касается текущей библиотеки, то тут нет никакой мета информации, нет названия файла, ничего кроме хэша. Спамить нечего, по сути.
Отличий я уже много написал в этой и предыдущей статье. Если они не совсем очевидны, то скорее всего нужно просто начать делать что-то конкретное, используя оба варианта.
По поводу спама:
Spreadable (низший слой) содержит механизмы по мониторингу и управлению поведением узлов и клиентов. Их можно расширять и улучшать при необходимости. Через пару статей я опишу это все подробнее.
Что касается текущей библиотеки, то тут нет никакой мета информации, нет названия файла, ничего кроме хэша. Спамить нечего, по сути.
Под решение исходной задачи подходят многие файлообменные сети. Привязка к криптовалютам возникает из идеи, что человек должен быть как-то заинтересован хранить чужие данные. Альтернативой платному хранению может быть, наверное, только «ты хранишь мои данные, а я твои». Отсюда возникает постоянная нагрузка на ноду (которая вам и не понравилась в IPFS). Ну и остаётся вариант, когда кто заинтересован в файле, тот его и хранит. Этот вариант реализуется торрентами. Какой вариант реализует storacle, из статьи я не особо понял. Видимо, как в IPFS, но почему тогда вы ожидаете меньшей нагрузки на ноду? Также очень смущает, что это всё на Node.JS. То есть, получившийся в итоге плеер мне представляется реализованным на Electron, к которому у многих есть определённые претензии.
Мне когда-то тоже приходила в голову мысль сделать музыкальный плеер с распределённым хранением. По результатам размышлений пришёл к выводу, что что-то новое можно послушать в контактике, а если понравилось, то скачать с торрентов и положить в папку «музыка», откуда слушать обычным плеером. Так оно получается проще и надёжнее.
Насчёт «спамить нечего» — пока да. Проблемы там начнутся для поиска по названию композиции. А на этом уровне можно разве что зафлудить DHT, где хранится соответствие хэш -> «адреса» отдающих файл серверов. Из статьи я не понял, как это устроено. И, кстати, я правильно понимаю, что, в отличие от торрентов, файл передаётся целиком, т.е. что нам отдали файл с поддельным хэшем мы узнаем только в самом конце?
Мне когда-то тоже приходила в голову мысль сделать музыкальный плеер с распределённым хранением. По результатам размышлений пришёл к выводу, что что-то новое можно послушать в контактике, а если понравилось, то скачать с торрентов и положить в папку «музыка», откуда слушать обычным плеером. Так оно получается проще и надёжнее.
Насчёт «спамить нечего» — пока да. Проблемы там начнутся для поиска по названию композиции. А на этом уровне можно разве что зафлудить DHT, где хранится соответствие хэш -> «адреса» отдающих файл серверов. Из статьи я не понял, как это устроено. И, кстати, я правильно понимаю, что, в отличие от торрентов, файл передаётся целиком, т.е. что нам отдали файл с поддельным хэшем мы узнаем только в самом конце?
Да, фундаментально, основная идея в том, чтобы совместно наращивать какие-то большие объемы данных, так, чтобы материальные затраты для отдельного участника были незначительные, а общий профит большой.
Потому что, в хранилище ipfs добавляются файлы отовсюду. Если миллионы проектов, никак не связанных друг с другом, используют ipfs, чтобы хранить свои файлы, то когда ты запускаешь свой узел для хранения музыки, через час у тебя весь жесткий диск будет забит разными файлами, не имеющего никакого отношения к твоей задаче. А процессор все это время будет умирать.
В случаи моего подхода, ты просто запускаешь отдельную сеть для каждой конкретной задачи, что существенно снижает нагрузку.
Торренты очень крутая и нужная тема. Но моя идея не особо конкурирует с торрентами. Реализация сильно отличается и задачи решаются разные. Общее только децентрализация и работа с файлами.
Под капотом не DHT. Реализован другой алгоритм со своими плюсами и минусами. Правда пока ограниченный вариант. Но что касается спама и прочего, то защиты от атак сивиллы полноценной нет ни в одной децентрализованной системе. Где-то больше проблем, где-то меньше. Но если злоумышленник захочет как-то повлиять на сеть, то он сможет это сделать, при наличии мозгов и ресурсов, поскольку возможность запуска подконтрольных узлов и видоизменение их кода не может быть ограничена. Остается только сводить все проблемы от этих атак к минимуму.
Не для рекламы, а просто, чтобы показать как может быть тоже удобно: museria.com
почему тогда вы ожидаете меньшей нагрузки на ноду?
Потому что, в хранилище ipfs добавляются файлы отовсюду. Если миллионы проектов, никак не связанных друг с другом, используют ipfs, чтобы хранить свои файлы, то когда ты запускаешь свой узел для хранения музыки, через час у тебя весь жесткий диск будет забит разными файлами, не имеющего никакого отношения к твоей задаче. А процессор все это время будет умирать.
В случаи моего подхода, ты просто запускаешь отдельную сеть для каждой конкретной задачи, что существенно снижает нагрузку.
Этот вариант реализуется торрентами.
Торренты очень крутая и нужная тема. Но моя идея не особо конкурирует с торрентами. Реализация сильно отличается и задачи решаются разные. Общее только децентрализация и работа с файлами.
зафлудить DHT
Под капотом не DHT. Реализован другой алгоритм со своими плюсами и минусами. Правда пока ограниченный вариант. Но что касается спама и прочего, то защиты от атак сивиллы полноценной нет ни в одной децентрализованной системе. Где-то больше проблем, где-то меньше. Но если злоумышленник захочет как-то повлиять на сеть, то он сможет это сделать, при наличии мозгов и ресурсов, поскольку возможность запуска подконтрольных узлов и видоизменение их кода не может быть ограничена. Остается только сводить все проблемы от этих атак к минимуму.
Так оно получается проще и надёжнее.
Не для рекламы, а просто, чтобы показать как может быть тоже удобно: museria.com
совместно наращивать какие-то большие объемы данных, так, чтобы материальные затраты для отдельного участника были незначительные, а общий профит большойМузыка — не настолько большой объём, чтобы там были значительные материальные затраты на хранение. В подавляющем большинстве случаев в 1-2 терабайта влезут все MP3-шки, слушаемые человеком за всю жизнь. При этом нету заморочек типа «интернет-каналу поплохело, музыка заикается» или «раньше слушал такой-то редкий трек, но сейчас его уже нету».
В случаи моего подхода, ты просто запускаешь отдельную сеть для каждой конкретной задачи, что существенно снижает нагрузку.Но ведь это только до того момента, пока сеть под эту конкретную задачу не соберёт достаточное количество пользователей, а дальше случится то же самое?
Но моя идея не особо конкурирует с торрентамиДля слоя хранения в децентрализованной игралке музыки нужен «чёрный ящик», в который скармливается хэш и из которого выходит файл. Плюс некий механизм для сохранения файлов. Чем это принципиально отличается от Kademlia и подобных? Там ведь те же самые задачи.
Под капотом не DHT. Реализован другой алгоритм со своими плюсами и минусами.Ну так и рассказали бы про него. А так, фактически, у вас в статье просто описание API получилось.
Не для рекламы, а просто, чтобы показать как может быть тоже удобно: museria.comВыглядит симпатично. Но нишу этого проекта я воспринимаю как «место, где свалено много музыки, и если мне хочется найти песню N исполнителя X, то я введу название и найду её». А эта ниша уже занята вконтактом. Для повседневного же плеера с идеей «запустил конкретный альбом, и он просто играет» это излишне сложно.
В подавляющем большинстве случаев в 1-2 терабайта влезут все MP3-шки, слушаемые человеком за всю жизнь
Все написано, в первую очередь, для программистов. Чтобы любой человек мог создать проект, завязанный на какой-то области (музыка, например) и не париться откуда брать файлы и где их хранить. Мне кажется эту мысль я старался донести с самого начала.
Чем это принципиально отличается от Kademlia и подобных
Вот принципиальное различие как раз в тексте выше. Предложенный вариант удобнее и проще для разработки и написания различных программ. Используя механизм торрентов написать децентрализованный онлайн плеер было бы не самой приятной задачей.
Но ведь это только до того момента, пока сеть под эту конкретную задачу не соберёт достаточное количество пользователей, а дальше случится то же самое?
Давайт просто сравним сложность:
кол-во пользователей vs кол-во пользователей * кол-во проектов
Ну так и рассказали бы про него.
Алгоритм создания сети написан в spreadable. Там и опишу его.
Я так понимаю, что тут действует принцип «одна нода — один диск» или же есть возможность на одну ноду несколько жестких дисков посадить? Просто если такой принцип имеет место быть — то децентрализации управления то может не оказаться совсем — один узел с кучей дисков погас — и оказалось, что все ноды на нем и висели. Было бы неплохо, как-то разделить ноду и хранилище на мой взгляд.
.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Storacle — децентрализованное хранилище файлов