Да, общался вскользь с создателем патифона. У него много технических проблем вылезло с ipfs вроде, в целом какие-то сложности в разработке. Решил, в общем, оставить пока это дело.
В случаи с musiphone, все под капотом мной написано, даже если что-то пойдет не так, мне проще будет что-то подправить и допилить.
Проблему с пиратством в мире творчества можно решить только изменением отношения людей к этому: постепенного перехода от формата корпораций/лейблов к донатам и коммьюнити. Об этом я в какой-то степени затронул в первой статье из цикла.
На данный момент каждый сам решает как ему поступать: если вы «добропорядочный гражданин», то можете попробовать фильтровать траффик или избегать свободного распространения вовсе. В противном случаи все на ваш страх и риск.
Если изнутри:
Все, что построено на стандартном dht работает по принципу хэш -> данные. То есть поиск осуществляется по хэшу. В моей реализации нет привязки ни к чему, акцент на быстрый обход сети для получения данных, по любым условиям. Детали опишу в следующей статье.
Если снаружи:
Почти ничего общего нет.
Если пройдетесь по предыдущим статьям, то ответ будет полнее.
В следующей статье уже как раз все это распишу. Просто механизм распределения и получения данных один и тот же во всех слоях, не хотелось дублировать все в каждой статье.
В подавляющем большинстве случаев в 1-2 терабайта влезут все MP3-шки, слушаемые человеком за всю жизнь
Все написано, в первую очередь, для программистов. Чтобы любой человек мог создать проект, завязанный на какой-то области (музыка, например) и не париться откуда брать файлы и где их хранить. Мне кажется эту мысль я старался донести с самого начала.
Чем это принципиально отличается от Kademlia и подобных
Вот принципиальное различие как раз в тексте выше. Предложенный вариант удобнее и проще для разработки и написания различных программ. Используя механизм торрентов написать децентрализованный онлайн плеер было бы не самой приятной задачей.
Но ведь это только до того момента, пока сеть под эту конкретную задачу не соберёт достаточное количество пользователей, а дальше случится то же самое?
Давайт просто сравним сложность:
кол-во пользователей vs кол-во пользователей * кол-во проектов
Ну так и рассказали бы про него.
Алгоритм создания сети написан в spreadable. Там и опишу его.
Да, фундаментально, основная идея в том, чтобы совместно наращивать какие-то большие объемы данных, так, чтобы материальные затраты для отдельного участника были незначительные, а общий профит большой.
почему тогда вы ожидаете меньшей нагрузки на ноду?
Потому что, в хранилище ipfs добавляются файлы отовсюду. Если миллионы проектов, никак не связанных друг с другом, используют ipfs, чтобы хранить свои файлы, то когда ты запускаешь свой узел для хранения музыки, через час у тебя весь жесткий диск будет забит разными файлами, не имеющего никакого отношения к твоей задаче. А процессор все это время будет умирать.
В случаи моего подхода, ты просто запускаешь отдельную сеть для каждой конкретной задачи, что существенно снижает нагрузку.
Этот вариант реализуется торрентами.
Торренты очень крутая и нужная тема. Но моя идея не особо конкурирует с торрентами. Реализация сильно отличается и задачи решаются разные. Общее только децентрализация и работа с файлами.
зафлудить DHT
Под капотом не DHT. Реализован другой алгоритм со своими плюсами и минусами. Правда пока ограниченный вариант. Но что касается спама и прочего, то защиты от атак сивиллы полноценной нет ни в одной децентрализованной системе. Где-то больше проблем, где-то меньше. Но если злоумышленник захочет как-то повлиять на сеть, то он сможет это сделать, при наличии мозгов и ресурсов, поскольку возможность запуска подконтрольных узлов и видоизменение их кода не может быть ограничена. Остается только сводить все проблемы от этих атак к минимуму.
Так оно получается проще и надёжнее.
Не для рекламы, а просто, чтобы показать как может быть тоже удобно: museria.com
Я таких проектов не так уж и много знаю. Все либо привязано к криптовалютам, либо слишком специфичное. Можете накидать ссылок, если я упускаю что-то реально интересное.
Отличий я уже много написал в этой и предыдущей статье. Если они не совсем очевидны, то скорее всего нужно просто начать делать что-то конкретное, используя оба варианта.
По поводу спама:
Spreadable (низший слой) содержит механизмы по мониторингу и управлению поведением узлов и клиентов. Их можно расширять и улучшать при необходимости. Через пару статей я опишу это все подробнее.
Что касается текущей библиотеки, то тут нет никакой мета информации, нет названия файла, ничего кроме хэша. Спамить нечего, по сути.
Это немного не про то. Библиотека просто дает возможность самому организовать сеть для хранения файлов (бесплатно разумеется). Как именно человек ею воспользуется уже его дело. Можно создать на основе этого как некоммерческие так и коммерческие решения.
Вы абсолютно правы, только есть один нюанс. Я не из соображений самого умного предложил такое решение. Фиксированная и устанавливаемая цена нам привычна, это да. Потому что тысячи лет люди продавали и покупали товары и услуги, когда интернета еще не было. Возможности доната были крайне ограничены. Сейчас же это становится очень удобным и эффективным. Появились криптовалюты, микротранзакции тоже становятся эффективнее. В общем поезд движется куда-то в эту сторону, могут произойти большие изменения, и я разделяю взгляды таких людей.
Такая мысль была изначально, они и сейчас обдумывается, но вперед пока выходит более простая альтернатива: собирать все донаты и инвестиции и какую-то часть распределять между владельцами узлов. Дело в том что вариант с криптой и плата за скачивание/хранение конечными пользователями может тупо убить спрос.
Это все понятно, но проспамить можно все что угодно. Я могу сейчас сесть и добавить кучу левых песен вконтаке, не соответствующих соодержанию, например. Но все же работает в целом. Такие моменты решаются уже другими инструментами и по мере их появления: контроль ip адресов, ограничения по кол-ву действий за время, модерация и.т.д.
Нет, приоритет и капча реализованы на уровне сети(серверов), а не клиента. А вот как я реализовывал капчу для децентрализованной сети, это уже отдельную статью писать надо )
Я выше уже писал про это. Песни можно сохранять с приоритетами и в режиме модерации. Только человек может сохранить с наивысшим приоритетом, так как в этом режиме надо проходить капчу. То есть если человек добавил песню x с приоритетом 1(максимум), то робот уже не может перезаписать ее, его максимум 0. Только другой человек. Это придумано специально, чтобы система стремилась быть заполненной, в итоге, людьми. Поспамить может и человек, но надо постоянно решать капчу. И для этого случая тоже есть решение, которое возможно будет введено в будущем.
В случаи с musiphone, все под капотом мной написано, даже если что-то пойдет не так, мне проще будет что-то подправить и допилить.
Вроде того, если смотреть с точки зрения пользователя.
На данный момент каждый сам решает как ему поступать: если вы «добропорядочный гражданин», то можете попробовать фильтровать траффик или избегать свободного распространения вовсе. В противном случаи все на ваш страх и риск.
Все, что построено на стандартном dht работает по принципу хэш -> данные. То есть поиск осуществляется по хэшу. В моей реализации нет привязки ни к чему, акцент на быстрый обход сети для получения данных, по любым условиям. Детали опишу в следующей статье.
Если снаружи:
Почти ничего общего нет.
Если пройдетесь по предыдущим статьям, то ответ будет полнее.
В следующей статье уже как раз все это распишу. Просто механизм распределения и получения данных один и тот же во всех слоях, не хотелось дублировать все в каждой статье.
хост:порт. Как там именно организованы диски значения не имеет.Наверху также график стоимости, но логарифмический. На нем лучше видно, что происходит на длительном участке.
Все написано, в первую очередь, для программистов. Чтобы любой человек мог создать проект, завязанный на какой-то области (музыка, например) и не париться откуда брать файлы и где их хранить. Мне кажется эту мысль я старался донести с самого начала.
Вот принципиальное различие как раз в тексте выше. Предложенный вариант удобнее и проще для разработки и написания различных программ. Используя механизм торрентов написать децентрализованный онлайн плеер было бы не самой приятной задачей.
Давайт просто сравним сложность:
кол-во пользователей vs кол-во пользователей * кол-во проектов
Алгоритм создания сети написан в spreadable. Там и опишу его.
Потому что, в хранилище ipfs добавляются файлы отовсюду. Если миллионы проектов, никак не связанных друг с другом, используют ipfs, чтобы хранить свои файлы, то когда ты запускаешь свой узел для хранения музыки, через час у тебя весь жесткий диск будет забит разными файлами, не имеющего никакого отношения к твоей задаче. А процессор все это время будет умирать.
В случаи моего подхода, ты просто запускаешь отдельную сеть для каждой конкретной задачи, что существенно снижает нагрузку.
Торренты очень крутая и нужная тема. Но моя идея не особо конкурирует с торрентами. Реализация сильно отличается и задачи решаются разные. Общее только децентрализация и работа с файлами.
Под капотом не DHT. Реализован другой алгоритм со своими плюсами и минусами. Правда пока ограниченный вариант. Но что касается спама и прочего, то защиты от атак сивиллы полноценной нет ни в одной децентрализованной системе. Где-то больше проблем, где-то меньше. Но если злоумышленник захочет как-то повлиять на сеть, то он сможет это сделать, при наличии мозгов и ресурсов, поскольку возможность запуска подконтрольных узлов и видоизменение их кода не может быть ограничена. Остается только сводить все проблемы от этих атак к минимуму.
Не для рекламы, а просто, чтобы показать как может быть тоже удобно: museria.com
Отличий я уже много написал в этой и предыдущей статье. Если они не совсем очевидны, то скорее всего нужно просто начать делать что-то конкретное, используя оба варианта.
По поводу спама:
Spreadable (низший слой) содержит механизмы по мониторингу и управлению поведением узлов и клиентов. Их можно расширять и улучшать при необходимости. Через пару статей я опишу это все подробнее.
Что касается текущей библиотеки, то тут нет никакой мета информации, нет названия файла, ничего кроме хэша. Спамить нечего, по сути.
Вы абсолютно правы, только есть один нюанс. Я не из соображений самого умного предложил такое решение. Фиксированная и устанавливаемая цена нам привычна, это да. Потому что тысячи лет люди продавали и покупали товары и услуги, когда интернета еще не было. Возможности доната были крайне ограничены. Сейчас же это становится очень удобным и эффективным. Появились криптовалюты, микротранзакции тоже становятся эффективнее. В общем поезд движется куда-то в эту сторону, могут произойти большие изменения, и я разделяю взгляды таких людей.
Такая мысль была изначально, они и сейчас обдумывается, но вперед пока выходит более простая альтернатива: собирать все донаты и инвестиции и какую-то часть распределять между владельцами узлов. Дело в том что вариант с криптой и плата за скачивание/хранение конечными пользователями может тупо убить спрос.
Примерно в этом духе я уже планировал реализовать систему распознавания фейковых трэков. Это пока требует более тщательного анализа.
Это все понятно, но проспамить можно все что угодно. Я могу сейчас сесть и добавить кучу левых песен вконтаке, не соответствующих соодержанию, например. Но все же работает в целом. Такие моменты решаются уже другими инструментами и по мере их появления: контроль ip адресов, ограничения по кол-ву действий за время, модерация и.т.д.
Я выше уже писал про это. Песни можно сохранять с приоритетами и в режиме модерации. Только человек может сохранить с наивысшим приоритетом, так как в этом режиме надо проходить капчу. То есть если человек добавил песню x с приоритетом 1(максимум), то робот уже не может перезаписать ее, его максимум 0. Только другой человек. Это придумано специально, чтобы система стремилась быть заполненной, в итоге, людьми. Поспамить может и человек, но надо постоянно решать капчу. И для этого случая тоже есть решение, которое возможно будет введено в будущем.