Infonesy: Вопросы и проблемы протокола обмена

Это наверно лютый офтоп, но слышал уже новость про BigchainDB

А ещё есть идея попробовать файлы постингов засовывать в ipfs, и хеши вписывать в файл топика.
без поиска других нод с архивом этих постингов.

В ipfs нужен явный pin add, для этого. Хотя-бы на некоторых узлах.

Кстати, по ipfs какая-нибудь навигация есть. Можно ли получить список всех хранимых объектов?

Так что сразу за 4 дня в обменном репозитории легло 23Мбайт файлов. Это на 876 штук. В то время, как всех остальных файлов (постинги, описания аттачей, форумы, категории) за 14 дней всего на 16Мбайт (16255 штук).

А вообще чего ты ожидаешь? Вечное хранение с полной репликацией?

Это наверно лютый офтоп, но слышал уже новость про BigchainDB

Пока — нет.

В ipfs нужен явный pin add, для этого

Само собой. Это автоматом выполняется на ноде-источнике и добровольно может выполняться на нодах-участниках сети.

Кстати, по ipfs какая-нибудь навигация есть. Можно ли получить список всех хранимых объектов?

Локальных? Да. ipfs pin ls выдаст список зафиксированных файлов. А вот список закешированных транзитных файлов — не знаю.

А вообще чего ты ожидаешь? Вечное хранение с полной репликацией?

В идеале — да. Но идеал невозможен :) Поэтому пока хочется просто единообразное долговременное хранение информации, в которой заинтересованы участники сети. И сохранение доступности к информации при падении/закрытии/блокировках исходной ноды, породившей информацию.

Правда, это, хотя и основная, но не единственная цель. Ещё из важных целей — единообразный формат обмена информацией между разными платформами участников (разные движки форумов, блогов и соц. сетей, всякие Retroshare и ZeroNet и т.п.), включая как исходные материалы, так и их обсуждение. Чтобы, например, можно было начать тему тут же, на ЛОРе (в гипотетическом случае его участия в сети :D) а обсуждать её на ОпенНете, в i2p и retroshare. С обменом комментариями между всеми участниками.

Чтобы, например, можно было начать тему тут же, на ЛОРе (в гипотетическом случае его участия в сети :D) а обсуждать её на ОпенНете, в i2p и retroshare.

Это же почти агрегатор новостей.

С обменом комментариями между всеми участниками.

Единый формат адресов, ключей. ZeroNet почти позволяет такое благодаря этому.

Это же почти агрегатор новостей.

Агрегаторы новостей односторонние. А так — да. Что там обмен информацией (одного типа и односторонний), что в Infonesy (многосторонний и разного типа) :)

Единый формат адресов, ключей. ZeroNet почти позволяет такое благодаря этому.

ZeroNet — это конкретная платформа. К тому же пока чисто технически очень слабо развитая. Я же хочу протокол обмена более высокого уровня. Чтобы тот же ЛОР, скажем, мог бы общаться с ZeroNet.

ZeroNet — это конкретная платформа.

Там биткоиновые адреса. Между различными сайтами там работают одни ID-шники.

Чтобы тот же ЛОР, скажем, мог бы общаться с ZeroNet.

Пока администрация ресурса не пойдет навстречу, ты сможешь только грабить существующие комментарии с лора. Но никак не продолжать дискуссию. А в ZeroNet такое даже уже можно.

Агрегаторы новостей односторонние.

Вот и получишь односторонний агрегатор новостей.

UUID

То, что в твоем примере, это НЕ uuid. https://www.ietf.org/rfc/rfc4122.txt

банальный поточный gzip решит, другой вариант бинарный формат,

ну да и если номера потсов long - то логично так и и хранить, а префикс выкинуть

ОП не очень-то понятный. Я правильно понял, что проблема состоит в неадекватно большом трафике при досинхронизации больших топиков, и возникает из-за того, что описание топика содержит список всех постов этого топика?

Если так, то можно ввести дополнительный уровень косвенности: список постов топика за определенный день. И сделать так, чтобы описание топика перечисляло не посты, а имена списков-по-дням с их контрольными суммами. Тогда при досинхронизации львиная доля списка постов повторно передаваться не будет.

Там биткоиновые адреса.

Не важно. Это — _конкретная платформа_. Как бы она ни была реализована, туда нельзя писать из Retroshare или обычного Web'а.

Пока администрация ресурса не пойдет навстречу ...

ЛОР — это просто абстрактный пример :) Чтобы не рекламировать постоянно косвенно собственные форумы. Естественно, система проходит концептуальную отработку и начальное тестирование на них. А дальше — будет видно.

То, что в твоем примере, это НЕ uuid

Всякий rfc4122 — universally unique identifier. Но не всякий universally unique udentifier — rfc4122.

банальный поточный gzip решит

Да нет, вопрос не в объёмах трафика, он тут не принципиален абсолютно, а чисто в вопросе эстетики :)

Если так, то можно ввести дополнительный уровень косвенности: список постов топика за определенный день.

Нет. Тогда проще вообще не передавать UUID постингов в топиках, передавая только сами постинги (так было вначале). Тут хочется, чтобы топик содержал полную информацию о топках, чтобы принимающая трафик нода сразу, без дополнительных запросов, видела, есть ли у неё все данные топика.

хочется <...> чтобы принимающая трафик нода сразу, без дополнительных запросов, видела, есть ли у неё все данные топика.

В конструкции, которую я предложил, это видно сразу из описания топика, не скачивая ни единого списка-по-дням.

Вместо

    «Posts»: [
        «ru.balancer.board.post.759526»,
        «ru.balancer.board.post.759563»,
        «ru.balancer.board.post.759910»,
        «ru.balancer.board.post.759919»,
        «ru.balancer.board.post.4124847»,
        «ru.balancer.board.post.4125397»,
        «ru.balancer.board.post.4126108»,
        «ru.balancer.board.post.4126149»,
        «ru.balancer.board.post.4126164»,
        «ru.balancer.board.post.4126167»,
        «ru.balancer.board.post.4126172»,
        «ru.balancer.board.post.4126877»,
        «ru.balancer.board.post.4126954»,
        «ru.balancer.board.post.4144048»,
        «ru.balancer.board.post.4144049»,
        «ru.balancer.board.post.4144841»,
        «ru.balancer.board.post.4144956»
    ]

    «Posts»: [
        {
                «ListFile»: «ru.balancer.board.topic.39814.day.1»,
                «ListMD5»: «100500»
        },
        {
                «ListFile»: «ru.balancer.board.topic.39814.day.2»,
                «ListMD5»: «111555»
        },
        {
                «ListFile»: «ru.balancer.board.topic.39814.day.4»,
                «ListMD5»: «123456»
        }
    ]

Не пойму, чем это будет компактнее моего формата при сохранении функционала (полный список ID постов в файле топика).

Компактнее будет за счет того, что список постов разбит на части и вынесен из файла топика в отдельные файлы. Неизменные части списка (а это, по идее, и есть львиная доля бессмысленного трафика) повторно скачиваться не будут.

Чтобы нода могла понять, все ли посты у нее скачаны, ей явный список постов не нужен.

А это разве корректно называть UUID?

У UUID определнный формат и поведение:

UUID задокументирован как часть ISO/IEC 11578:1996

Компактнее будет за счет того, что список постов разбит на части и вынесен из файла топика в отдельные файлы.

Определённый смысл в этом есть, но появится лишняя сущность. Сейчас мы получив один файл сразу знаем, есть у нас всё что нужно или нет. И если нет то (после добавляения IPFS-хешей) можно будет получить недостающее без прямого обращения к выпустившей топик ноде.

При разбивке появляется ряд новых действий — проверить наличие-файлов списков, их выдёргивание, если их нет, анализ последующий... Если трафик станет реально огромным, такой подход будет иметь смысл, но пока это ненужное усложнение.

А это разве корректно называть UUID?

Infonesy: Вопросы и проблемы протокола обмена (комментарий)

Есть другой термин для обозначения универсального уникального идентификатора? :)

Логично.

туда нельзя писать из Retroshare или обычного Web'а.

В первый можно реализовать, но это проблема ретрошары. А из вэба есть гейты. То что ты делаешь ты считаешь что, оно так сразу всеми примется. Вангую что нет.

Чтобы нода могла понять, все ли посты у нее скачаны, ей явный список постов не нужен.

А чтобы запрашивать отсутствующие?

То что ты делаешь ты считаешь что, оно так сразу всеми примется.

А я это под себя делаю :) Примется ещё кем-то — отлично. Нет — хуже не будет.

А как ты оцениваешь перспективы IPFS? Какие могут возникнуть проблемы. Мне пока что-то страшно погружаться в Merkle DAG, хоть я и считаю его перспективнее блокчейна, но блокчейн более простой.

Я пока не знаю что выбрать для распространения данных. Торрент или IPFS. Torrent — проверенный, IPFS — удобный. Но не возникнет ли проблем потом?

А как ты оцениваешь перспективы IPFS?

Непредсказуемо. Затея отличная. Реализация тоже отлично работающая. Но. Есть сущие мелочи, которые сильно улучшили бы жизнь и намного расширили возможность применения (mime-типы и/или расширения файлов, возможность шарить файлы с внешнего хранилища без закачивания их в локальное хранилище ipfs). О них уже давно и много говорят, но... воз и ныне там. Никаких заметных изменений в ipfs нет уже с год, наверное. Это настораживает. По сути, получается, проект висит на одном энтузиасте-разработчике. И это делает его очень уязвимым.

Но я у себя в infonesy использую (и планирую дальше) его весьма активно. С одной стороны, проект опенсорсный и на Go (демон), если что, развивать его можно будет и самостоятельно. С другой, infonesy можно будет легко переключить на другой файловый транспорт, позволяющий доставать данные по ключу. Скажем, я позже планирую файлы заливать не только в ipfs, но и во freenet (минус его в чудовищной тормознутости и отсутствии гарантии сохранения файла, но как дополнительное запасное средство хранения — вполне сойдёт). А там, глядишь, поспеют и новые p2p-хранилища, которые сейчас активно пилятся, например, на blockchain.

Я пока не знаю что выбрать для распространения данных. Торрент или IPFS.

У них юзкейс очень разный. ipfs удобен для быстрого распределённого доступа к мелким файлам на манер обычного web'а. Те же картинки на сайтах раздавать без привязки к конкретному серверу. Но ipfs плохо подходит для крупных файлов. Вышибает кеши на транзитных нодах. Не уверен, что закачка идёт по блокам. Файлы, которые скачал простой юзер через гейт от юзера не раздаются (только пока в кеше гейта лежит).

torrent не годится для быстрой отдачи мелочи, зато очень круто параллелится. И раздача идёт ото всех участников.

Так что я сейчас всякие картинки/аттачи кладу в ipfs.

А вот для видео/музыки пока хорошего решения не нашёл. Торренты хороши для закачки, но хочется показывать пользователям что нужно прямо в браузере. Активное пиление в этом направлении тоже идёт, но пока нужного мне варианта ещё нет. webtorrent.io / instant.io — уже почти то, что надо, но ещё не до конца :)

Никаких заметных изменений в ipfs нет уже с год, наверное.

Но они там хвастаются повышением производительности в 0.4. Да и динамический контент — это вроде новое, или нет?

А вообще мне нужно как-то распространять блоки данных(примерно в килобайт) между пирами, я думаю на torrent, ipfs или велосипед.

По сути, получается, проект висит на одном энтузиасте-разработчике.

Странно всё это. Большинство околоблокчейновых проектов выглядят как скам, созданный с целью сбора инвестиций. А тут оказывается есть разработчик. Что это? Неправильное позиционирование проекта? Вот с этим новым Bigchain тоже нифига не понятно, в чём подвох.

ipfs удобен для быстрого распределённого доступа к мелким файлам на манер обычного web'а

Но кешировать произвольные там тоже нельзя, как я понял. Либо нужен какой-то просмотр всех блоков.

В случае UUID - это стандарт. В вашем случае назовите KUID и наслаждайтесь.

Тоже самое каждый может выпускать свои RFC, с одной стороны никто не запрещает, с другой стороны будут ли это RFC?

В случае UUID - это стандарт.

RFC с номером — стандарт. А вот как аббревиатура _общепринятого_ сокращения _с широким смыслом_ может быть стандартом?

Этот термин использовался задооолго до 2005-го, в котором был принят RFC. И что же теперь, резко перестать его использовать в том смысле, в каком это делали все раньше?

Linux kernel 2.5.3 is out

http://www.balancer.ru/g/p305369

http://www.uddi.org/pubs/draft-leach-uuids-guids-01.txt

и т.п.

нужно как-то распространять блоки данных(примерно в килобайт) между пирами, я думаю на torrent, ipfs или велосипед.

Если нужно распространять как временный поток без необходимости длительного хранения и всеобщей доступности, то я тут предпочитаю btsync. Расшариваешь по btsync каталог, одна машина пишет, другие у себя сидят и ждут данные по inotify. btsync работает очень эффективно и шустро. Не требует явного включения машины, как в syncthing. Отлично работает за любыми nat... У меня сейчас в infonesy данные именно по btsync распросраняются. Годится любой протокол, но btsync — самый удобный.

А ipfs хорош, когда нужно отдать файл на долгое хранение и иметь к нему быстрый доступ через web.

Но кешировать произвольные там тоже нельзя, как я понял. Либо нужен какой-то просмотр всех блоков.

Если ты дёргаешь файл через гейт, он остаётся в кеше этого гейта, пока не будет выбит чем-то другим. Кешировать навсегда можно произвольные файлы — достаточно сделать ipfs pin add <hash> на любой ноде и он будет скачан и зафиксирован.

достаточно сделать ipfs pin add <hash> на любой ноде и он будет скачан и зафиксирован.

Нет, мне именно когда я не знаю хэша. А то иначе для хранения хэшей мне придется к внешнему блокчейну прибегать.

Но они там хвастаются повышением производительности в 0.4.

Хм. Да, выпуск 0.4 я прозевал. Оживились, значит :)

Нет, мне именно когда я не знаю хэша.

А как ты можешь хранить то, что не знаешь? :) А если речь о некой потоковой передаче или мониторинге для получения нужных тебе данных, то тут ipfs не годится. Отчасти подходит ipns, но это пока очень экспериментальная штука и очень концептуально смутная. Конечно, один модифицируемый хеш на ноду позволяет потом развернуть что угодно, но это не оптимальный вариант для передачи данных.

А то иначе для хранения хэшей мне придется к внешнему блокчейну прибегать.

Вот. А я для этого использую btsync. Когда человек пишет сообщение на одном форуме, то постинг кидается в btsync в каталог экспорта. Приёмная нода сидит на таком же каталоге у себя через скрипт на inotifywait и как только файл оказывается на месте — размещает его контент в своём форуме. Ноды в общем случае даже не знают ничего друг про друга. А ipfs используется для хранения аттачей. Чтобы картинки не гнать через btsync и чтобы приёмная нода могла обходиться небольшим местом на всяких VPS, не храня у себя десятки/сотни гигабайт аттачей...

На самом деле то, что вы так упорно называете UUID, зовется URI.

Неплохая отрезвляющая книга на тему: RESTful Web Services by Leonard Richardson, Sam Ruby.

Основная мысль: устраивать неоднозначность и вступать в коллизии с уже существующими стандартами - путь к забвению.

URI даже по аббревиатуре и смыслу — совсем не то :)

...

Но я, кажется, понял, что смущает — наличие домена в моих UUID? Это сделано просто для удобства человекочитаемости. Там запросто может стоять и UUID по RFC. Может и какой-нибудь URI.


Ещё раз рекомендую подумать над тем как назвать всеобщий уникальный идентификатор :) И стоит ли придумывать устоявшемуся много лет назад термину альтернативу только потому что недавно приняли RFC, оперирующий этим термином.

Если завтра придумают стандарт, по которому, скажем, JIT станут использовать для обозначения стандартного процесса конкретной виртуальной машины, скажем, в Java, то понятие Just-in-time для других языков использовать станет нельзя? :)

URI даже по аббревиатуре и смыслу — совсем не то

Вы не улавливаете тонкую суть.

всеобщий уникальный идентификатор

Не путайте уникальный и универсальный, выше по топику вы используете это как синонимы. Что бы называться, хотя бы даже формально UUID нужно быть универсальным (вы сами об этом говорите).

Далее запись:

ru.balancer.board.topic.39814

1) Не отвечает принятым критериям универсальности (викисловарь в помощь). 2) Является унифицированной - я четко вижу инвертированный домен, и далее точки, который (чисто интуитивно) похоже разделяют сущности в дереве иерархий (лучше бы в этом направлении покопать, чем бороться с UUID), это не (псевдо)рандомный набор символов.

И, да, это именно «URI в собственном прострастве имен»: ISBN (которым книжки обозначают) - это URI. Путать URL (в общепринятом понятии) и URI тоже не рекомендую, тут только педивики и маны вас спасут.

MD5

Однозначно в мусор. Уже 10 лет никто не использует, основная причина - существует несколько математических способов сильно упрощающих нахождение коллизий. Как хеш функция уже очень давно не актуально.

И, да, это именно «URI в собственном прострастве имен»: ISBN (которым книжки обозначают) - это URI.

Вам надо или крестик снять или...

URI — это RFC 1630.

Если Вы допускаете существование других «пространств имён URI», то допускаете использование аббревиатуры URI для понятий, не вписывающихся в этот RFC. Но тогда странно, что Вы не допускаете того же самого для аббревиатуры UUID.

MD5

Однозначно в мусор

Как только Gravatar и аналоги станут использовать что-то иное.

существует несколько математических способов сильно упрощающих нахождение коллизий

Зачем искать коллизии, если в передаваемый файл итак можно вписать что угодно? Вы не понимаете сути проекта. Ну да ладно, это Ваши трудности.

Блин, вы реально не догоняете.

Прежде всего URI - Uniform Resource Identifier. Го в википедию.

URI — это RFC 1630.

Открываем RFC1630 и читаем.

Universal Resource Identifiers in WWW
in WWW

...

Как только Gravatar

Это эталон чего?

Вы не понимаете сути проекта.

Попытка создать свой USENET с нуля - затея бредовая изначально. На потрещать в толксах сойдет, в глабальном плане сдохло еще не родившись.

in WWW

Ок. Моё использование UUID касается «in Infonesy». Так понятнее?

Блин, вы реально не догоняете.

Скажите это себе — так будет вернее :)

Пилю драйвер для Vanilla forum, чтобы, наконец, соединить, хотя бы начерно, несколько рабочих форумов.

Наткнулся на концептуальную проблему. Чувствовал, что с ней будет что-то не так и раньше, но сейчас упёрся лбом.

В Vanilla-форуме сделано не как у многих других, где первое сообщение топика является обычным сообщением-постингом, как и ответы. Тут текст первого поста хранится прямо в записи топика. И поэтому нельзя идентифицировать стартовое сообщение по post_id, оно определяется по topic_id.

Соответственно, если топики режутся/переносятся, то первое сообщение то конвертируется из топика в постинг, то из постинга в топик.

В результате нельзя гарантировать сохранность ID такого сообщения :-/

То есть, я могу передать в Infonesy UUID такого поста равным UUID топика. И, наверное, пока так и придётся сделать. Но тогда, при операциях с топиками Vanilla, этот UUID может потеряться. Или будет указывать уже на другое сообщение.

Конечно, ещё есть вариант хранить в БД отдельные UUID и модифицировать их при операциях форума, но это многократно усложняет работу и требует вмешательства в код чужих плагинов (split/merge топиков).

Сложный, блин, случай :-/