= Сообщение: 3521 из 14875 ======================================= R50.SYSOP =
От : Sergey Sokoloff 2:50/88 18 Sep 15 11:49:24
Кому : Alexey Vissarionov 18 Sep 15 11:49:24
Тема : IPFS и байхуизм вместо ююков и файлэх
FGHI : area://R50.SYSOP?msgid=2:50/88+55fbd061
На : area://R50.SYSOP?msgid=2:5020/545+55faa4ce
= Кодировка сообщения определена как: CP866 ==================================
Ответ: area://R50.SYSOP?msgid=2:5000/111+55fbea74
Ответ: area://R50.SYSOP?msgid=2:5020/545+55fd355a
==============================================================================
════╤╤═════ Коль гонимы псевдонимы (паспорта в почёте) тут,
//│/│ ││ │/│/ То не Mithgol the Webmaster и меня здесь назовут.
Так было 11:14 17 Sep 15 написано от Alexey Vissarionov к Sergey Sokoloff:
AV>>> В этом случае появляется другое, хотя и вполне приемлемое
AV>>> ограничение: одна ссылка - один файл.
SS>> Ситуация лучше, чем ты думаешь, поскольку помимо адресов файлов
SS>> IPFS умеет создавать и понимать адреса каталогов, состоящих,
SS>> однако же, из адресов (и имён) их файлов и подкаталогов,
AV> Я знаю, как это реализовано, например, в .emulecollection (текстовый файл
AV> со ссылками по одной в строке).
Насколько я помню положение дел в eMule (а я могу ошибаться, потому что мне
много лет не доводилось запускать eMule), создание файла .emulecollection было
не особенно рекурсивным. Можно было сложить несколько файлов в .emulecollection
в виде плоского каталога, но для разветвлённого каталога (то есть каталога,
имеющего подкаталоги) не обеспечивалось рекурсивное создание .emulecollection,
описывающих подкаталоги, и складывание ссылок на них в .emulecollection более
высокого уровня. Между тем IPFS это автоматизирует, так что IPFS в этом смысле
более похожа на файловую систему (отсюда и название).
SS>> так что адрес каждого отдельного файла это не меняет и прочие
SS>> вышеперечисленные ништяки не отменяет. Получатели одного и того же
SS>> (по содержанию) файла, скачиваемого ими в составе разных каталогов,
SS>> не совершают лишнего труда.
AV> Мне тут придумался вариант реализации таких ссылок:
AV> scheme:/jrP6+D09/l1zgWZdU2uwzustHGk24b3XrdDJ9hRP0rg
AV> scheme:/jrP6+D09/l1zgWZdU2uwzustHGk24b3XrdDJ9hRP0rg*files.list
AV> scheme:.xZlx0frfNh7JisYimeyp2+dJDhYtRjG3QWIIpXc1ijN*some.file
AV> Первый символ после двоеточия является признаком каталога ('/') или
AV> обычного файла ('.'), далее идет base64 от дерева Меркла на основе sha256,
AV> а в хвосте опциональное имя файла, для удобства отделенное каким-нибудь
AV> символом.
AV> Признак каталога означает только то, что этот файл подлежит дальнейшей
AV> обработке, но можно вполне обойтись и без него. Алгоритм SHA256 выбран из
AV> соображений упихивания ссылки в 80 символов, а размер блока для построения
AV> дерева Меркла я бы выставил в 16777216, 33554432 или 67108864 байтов
AV> (соответственно 16, 32 или 64 мегабайтов).
AV> Собственно, ничего принципиально нового здесь нет - тот же ed2k, вид
AV> сбоку.
Ты тут уж начинаешь заново изобретать IPFS. А не надо заново изобретать, если
можно использовать готовое. Почему не надо? Потому, что кое-что получится хуже.
Скажем, выбор алгоритма SHA256 означает, что после устаревания алгоритма SHA256
устареет и формат записи URLов, и сеть, может быть. (Тогда как IPFS использует
мультихэш, так что после устаревания одной формы хэша перейдёт на другие без
резких изменений в тех местах кода, где у тебя был бы жёстко заложен SHA256.)
AV>>> А куда и как можно развить протокол Kademlia? Он, конечно, не
AV>>> идеальен, но близок к оптимуму.
SS>> У него есть такая неприятность, как подверженность Атаке Сивиллы
SS>> https://en.wikipedia.org/wiki/Sybil_attack
AV> Формально этой атаке в той или иной степени подвержены все
AV> децентрализованные системы - вопрос лишь в том, насколько ресурсоемким
AV> является процесс создания новой сущности.
Это замечание справедливо. Просто новые решения заметно лучше запроектированы
в отношении противостояния атаке, нежели чистая Kademlia.
AV>>> А вот тут неустранимый затык: если эхи как были, так и остаются
AV>>> наиболее популярным (и единственным ценным) фидошным ресурсом, то
AV>>> файлэхи уже никому особо и не нужны.
SS>> Об этом можешь мне не рассказывать: мне они во всё время в Фидо не
SS>> были нужны. А сейчас, однако, сделались нужны: как иначе передать
SS>> по Фидо иллюстрации?
AV> А использовать внешние сервисы православным буддистам аллах запрещает?
AV> Хорошо, что я атеист... :-)
Говорят, что Кадыров сказал, что деньги Чечне даёт Аллах. Дык вот тот самый
кремлёвский Аллах сейчас и интернетовские сервисы постепенно запрещает, причём
не одним только православным буддистам, но и всем остальным гражданам также.
Децентрализованный IPFS запретить, правда, несколько труднее будет, чем сайт.
Поэтому я допускаю, что стану добавлять в свой софт (которым обеспечивается
работа гипертекстового Фидонета) поддержку IPFS.
Сейчас, правда, в Windows-версии IPFS есть довольно неприятная ошибка; и она
препятствует повторному запуску этой версии после того, как первый запуск её
окончился. Выглядит это так:
https://twitter.com/FidonetRunes/status/644092911982931968
Потому сколько-нибудь серьёзные доработки моего софта (то есть такие доработки,
которые полагались бы на наличие запущенного IPFS в системе) мне трудно сейчас
тестировать. Ожидая исправления ошибки (о которой разработчики IPFS дней 12 уж
осведомлены), я покамест добавил только поддержку схемы URLов 'fs:' в модуль,
преобразующий текст сообщения фидопочты в код HTML:
https://github.com/Mithgol/node-fidonet-fidohtml/commit/f3b2a7ffaaf26ac62d1547
У меня также есть набросок кода, который будет преобразовывать URLы этого типа
в гиперссылки, ведущие на гейт, позволяющий в WWW смотреть файлы, выложенные
в IPFS. Пока этот набросок я использую для тестирования вышеупомянутого модуля:
https://github.com/Mithgol/node-fidonet-fidohtml/commit/0a296189ee6f995737c2c6
Со временем я надеюсь придать им и другое (куда более практическое) применение.
Если моему примеру затем последуют Макс Лушников (в wfido) и Сергей Позитурин
(в HotdogEd), то Фидонет будет несколько иллюстрированнее нынешнего, причём
без необходимости полагаться на распространение файлэх или на их гейтование
через серверы, позволяющие на FTP смотреть файлы, выложенные в файлэхи.
AV>>> Да хрен бы с ним, с отображением... Вон, в golded есть urlhandler,
AV>>> которого вполне достаточно.
SS>> Тебе достаточно, а мне нет.
AV> Ты не поверишь: я даже им не пользуюсь - мне проще выделить ссылку в деде,
AV> работающем на отдаленном сервере, и шлепнуть средней кнопкой мыши (точнее,
AV> трекпойнта) в соседнем окне.
Мне действительно сложно веровать тому, что тебя эти усилия не подзадалбывают.
SS>> (Если бы мне было достаточно, то я бы и не думал о гипертекстовом
SS>> Фидонете и об иллюстрированности эхоконференций в нём.)
AV> Куда-то ты не в ту сторону думаешь...
А я вот думаю, что именно в ту, в ту самую.
SS>> С чего-то надо же ведь начинать. Вон в Москве на Триумфальной
SS>> площади деревья не посадили, но таблички о том, что здесь посадят
SS>> то или иное дерево, воткнуты. Планирование, оповещение.
AV> ... в надежде на то, что придут горожане и все сделают сами. После чего
AV> муниципалы отчитаются перед округом, округ перед мэрией - и все будет
AV> замечательно, причем без каких-либо затрат на оплату труда озеленителей.
Да нет, вроде как просто для того, чтобы не было голой земли и лишних вопросов.
SS>> К сожалению, у нас тут (в Фидонете, я имею в виду) есть ещё явная
SS>> проблема с отображением адресов, превосходящих 80 и даже 79 символов:
SS>> они начинают наталкиваться на границу окна восьмидесятисимвольного
SS>> терминала, так что даже и голдедовский urlhandler, выше тобою
SS>> упомянутый, начинает несколько некорректно вести себя, потому что сам
SS>> GoldED+ передаёт ему не полный URL, а только начальный огрызок его.
AV> Хренассе... А почему я не видел багрепорта в ru.golded?
А смысл?
Во-первых, как мне кажется, разработка GoldED+ прекратилась уж совершенно.
Во-вторых, я сейчас пользуюсь GoldED-NSF, так что даже маловероятный выход
новой версии GoldED+ ничем мне не поможет, ведь разработка GoldED-NSF также,
как мне кажется, прекратилась уж совершенно.
Я, конечно, мог бы перейти со старой версии GoldED-NSF на новую версию GoldED+;
однако тогда мне пришлось бы смириться с утратою возможности перехода в GoldED
по внутрифидонетовским URLам. Ведь есть (или было) официальное заявление о том,
что в GoldED+ не будет добавлена существующая в GoldED-NSF возможность перехода
по внутрифидонетовским URLам (FGHI URL), возможность копирования URLа открытого
в настоящее время сообщения, и так далее.
Мне проще сочинить собственный редактор фидопочты (хотя это, право же, также
далеко не просто), чем иметь дело с вышеперечисленными проявлениями глубочайшей
безысходности и техномазохизма. Вдругорядь скажу: Фидонет создали педерасты,
а погубят его мазохисты.
SS>> fs:/ipfs/QmWdss6Ucc7UrnovCmq355jSTTtLFs1amgb3j6Swb1sADi
SS>> Длина его -- 55 символов. Однако это, так сказать, прямой адрес
SS>> файла. Если бы мы пожелали вместо этого дать адрес папки,
AV> Вообще-то папки сношают мамок, а в файловой системе используются каталоги.
Вообще-то в русской речи есть такая штука, как омонимы, так что папка ── это
не только папа, то и твёрдая обложка для владывания в неё бумаг. Как метафора
для файловой системы это слово ('папка') тем удобнее другой метафоры 'каталог',
что оно короче на два символа (или на один слог) и оттого набирать его (или же
произносить) бывает и проще, и быстрее.
AV> Внимание, китайский вопрос: где цветок (na3 hua1)?
AV> Если тебе нужен файл - укажи его хеш безо всяких каталогов.
Отвечу также по-китайски: дело в том, что это байхуизм, то есть следование
идеалам движения 'байхуа юньдун', провозглашённого Мао Цзэдуном в 1957 году
по мотивам классического китайского стихотворения 'пусть расцветают сто цветов,
пусть соперничают сто школ', начинающегося словами 'бай хуа' ('сто цветов').
Именно там и цветок.
SS>> то на такое дописывание у нас осталось бы 24 символа, считая и
SS>> косые черты. Это больше, чем прежний стандарт 8.3, но не особенно
SS>> больше.
AV> В предложенном мной выше варианте можно использовать 27 символов. С учетом
AV> контекста сообщения должно более-менее хватать.
AV> Кстати, эксперимента ради собрал статистику по своему варезнику: из более
AV> 12 тысяч файлов больше всего 12-символьных имен (1202), затем идут
AV> 9-символьные (772) и 8-символьные (737). Односимвольных файлов обнаружено
AV> всего 127 штук, двуххсимвольных 139 штук, а рекордной длиной имени (ажно
AV> 112 символов) может похвалиться всего один файл.
AV> Ну и самое главное: файлов с длиной имени не более 27 символов набралось
AV> 77.6% (9724/12525) от общего количества, что позволяет в 7 случаях из 9
AV> обойтись без переименования публикуемых файлов.
Эта статистика весьма познавательна.
Я также тут некоторое время подумал и понял, что можно ограничить адрес IPFS
указанием одного только хэша, однако надо же задуматься и о том, что картинка
в Фидонете будет со временем (как я о том говорил несколько раньше) не только
в форме голого URLа записываться, но также и в форме фидонетовской руны (некоей
единицы легковесной разметки), включающей указание альтернативного текста для
такой картинки. И я покажу это на примере совершенно того же отрывка из аниме
'Saenai Heroine no Sodatekata', который использовал ранее. Разметка наподобие
языка Markdown будет иметь такой вид:
Что мы должны видеть на этом примере, что мы видим?
Мы видим, что на месте для альтернативного текста я ещё мог поместить псевдоним
'Kashiwagi Eri', но полное имя 'Sawamura Spencer Eriri' там не поместилось бы.
Мало места.
Весьма вероятно, что надо будет и дальше брать пример с языка Markdown, то есть
предусмотреть употребление разметки, разделённой на две части, одна из которых
употребляется на том месте, где надо показать картинку, а другая употребляется
в другом месте (например, в конце текста) и приводит технические подробности
(URL, например). Выглядеть это будет как-нибудь так: на месте картинки
![Sawamura Spencer Eriri][eri]
(с указанием лишь краткого идентификатора) и затем где-нибудь в конце текста
[eri]: fs:/ipfs/QmWdss6Ucc7UrnovCmq355jSTTtLFs1amgb3j6Swb1sADi "Kashiwagi Eri"
Как видно, в этом случае после URLа даже есть пространство для краткого текста
подсказки, всплывающей при наведении мыши на иллюстрацию.
SS>>>> нет проблемы затирания файла одноимённым новым файлом,
AV>>> Кстати, иногда это нужно. Не одноименным, разумеется, а "одноцелевым".
SS>> Поясни.
AV> На примере файлэхи: обновление нодлиста.
Понятно.
В системе IPFS предусмотрена система имён IPNS, позволяющая сперва присваивать
уникальное имя некоторому файлу, а затем переназначить это имя на другой файл
(причём переназначить может только обладатель того же закрытого ключа, который
создавал имя).
Сейчас эта система работает несколько криво (создаётся не более одного имени
на одну установленную-настроенную-запущенную копию IPFS), но со временем можно
предвидеть развитие возможностей этой системы.
SS>>>> сейчас нигде в Фидонете нет поддержки IPFS, а ещё будут проблемы
SS>>>> узлов и пойнтов, не готовых начать поддержку IPFS, не имеющих
SS>>>> у себя поддерживаемой IPFS операционной системы, не имеющих
SS>>>> постоянного подключения к Интернету
AV>>> Нет. И не нужно.
SS>> Поясни.
AV> IPFS является экзотикой даже за фидошными пределами, поэтому нужно
AV> поискать что-нибудь более популярное и при этом подходящее. Я одно время
AV> использовал ссылки ed2k, но особой народной любви они не получили.
Файлэхи не особенно распространены в Фидонете в их непосредственном виде,
однако многие фидошники, не имеющие у себя файлэх, имеют, несмотря на это,
доступ к содержимому файлэх за счёт того, что существуют гейты, на FTP-сервере
позволяющие посмотреть файл по известному имени файла и по названию файлэхи.
Правда, для этого необходим доступ к Интернету, а не к одному только Фидонету.
Гиперссылки ed2k не могли похвастаться этим достоинством потому, что фидошникам
не была предоставлена возможность без участия в ed2k-файлообмене пользоваться
практическими плодами его, то есть получать файлы из ed2k-сети посредством
некоторого гейта.
Таковы два противоположных полюса.
К которому из этих двух полюсов более близка распределённая файловая система
IPFS? Я полагаю, что она более близка к первому полюсу. Пускай установка IPFS
не сделалась ещё распространённым обычаем в Фидонете, однако многие фидошники,
не имеющие установленной поддержки IPFS на своём компьютере, несмотря на это
возымеют доступ к содержимому IPFS за счёт того, что существуют гейты, которые
на WWW-сервере позволяют посмотреть файл по известному хэшу его. Да, для этого
необходим доступ к Интернету, а не к одному только Фидонету; но ведь если это
условие не было обременительно для фидошников в случае с файлэхами, то для IPFS
оно также не окажется сколько-нибудь обременительным.
Причём ведь фидошнику, файлэхи имеющему, приходилось напрягаться для того, чтоб
поделиться с остальными фидошниками содержимым своих файлэх по FTP (для этого,
как минимум, требовалось выбрать, установить и настроить FTP-сервер). Тогда как
запущенный IPFS по умолчанию является также и веб-сервером, так что фидошнику,
IPFS имеющему, не придётся чрезмерно напрягаться для того, чтобы поделиться
с остальными фидошниками содержимым IPFS: достаточно ему будет открыть порт
в настройках своего файерволла и (или) домашнего маршрутизатора, вот и всё.
Думаю, что эта благоприятная простота должна внушать нам некоторый оптимизм.
Mithgol the Webmaster. ═[Mithgol.Ru]═[FGHI]═[Ru.Mozilla]═[Team А я меняю subj]
--- иногда пронзительно свистит на горе рак и свершается страшное (c) Marїnais
* Origin: Hо злая мука богооставленности не может длиться вечно!! (2:50/88)
|
