Валерий Крылов (justy_tylor) wrote,
Валерий Крылов
justy_tylor

Category:

Идентификация 4D-документов через криптохэши

Сейчас обнаружил, что с прошлого года так и не опубликовал пост на тему идентификаций 4D-документов. Собирался доформулировать некоторые аспекты использования таких идентификаций в языках запросов, но там как-то само фоном дошло, и это явно материал не для одного поста.

Предыстория.

Вышел тогда летом у vitus_wagner пост с отсылкой к старой теме чеширнета (децентрализованная соцсеть), а у меня тогда мысли витали в близких направлениях (пересылка произвольных документов между личными и корпоративными системами менеджмента данных, с автоматическим встраиванием на корректную позицию, проверками целостности, etc), так что в поисках вдохновения я решил перечитать уже порядком подзабытое из https://vitus-wagner.livejournal.com/tag/cheshirenet

В чеширнете также предполагались некие типы документов и возможность публикации обновлённых версий существующих документов. Но меня смутил предлагаемый способ идентификации самих документов - на основе псевдослучайных UUID (GUID) из RFC 4122. Ещё обдумать не успел, а подсознание уже указывает: "грабли здесь, грабли".

Ведь можно взять любую отдельно взятую систему (или несколько), и заменить там сообщение с важной новостью от Пети на собщение с котофоточками от Васи, без какого-либо изменения UUID. А дальше - выяснение "что же там было на самом деле", поиск консенсуса, и прочие действия, которых можно избежать. И вот как.

Идентификация 4D-сущностей через криптохэши.

Для начала уточним терминологию. Статичный (неизменяемый) документ или отдельно взятое состояние изменяемого документа легко идентифицируются криптохэшем от данных (и иногда - от дополняющих их метаданных). Это используется во множестве современных технологий: системы контроля версий, документориентированные СУБД, magnet-ссылки и прочее. Такие неизменяемые документы или состояния/версии документов это 3D-документы, они не зависят от времени.

В свою очередь, есть 4D-документы, редактируемые. Их содержимое может быть изменено или заменено в разные моменты времени (причём, разным образом в разных возможных мирах, но не будем сейчас углубляться в эту тему). 4D - потому что появляется время как измерение (более подробно про 4D можно прочитать в BORO или ISO 15926). Соответственно 4D-документ имеет свою отдельную идентификацию, а его содержимое представлено множеством 3D-документов (версий), в зависимости от времени и других условий.

Например, обыденными идентификаторами для 4D-документов являются пути в файловое системе и HTTP/HTTPS-ссылки. Но для них необходима централизация для обеспечения уникальности, в первом случае осуществляемая операционной системой, а во втором процедурами DNS. Или альтернатива - те самые псевдослучайные UUID (GUID).

Но есть и другой способ. Если первая версия 4D-документа создаётся именно как версия (для чего достаточно, например, наличия даты и криптографической подписи), то сам 4D-документ можно идентифицировать под криптохэшу первой версии.

Пример: вы написали новую статью и запускаете её в сеть (с датой и подписью). SHA-256 от 3D-документа первой версии будет "NNN...". Затем вы обнаружили несколько опечаток и публикуете вторую версию статьи. В метаданные этой и всех следующих версий также добавляется запись "document_id:sha256:NNN...". Дата, подпись.

Чем это лучше использования псевдослучайных значений? Если идентификация 4D-документа делается по криптохэшу первой версии, то можно проверить:
1. Что некий предлагаемый 3D-документ является первой версией обсуждаемого (так как совпадёт криптохэш).
2. Что некая предлагаемая новая версия документа содержит ту же подпись, что и первая версия документа - для этого достаточно одновременно предоставить первую версию, с нужным криптохэшем.

Чуть отвлечённо.

Вообще, имеет смысл и гибридная идентификация документов, 4D и 3D одновременно. Ситуация: автор написал статью, затем обновил, вы оставили комментарий об оставшихся неточностях, автор обновил ещё раз, и теперь ваш комментарий не соответствует содержимому статьи и выглядит странно. Этого можно избежать, если документ с комментарием содержит как идентификацию 4D-документа статьи, так и идентификацию 3D-документа той версии, на которую вы отвечали: "in_reply_to(document_id:sha256:NNN1..., version_id:sha256:NNN3...)".

В общем, используйте. Возможно вам пригодится. Возможно мне пригодится.
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 6 comments