Идентификация 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...)".
В общем, используйте. Возможно вам пригодится. Возможно мне пригодится.
Предыстория.
Вышел тогда летом у 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...)".
В общем, используйте. Возможно вам пригодится. Возможно мне пригодится.