Comments 103
Я уже боялся, что про г-т фидонет ничего не будет.
В конце блогозаписи про юбилей Фидонета был тизер-трейлер про внедрение IPFS в Фидонете, так что вот теперь я раскрыл ту тему, на которую тогда намекал.
Несомненно, ключевым аргументом ipfs в статье смотрится фрагмент конфига Голого Деда. Куда же сейчас без него!
При всем моем уважении, упоминанине Фидонета в подобных случаях выглядит как проявление некоей латентной некрофилии. Сильно плохого в этом ничего нет, однако, рецидивы настораживают.
Искренне ваш,
ex. 2:5070/44
При всем моем уважении, упоминанине Фидонета в подобных случаях выглядит как проявление некоей латентной некрофилии. Сильно плохого в этом ничего нет, однако, рецидивы настораживают.
Искренне ваш,
ex. 2:5070/44
Спасибо. Интересная альтернатива чистому p2p интернету, в котором будет работать только статика нормально. В этом варианте можно использовать смешанное содержимое, которое позволит снять часть нагрузки.
— Хэш файла зависит только от содержимого файла. Если файл имеет другое имя или лежит в другом подкаталоге, то это всё равно тот же файл. (Это выгодно отличается, например, от битторрентовского хэша BTIH, который изменяется в зависимости от названия и взаимного расположения файлов.) Если тот же самый файл раздаётся под другим именем или в составе другого подкаталога, раздачи автоматически объединятся, не потребуется удвоение усилий, траффика, пространства на диске.
Я немного совершенно не понял — как они собираются бороться с коллизиями?
Там очень большие хеши. Боюсь, что вероятность коллизии будет много ниже вероятности того, что, например, упомянутого крупного диктора просто собьет машина на улице…
Тем не менее вероятность !=0.
Случайно может будут редкие совпадения. Но с теми же хешами есть разные варианты атак, поэтому важна криптостойкость, а не только длина.
Случайно может будут редкие совпадения. Но с теми же хешами есть разные варианты атак, поэтому важна криптостойкость, а не только длина.
В таком случае вам не рекомендуется использовать гуиды во всех проявлениях.
Кто-то использует guid как криптоподпись?
Как ID в распределенной системе — легко. А к чему может привести коллизия уникальных идентификаторов — кто знает, от простой пропажи одной записи в БД до отказа в обслуживании и сливания всей инфы на сторону.
Как id — понятно.
А вот как подпись?
Во, т кстати, совсем скоро увидим коллизиии — habrahabr.ru/post/268495
То есть подменить файл и чисто количественно задавить раздачу вполне реально.
Но еще лучше подменить адреса машин, откуда узлы должны узнавать друг про друга — т.е. просто развалить сеть на части.
А вот как подпись?
Во, т кстати, совсем скоро увидим коллизиии — habrahabr.ru/post/268495
То есть подменить файл и чисто количественно задавить раздачу вполне реально.
Но еще лучше подменить адреса машин, откуда узлы должны узнавать друг про друга — т.е. просто развалить сеть на части.
На всякий случай сообщаю, что по адресу http://habrahabr.ru/post/268495/ речь идёт о поиске коллизий в SHA-1, тогда как IPFS, во-первых, использует более современный хэш SHA-2, а во-вторых, употребляет вокруг него такую обёртку (в виде мультихэша), которая позволит в случае необходимости перейти (по общему согласию) от употребления SHA-2 к употреблению ещё более современного хэша, вовсе не трогая остальную логику работы системы (и, весьма вероятно, с некоторым переходным периодом, когда оба хэша будут приниматься к употреблению, но только более новый будет создаваться для дальнейшего употребления).
Получается при заходе на страницу я ее буду качать и хранить у себя как некий кэш, который у меня потом могут взять другие или файл. OK
Что делать если у меня мало место?
При изменении динамики, насколько быстро распространится изменения.
Будет ли полная перекачка файла или только изменения файла?
Как распределяются права к файлам? Можно ли сделать больше одного человека, который имеет RW права на папку?
Как быть, если кто-то удалил все файлы в каталоге или сам каталог?
Как быть с коллизиями?
Что делать если у меня мало место?
При изменении динамики, насколько быстро распространится изменения.
Будет ли полная перекачка файла или только изменения файла?
Как распределяются права к файлам? Можно ли сделать больше одного человека, который имеет RW права на папку?
Как быть, если кто-то удалил все файлы в каталоге или сам каталог?
Как быть с коллизиями?
Если Вы простой посетитель с одним только браузером, то Вы просто скачаете картинку через гейт по обычному http.
Чтобы получить p2p, нужно ставить локальный софт. Очевидно, что настройки объема локального хранилища там должны быть.
Чтобы получить p2p, нужно ставить локальный софт. Очевидно, что настройки объема локального хранилища там должны быть.
Мало места — мало кэша.
Изменения динамики распространяются по мере повторных заходов.
Будет полная перекачка файла.
Никто не имеет RW-права на папку, потому что по факту там WORM: изменённые файлы и папки рассматриваются как новые.
Коллизий нет.
Изменения динамики распространяются по мере повторных заходов.
Будет полная перекачка файла.
Никто не имеет RW-права на папку, потому что по факту там WORM: изменённые файлы и папки рассматриваются как новые.
Коллизий нет.
Коллизий нет.
Это невозможно. Коллизии могут быть маловероятными, но совсем исключить вы их не можете.
Там хэшем служит SHA2-256, то есть, как я понимаю, 32-байтовое (256-битовое) число.
Вероятность коллизий ничтожна (что-то порядка квадратного корняиз 10−77, если я это правильно понимаю), так что я не верю, что они есть.
Вероятность коллизий ничтожна (что-то порядка квадратного корня
Вероятность коллизии в 0.5 достигается после 4 × 1038 файлов (да здравствует «парадокс» дней рождений). Называть это ничтожным я бы не стал.
Ну да, именно из-за парадокса дней рождений я и заговорил именно о квадратном корне.
А что касается 4×1038(2128) файлов, то это очень много. Рассудим теоретически:
так что если у нас есть 2128 различных файлов, то их длина варьируется (по меньшей мере) от битадо 264 битов, причём файлов размером 264 битов около половины, так что и средняя длина где-то там.
Следовательно, суммарный размер этих файлов —что-то около 2128×264 битов = 2192 битов = 2189 байтов = 2179 килобайтов = 2169 мегабайтов = 2159 гигабайтов = 2149 терабайтов = 2139 петабайтов = 2129 эксабайтов = 2119 зеттабайтов = 2109 иоттабайтов… дальше понятно.
А что касается 4×1038
- для записи одного из двух различных файлов достаточно однобитной длины,
- длина файла от одного до двух битов позволяет записать один из 21+2² различных файлов,
- длина файла от одного до трёх битов позволяет записать один из 21+2²+2³ различных файлов,
так что если у нас есть 2128 различных файлов, то их длина варьируется (по меньшей мере) от бита
Следовательно, суммарный размер этих файлов —
Хотя нет, что это я несу. Последние два абзаца предыдущего рассуждения на самом деле должны были быть вот какими:
…так что если у нас есть 2128 различных файлов, то их длина варьируется (по меньшей мере) от битадо 64 битов, причём файлов размером 64 бита (26 битов) около половины, так что и средняя длина где-то там.
Следовательно, суммарный размер этих файлов —что-то около 2128×26 битов = 2134 битов = 2131 байтов = 2121 килобайтов = 2111 мегабайтов = 2101 гигабайтов = 291 терабайтов = 281 петабайтов = 271 эксабайтов = 261 зеттабайтов = 251 иоттабайтов… дальше понятно.
…так что если у нас есть 2128 различных файлов, то их длина варьируется (по меньшей мере) от бита
Следовательно, суммарный размер этих файлов —
Допустим, вероятность случайных коллизий настолько низка, что можно не беспокоиться об этом. А как IPFS защищается от флуда специально созданными мусорными файлами, в которых подобран хэш какого-нибудь полезного (или неугодного кому-то) файла?
Ну тогда тут вопрос спорный, зачем оно надо. Гложут сомнения что это взлетит.
Минимум — защита от цензуры.
Насчет цензуры есть несколько вопросов. Протокол ведь будет отдавать IP адреса всех, у кого есть этот контент? Всех можно и взять будет (до кого дотянутся) за распространение. И второе, про гейт. Гейт отдает только IP адреса централизованно?
Для этого лучше подходят мех сети и я думаю лучше их развивать. Например Cjdns. hyperboria.net
Имхо, одно другому не мешает. Кеширование статики может работать как поверх обычного интернете так и поверх CJDNS — ведь она по сути придоставляет IPv6. Параноики могут раздавать кеш только через интерфейс tun от cjdns. В идеале бы людям, которые способны установить одно, ставить и другое, но для того как раз раскручивание на хабре. Надеюсь, когда тут был цикл статей о меш сетях, многие не поленились и поставили ноду (тем более под убунту это ставится из пакетов). Я еще купил и прошил роутер под это дело и жду соседей (:
Сегодня нашел время и поставил ipfs, если можно так выразиться: приложение на го — это один исполняемый файл, который надо только положить и запустить. В общем, оно работает и радует, и тут же через мой CJDNS подхватилось пять пиров сразу без ручного поиска. Т.е., как я и предполагал, есть те, кто осилил и то и это. (:
Никаких изменений. Любое изменение = новый файл.
Как я понял, используется «Git Merkle DAG 2 object model» и при изменении файла будет скачивание только изменений, а не всего нового файла.
Получается при заходе на страницу я ее буду качать и хранить у себя как некий кэш, который у меня потом могут взять другие или файл. OK
Что делать если у меня мало место?
Можно регулировать, сколько места отдавать под кэш. Или по аналогии с тонкими bitcoin-клиентами вообще ничего не сохранять на диск.
При изменении динамики, насколько быстро распространится изменения.
Динамика хранится в виде изменяющихся ссылок на статику в системе IPNS (IP Naming System), как ref'ы в Git. Изменения в них распространяются не мгновенно, но являются атомарными, т.е. если выложить новую версию сайта, хэш его корневого элемента будет новым, и новую версию увидят только те пользователи, которые получат новое значение через IPNS.
Конечно, сайт может ссылаться не только на объекты IPFS, но и на записи в IPNS, но это разбивает его на несколько атомарных частей, так что с этим надо быть аккуратней.
Будет ли полная перекачка файла или только изменения файла?
Любой файл может быть представлен как одним объектом, так и набором подобъектов. Так что всегда целиком будет перекачиваться основной объект файла (список подобъектов), но подобъекты будут скачиваться только те, которые изменились. Так, например, можно разбить видео на эпизоды, и ретушь одного эпизода не вызовет перекачку всего видео.
Как распределяются права к файлам? Можно ли сделать больше одного человека, который имеет RW права на папку?
В IPFS единственное понятие, на которое распространяются права — это запись в IPNS. Менять её может только владелец ключа шифрования, которым эта запись адресуется. Они планируют что-то поменять, чтобы можно было одним ключом менять несколько записей в IPNS, но я не видел, чтобы они хотели дать возможность менять одну запись несколькими ключами (что печально и сильно ограничивает область применения).
Как быть, если кто-то удалил все файлы в каталоге или сам каталог?
IPFS хочет заменить интернет (ну почти), а что попало в интернет, как известно, не вырубишь и
Как быть с коллизиями?
Не париться по их поводу пока, менять алгоритмы хэширования потом, см. другие комменты.
Присматривался к ipfs для раздачи статики на своем сайте. Остановило неумение раздавать целые каталоги прямо с диска. Т.е. мне для раздачи нужно каждый файл залить в локальное хранилище ipfs и по факту имеет две копии: одна копия в обычной fs (ибо ipfs не обеспечивает весь локальный функционал), вторая — в ipfs. Когда файлов — сотни гигабайт, такое дублирование становится расточительным и бессмысленным :—/
А в остальном система очень понравилась. Ещё бы чисто браузерную реализацию (js, webrtc), чтобы простой юзер мог бы качать минуя гейт, но при этом не устанавливая дополнительный софт, цены б ей не было :)
А в остальном система очень понравилась. Ещё бы чисто браузерную реализацию (js, webrtc), чтобы простой юзер мог бы качать минуя гейт, но при этом не устанавливая дополнительный софт, цены б ей не было :)
Работы над изготовлением реализации IPFS на языке JavaScript ведутся потихоньку.
А что мне мешает на гигабитном канале сделать dd if=/dev/urandom of=/ipfs/flood_file bs=1G count=1000000 и уложить всю сеть?
А кто будет ЭТО качать? p2p — это не когда тебе подсовывают всё, что не нужно. Это когда ты у других берёшь то, что нужно.
Так если оно не дублицируется, тогда зачем нужно. Ну и атаку на хештаблицу можно устроить так же.
ipfs — это не распределённое хранилище. Это распределённый транспортный протокол с попутным кешированием. p2p-транспорты не менее, а скорее более востребованы, чем [анонимные] p2p-хранилища.
Ну и получим мы в итоге, что будет кэш только самого популярного и востребованного. Мы это и наблюдаем в текущий реализации торрентов, когда нужно скачать что-то и сидишь ждешь когда появится кто-то у кого оно есть.
Но подход понятен, это как у MS с обновлениями по P2P, хочешь не хочешь а будишь раздавать.
Но подход понятен, это как у MS с обновлениями по P2P, хочешь не хочешь а будишь раздавать.
О-о-о, т.е. это совершенно не замена тому же tahoe-lafs?
Нет. Tahoe — это хранилище. IPFS — транспорт (хотя и с локальным кеш-хранилищем, но не распределённым, как tahoe). В принципе, они могут быть хоть совмещены. tahoe как средство распределённого хранения, а ipfs — транспорт для передачи клиенту (не требующий, в отличие от tahoe установки клиента)
ipfs — транспорт для передачи клиенту (не требующий, в отличие от tahoe установки клиента)
Это же только если пользоваться чьим-то уже развернутым гейтом?
Ещё есть IPFS.JS загружается и работает в браузере.
Все хорошо в этом переводе, кроме стилистики, которая забирает на себя больше внимания, чем следовало бы.
Мне казалось или в p2p сетях обычно долгое ожидание начала загрузки? Если они не решат эту проблему, то протокол уже мертв.
Экономия трафика — прекрасно, но не в ущерб скорости загрузки.
Экономия трафика — прекрасно, но не в ущерб скорости загрузки.
+1
Пока дождешься установления соединения, потеряется всякий интерес к старнице.
Многие исследования говорят, что если веб-страница не загрузилась за 3-5секунд, то среднестатистический пользователь её закрывает.
Протокол уже мертв.
Про кэширование на устройстве: ну незнаю, насколько это хорошая идея, ведь есть сайты, на которых контент меняется очень-очень часто — всякие чаты, доски обновлений, популярные форумы. Кэширование будет создавать эффект, что на этом сайте ничего не происходит, выдвигаемый контент будет опаздывать, итд итп. Да, сайт может поставить какой-нибудь псевдо-флаг «не кэшировать», но тогда теряется вся суть «СПАСИТЕЛЯ ИНТЕРНЕТА». Я молчу про то, больше половины пользователй интернета сидят с телефонов и планшетов.
Насчет Ддос: всю тяжесть ддосов будут нести не владельцы сайтов, а пользователи, на которых схэшировалось довольно много файлов. Если у пользователя узкий канал, или он играет в онлайн игры, или у него нет SSD, то всё для него будет весьма печально- страницы будут загружаться медленнее из-за высокой отдачи, онлайн-игры будут лагать и вырастут пинги, если всё у пользователя крутится на одном HDD то о нормальной работе на ПК можно забыть — HDD будет постоянно занят, снижая свою производительность, т.е. все программы будут запускаться гораздо дольше.
«И всё ради чего?» -спросит себя пользователь, и снесет всю эту лабуду, чтобы нормально пользоваться СВОИМ компьютером, а не для того, чтобы всякие владельцы сайтов снижали с себя расходы.
Пока дождешься установления соединения, потеряется всякий интерес к старнице.
Многие исследования говорят, что если веб-страница не загрузилась за 3-5секунд, то среднестатистический пользователь её закрывает.
Протокол уже мертв.
Про кэширование на устройстве: ну незнаю, насколько это хорошая идея, ведь есть сайты, на которых контент меняется очень-очень часто — всякие чаты, доски обновлений, популярные форумы. Кэширование будет создавать эффект, что на этом сайте ничего не происходит, выдвигаемый контент будет опаздывать, итд итп. Да, сайт может поставить какой-нибудь псевдо-флаг «не кэшировать», но тогда теряется вся суть «СПАСИТЕЛЯ ИНТЕРНЕТА». Я молчу про то, больше половины пользователй интернета сидят с телефонов и планшетов.
Насчет Ддос: всю тяжесть ддосов будут нести не владельцы сайтов, а пользователи, на которых схэшировалось довольно много файлов. Если у пользователя узкий канал, или он играет в онлайн игры, или у него нет SSD, то всё для него будет весьма печально- страницы будут загружаться медленнее из-за высокой отдачи, онлайн-игры будут лагать и вырастут пинги, если всё у пользователя крутится на одном HDD то о нормальной работе на ПК можно забыть — HDD будет постоянно занят, снижая свою производительность, т.е. все программы будут запускаться гораздо дольше.
«И всё ради чего?» -спросит себя пользователь, и снесет всю эту лабуду, чтобы нормально пользоваться СВОИМ компьютером, а не для того, чтобы всякие владельцы сайтов снижали с себя расходы.
ipfs интересен тем, что в нём реально получается небольшое время ожидания. Что-то типа tor. Не сравнить с i2p или freenet/gnunet.
И речь именно о холодном ожидании. Как закачалось в кеш — отдаётся мгновенно.
И речь именно о холодном ожидании. Как закачалось в кеш — отдаётся мгновенно.
Я изучал причины задержки p2p протоколов на примере nmdc и пришёл к выводу, что причины в плохой реализации. Если использовать более продуманный протокол, то задержки будут минимальны, если вообще будут.
Например, есть способ вообще гарантированно увеличить скорость передачи данных, а не вносить задержки. Но это зависит от реализации. Проще говоря — тут надо не думать, а делать.
Например, есть способ вообще гарантированно увеличить скорость передачи данных, а не вносить задержки. Но это зависит от реализации. Проще говоря — тут надо не думать, а делать.
Задежки уровня tor подойдут только для видео. Для картинок они уже будут слишком большими.
Если быть совсем точным, то задержки _холодных_ данных в ipfs сравнимы с задержкой _горячих_ данных в tor. Горячие же данные в ipfs отдаются с обычной для web'а скорость. Ну, вот, чтобы не быть голословным, залитая мной картиночка в ipfs: gateway.ipfs.io/ipfs/QmTUeRKutKfbTRmoXsgRTv4r9zKJyFVrX3NVLQctRmoa1v
Всё-таки неплохо было бы перечитывать перед публикацией. Биллион — это миллиард, да и ещё мелочи цепляют глаз.
По теме же, кажется, время этой системы ушло, не наступив. Кэширование на локальной машине — это неплохо, но в связи со всё уменьшающейся «толщиной» юзерских машин, кажется, не случится.
Могу понять мечту об анархизме, но без скоростных И дальнобойных каналов «точка-точка» никакого анархизма не случится. А как пропустить через радиоэфир гигабиты — не представляю.
По теме же, кажется, время этой системы ушло, не наступив. Кэширование на локальной машине — это неплохо, но в связи со всё уменьшающейся «толщиной» юзерских машин, кажется, не случится.
Могу понять мечту об анархизме, но без скоростных И дальнобойных каналов «точка-точка» никакого анархизма не случится. А как пропустить через радиоэфир гигабиты — не представляю.
Нужно придумать все таки систему управления правами и авторством. Иначе это никак не поможет ютубу тому же.
Украли мою технологию Peering cloud :-) Я подошёл немного с более приземлённого решения использовать nmdc протокол и его хабы. В дальнейшей перспективе — это так же превратиться в протокол передачи данных. А сегодня это помогает мне раздавать статику. Исходный код здесь: https://github.com/master255/ImmortalPlayer
Рабочая программа здесь: https://play.google.com/store/apps/details?id=com.medialibrary.mycollection
Должен заметить, эта технология может совместно сосуществовать с другой моей очень обсуждаемой (http://habrahabr.ru/post/267329/) технологией DoubleDomain.
Рабочая программа здесь: https://play.google.com/store/apps/details?id=com.medialibrary.mycollection
Должен заметить, эта технология может совместно сосуществовать с другой моей очень обсуждаемой (http://habrahabr.ru/post/267329/) технологией DoubleDomain.
Ну какие «биллионы»? Биллион — это миллиард, если по-русски.
Интересная вещь, возможно найдет свое место в корпоративных сетях, но вот в качестве замены интернету нет.
Тут уже писали, про то, что есть коллизии… Теоретически я могу насоздавать у себя кучу файлов с текстами этих хешей… и тогда мне не нужно будет кого то там DDOS ить, вирус люди скачают себе сами.
Возможно эта штука будет полезна для больших сетей, раздающих контент, таких как youtube, vk. Если все большие контент хранилища перейдут на этот протокол, то возможно интернет уже почувствует облегчение. От пользователя к пользователю — это долго, не безопасно и не нужно, есть торрент в конце концов.
Тут уже писали, про то, что есть коллизии… Теоретически я могу насоздавать у себя кучу файлов с текстами этих хешей… и тогда мне не нужно будет кого то там DDOS ить, вирус люди скачают себе сами.
Возможно эта штука будет полезна для больших сетей, раздающих контент, таких как youtube, vk. Если все большие контент хранилища перейдут на этот протокол, то возможно интернет уже почувствует облегчение. От пользователя к пользователю — это долго, не безопасно и не нужно, есть торрент в конце концов.
Попробую объяснить на примере.
Допустим, что по хэшу«QmQZB43ePCwDsow74gehT8v74M2tKtTs9FCbH4wpoUksfF» находится текстовый файл, состоящий из единственного слóва «Хабрахабр» (в UTF-8 с сигнатурою).
Внимание, вопрос: сколько лет придётся работать над достижением цели «вирус люди скачают себе сами» (то есть над достижением коллизии), если строка «QmQZB43ePCwDsow74gehT8v74M2tKtTs9FCbH4wpoUksfF» состоит из 46 символов в формате base58, являющихся мультихэш-обёрткою вокругSHA2-256?
Допустим, что по хэшу
Внимание, вопрос: сколько лет придётся работать над достижением цели «вирус люди скачают себе сами» (то есть над достижением коллизии), если строка «QmQZB43ePCwDsow74gehT8v74M2tKtTs9FCbH4wpoUksfF» состоит из 46 символов в формате base58, являющихся мультихэш-обёрткою вокруг
Прибавлю, что хэши SHA-256 используются и в Bitcoin, так что, если бы коллизии и впрямь были такой проблемою, то сперва их первооткрыватели немало озолотились бы, а затем биткоины резко обесценились бы. Мы не видим ни того, ни другого.
Вопрос времени и необходимости. Мир уже не один раз проходил стадию, вот мы сделаем и теперь точно хватит на всегда!
Вопрос вычислительной сложности. Сейчас, если я ничего не путаю найти коллизию в SHA-256 можно за 265 операций, но это просто коллизия. Семантическая коллизия (т.е., подбор такого исходника, который выполняет нужную вам функцию, и который бы совпадал по хэшу с другим исходником, выполняющим другую нужную вам функцию) не факт, что вообще возможна.
Понятно, что конкретный хэш (SHA-256) не навсегда. В том числе поэтому существует обёртка в форме мультихэша, которая позволит в случае чего перейти к употреблению другого конкретного хэша в IPFS, не трогая ничего более в логике работы файлообмена.
Вот я создам 2^65 файлов (сейчас вряд ли, но когда нибудь в будущем) где будет строка s = 'Уникальный хеш'. То есть получается я переберу все варианты из 2^65. (Хеш в исходнике может не совпадать с хешем самого файла). Ну даже если не 2^65, а меньше… все равно будет вероятность, что мой код будут считать за другой файл.
Это замечание по сути верно, но по формулировке не совершенно справедливо, так что я выскажу к нему две поправки.
Во-первых, хэшSHA-256 является (насколько я его понимаю) 256-битным, так что вместо 265 файлов понадобится 2256 файлов, а это гораздо больше.
Во-вторых, как упоминалосьнесколько выше, даже для хранения 2128 различных файлов потребуется ≈251 иоттабайтов, то есть не менее квадриллиона иоттабайтов.
(Это для хранения, но задача их генерации также никак не может быть названа простейшею.)
Во-первых, хэш
Во-вторых, как упоминалось
(Это для хранения, но задача их генерации также никак не может быть названа простейшею.)
Так, для сравнения, оценка количества атомов во вселенной ≈1080,
а 2256 всего на три порядка меньше
а 2256 всего на три порядка меньше
Ну в статье приводится вполне конкретный хеш:
QmcXx5mKDQAc7tCWLq84Hn7XFxWfBdZpvogJk3tNXQRFiv
вот и возник такой вопрос.
QmcXx5mKDQAc7tCWLq84Hn7XFxWfBdZpvogJk3tNXQRFiv
вот и возник такой вопрос.
Этот хэш состоит из сорока шести пятидесятивосьмеричных цифр.
А это надёжней чем TTH? Если да, то на сколько?
Что вы понимаете под TTH? Если Tiger, то где-то на десять десятичных порядков, если по birthday attack смотреть.
Файлы передаются блоками от разных пользователей
Вот ведь копирайтеры-то обрадуются: каждый «клиент» в таком p2p-интернете есть распространитель контента — это просто подарок им: «письма счастья — в каждый дом».
Законодательно исключить такой p2p-интернет, чтобы логика не попадала под распространение с нарушением авторского права (aka copyright law, Urheberrechtsgesetz и иже с ними) — та еще проблема, имхо.
По крайней мере в известных своей бюрократией странах.
Где-то читал около-юридическую статью на похожую тему — реально обсуждалась идея с хранением origin. Чтобы значит копирайтера туда отправлять. Про-то как технически реализовать такой бред… лучше не здесь, а то сильно толсто получится.
Законодательно исключить такой p2p-интернет, чтобы логика не попадала под распространение с нарушением авторского права (aka copyright law, Urheberrechtsgesetz и иже с ними) — та еще проблема, имхо.
По крайней мере в известных своей бюрократией странах.
Где-то читал около-юридическую статью на похожую тему — реально обсуждалась идея с хранением origin. Чтобы значит копирайтера туда отправлять. Про-то как технически реализовать такой бред… лучше не здесь, а то сильно толсто получится.
Вы сейчас слово «копирайтеры» не вон в том значении употребили, правда ведь?
Думаю, что лессиговский принцип «code is law» будет действовать, то есть трудновато будет в связи с появлением новой программы буквально каждого читателя Сети бросить за решётку или штрафовать (сейчас провайдеров не сажают же и не штрафуют за распространение, например).
К сожалению, вы не правы, и во многих странах уже несколько лет как штрафуют, поэтому пользоватся p2p (тот же торрент) ой как небезопасно для собственного кармана.
А штрафы кстати не маленькие: ~ 800 за фильм или ~ 300 за песню (в вечнорастущих).
К тому же право как правило прецедентное или близко к тому, то есть судья и не силно долго разбирается, и если просто из принципа попробовать все же в суде, еще и все судебные издержки в случае очень вероятной неудачи оплачивать.
А провайдер вообще не причем, он просто тупо сливает (ибо обязан) домашний адрес «распростронителя» по IP+timestamp адвокату «потерпевшей» стороны, по предьявлению им прокурорской авизо.
И это например в тех же Европах поставлено на поток, т.е. дело нескольких минут.
А штрафы кстати не маленькие: ~ 800 за фильм или ~ 300 за песню (в вечнорастущих).
К тому же право как правило прецедентное или близко к тому, то есть судья и не силно долго разбирается, и если просто из принципа попробовать все же в суде, еще и все судебные издержки в случае очень вероятной неудачи оплачивать.
А провайдер вообще не причем, он просто тупо сливает (ибо обязан) домашний адрес «распростронителя» по IP+timestamp адвокату «потерпевшей» стороны, по предьявлению им прокурорской авизо.
И это например в тех же Европах поставлено на поток, т.е. дело нескольких минут.
а есть ли прув на пример такого дела из-за торрент раздачи? И как можно систематизировано проверять торрент раздачи, если файлы раздаются частями, ссылки на эти файлы находятся на каких-то не понятных форумах, а в раздаче попеременно участвуют сотни ip адресов.
Что, неужели на поток поставили отслеживание всех торрент трекеров в интернете???
Если да, то как :-)?
Что с другими п2п сетями? Например dc++? Там вроде всегда было больше контента, чем в торрентах.
Что, неужели на поток поставили отслеживание всех торрент трекеров в интернете???
Если да, то как :-)?
Что с другими п2п сетями? Например dc++? Там вроде всегда было больше контента, чем в торрентах.
Прувов в сети немерено, гуглить по Abmahnung Filesharing «Urheberrechte verletzt» (это если на немецком например).
Без разницы, какая p2p сеть — filesharing есть filesharing.
По поводу остального как-то отвечал уже на хабре. Но с тех пор все гораздо хуже (строже).
Без разницы, какая p2p сеть — filesharing есть filesharing.
По поводу остального как-то отвечал уже на хабре. Но с тех пор все гораздо хуже (строже).
я уже не раз говорил, что введение подобных фич в странах типо нашей просто приведет к тому, что в торрент-клиент будут встраивать тот же CJDNS или тор. Т.е. активно внедряться механизмы скрытия своего адреса. Если в Европе в контексте данной ситуации мораль рабов выигрывает (проще заплатить за каждую лицензию не по разу, чем заморачиваться), то у нас после девальвацией уже есть резон вникнуть и установить.
CJDNS вообще отлично получается — скорость максимальная, нет специального прогона трафика где-попало, но при этом бегать по цепочке нод ради каждого раздающего, чтобы найти его обычный айпишник — нафиг кому-то надо. Особенно если этот умник еще и счастливчик, и у него часть трафика ходит через реальным меш!
CJDNS вообще отлично получается — скорость максимальная, нет специального прогона трафика где-попало, но при этом бегать по цепочке нод ради каждого раздающего, чтобы найти его обычный айпишник — нафиг кому-то надо. Особенно если этот умник еще и счастливчик, и у него часть трафика ходит через реальным меш!
— Есть ли прямо сейчас пример такого хостинга произвольных файлов, который складывает их в IPFS?
— Есть, ipfs.stadja.net/upload
Уже нет :D fucking russians :D :D
UFO just landed and posted this here
Провайдерам регионального уровня это будет выгодно, потому что больше траффика будет переходить в локалку из глобалки, так что меньше придётся тратиться на доступ к магистральному каналу. (Пример 2010 года: решение ОАО «ЮТК» о бесплатном и обязательном безлимите между абонентами Краснодарского края, принятое силою моего убеждения.)
Поигрался, очень интересная штука, работает шустро. Смущает только невозможность (или я не нашел) удалить файл, если я являюсь его владельцем (почему бы и нет?).
Конечно, знаю пословицу про 7 раз отмерь… но все же, если по случайно в паблик выкатить ошибочный (или не тот) файл, дать на него ссылку и по ней его скачает другой человек, то даже при всем желании владельца, выпилить его из сети будет уже нереально никогда, пока сеть существует.
Плюс, сеть будет захламляться со временем старыми версиями файлов, которые и нафик ни кому не нужны. Владельцы бы и рады устроить чистку, да не смогут.
Конечно, знаю пословицу про 7 раз отмерь… но все же, если по случайно в паблик выкатить ошибочный (или не тот) файл, дать на него ссылку и по ней его скачает другой человек, то даже при всем желании владельца, выпилить его из сети будет уже нереально никогда, пока сеть существует.
Плюс, сеть будет захламляться со временем старыми версиями файлов, которые и нафик ни кому не нужны. Владельцы бы и рады устроить чистку, да не смогут.
С точки зрения борьбы с цензурою даже полезно, что файл не имеет того одного владельца, до которого было бы возможно добраться и принудить к стиранию файла. Потому что если возможно, то оно было бы и повадно.
Не пытайтесь изменить факт, пытайтесь изменить своё отношение к этому факту.
Под технологии подстроится и психология.
В давние времена и фотографии-то незнакомым людям не показывали,
а сейчас инстаграмм, ютюб, перископ, лишь бы кто-нибудь посмотрел и лайкнул.
Под технологии подстроится и психология.
В давние времена и фотографии-то незнакомым людям не показывали,
а сейчас инстаграмм, ютюб, перископ, лишь бы кто-нибудь посмотрел и лайкнул.
Рискну предположить, что реализован (или в скором времени будет реализован) механизм, по мере заполнения кэша удаляющий невостребованные файлы. Но удалить с гарантией — невозможно.
Счётчики посещений и прочая статистика лесом пойдут?
https://github.com/jbenet/multihash/blob/master/hashtable.csv
То есть, TIGER, из которого получается TTH, тут нет, петабайтная локалка уже сегодня в качестве кеша работать не сможет, а вот если все поставят IPFS, ну тогда, может быть, что–нибудь и получится. Inter-Planetary как бы намекает, в каком временном диапазоне это может случиться.
code name
0x11 sha1
0x12 sha2-256
0x13 sha2-512
0x14 sha3-512
0x15 sha3-384
0x16 sha3-256
0x17 sha3-224
0x18 shake-128
0x19 shake-256
0x40 blake2b
0x41 blake2s
# 0x00-0x0f reserved for application specific functions
# 0x10-0x3f reserved for SHA standard functions
# 0x14 formerly had the name «sha3», now deprecated
То есть, TIGER, из которого получается TTH, тут нет, петабайтная локалка уже сегодня в качестве кеша работать не сможет, а вот если все поставят IPFS, ну тогда, может быть, что–нибудь и получится. Inter-Planetary как бы намекает, в каком временном диапазоне это может случиться.
1. Ссылка https://ipfs.io/ipfs/QmQZB43ePCwDsow74gehT8v74M2tKtTs9FCbH4wpoUksfF валится с 504-й ошибкою. Сей факт вкупе с наличием в статье ссылок на некий другой IPFS-гейт наводит на печальные мысли о том, что наличие единственного домена-гейта — это плохо и централизация. Куда логичнее было бы обрабатывать адреса вида ipfs.anydomain.tld: владелец anydomain.tld не принуждается доверять доступность своей статики некоему серверу, а расширение по-прежнему может брать данные с локальной IPFS.
2. Как бы то ни было, решение с отслеживанием домена/поддомена есть костыль, который, хотя и красив, едва ли когда-нибудь будет принят на вооружение браузерами в умолчальной конфигурации, а потому уже сейчас необходимо указывать некий html-атрибут, соответствующий IPFS-хэшу, например,
3. Реквестирую PPA для установки сего в Ubuntu 12.04 или хотя бы толковый мануал.
2. Как бы то ни было, решение с отслеживанием домена/поддомена есть костыль, который, хотя и красив, едва ли когда-нибудь будет принят на вооружение браузерами в умолчальной конфигурации, а потому уже сейчас необходимо указывать некий html-атрибут, соответствующий IPFS-хэшу, например,
3. Реквестирую PPA для установки сего в Ubuntu 12.04 или хотя бы толковый мануал.
Ещё не поздно для IPFS https://habrahabr.ru/post/310554/
Вышел FF59 с поддержкой IPFS.
Насколько я понял они просто добавили возможность прицепить обработчик протокола.
- New values for protocol_handers:
- "ssb" for Secure Scuttlebutt communications
- "dat" for DATproject
- "ipfs", "ipns", "dweb" for IPFS
https://developer.mozilla.org/en-US/Firefox/Releases/59#WebExtensions
Но вот работает ли это с ресурсами на странице или только для ссылок?
Tо есть будет ли он так работать
<img src="ipfs:QmTUeRKutKfbTRmoXsgRTv4r9zKJyFVrX3NVLQctRmoa1v" alt="белочка" />или только так
<a href="ipfs:QmTUeRKutKfbTRmoXsgRTv4r9zKJyFVrX3NVLQctRmoa1v">белочка</a>Sign up to leave a comment.
Почему Интернету нужен IPFS, пока ещё не поздно