Идентификаторы для ролей
Когда-то я написал пост "Идентификация 4D-документов через криптохэши", и с тех пор неоднократно давал на него ссылки. Реакции были как "примерно понятно, но терминология 3D/4D сложна для восприятия". Да и сами по себе BORO и ISO 15926-2, откуда я (привычно) взял эту терминологию, достаточно тяжеловесны.
Так что, в 2019 году я перешёл к использованию другого термина - "роль". Сначала сам, потихоньку оценивая, а после дискуссии https://ailev.livejournal.com/1470152.html?thread=16180424#t16180424 термин был применён ailev в новой редакции его книги "Системное мышление", хоть и не в таком широком определении, но тоже к месту. Настало время и мне обновить старые материалы.
Роль - то, что имеет идентификацию, но в разных контекстах представлено разными состояниями/значениями.
Роль "яблоко на столе". Час назад его не было, сейчас оно есть, через 5 минут будет надкушено. Это разные состояния в контексте. Роль "переменная app.current_view.selected_items", значение которой меняется в разные моменты времени. Роль "файл readme.md в git-репозитории такого-то проекта на github" - зависит от ветки и момента запроса или от выбранного коммита. Пост "путешествие" в блоге, который может быть отредактирован спустя некоторое время.
Но насколько хорошо специфицирована роль? Что если в контексте есть несколько столов с возможными яблоками? Что если в блоге несколько постов "путешествие", причём, некоторые из них в одни и те же дни? Ок, можно роль специализировать. "Яблоко на столе сразу слева от входа". Или завести реестр столов, с описаниями и номерами, и использовать "яблоко на столе N1". Аналогично, постам в блоге присваиваются номера или специальные псевдослучайные коды. Номер может быть присвоен через запрос к центральному реестру, которым резервируется данный номер для поста, и никак иначе. Но если реестр будет скомпрометирован или утрачен - идентификация сломается. Псевдослучайный код может быть сгенерирован без реестра, и, при достаточной длине, тоже будет уникально идентифицировать отдельно взятый пост "путешествие". Однако, любой злоумышленник может заявить, что данный код идентифицирует не ваш пост "путешествие", а его статью "100500 лайфхаков успешных людей". Но у этой проблемы есть решение.
В качестве идентификатора роли можно использовать криптохэш от полного описания роли на момент её создания.
Вы пишете пост "путешествие". Его содержимое плюс дата и подпись описывают как роль, так и инициальное состояние/значение этой роли. Далее для идентификации поста можно использовать криптохэш от его же блоба (например, role_sha256). Который изначально совпадает с идентификатором версии (например, data_sha256). Спустя пару дней вы редактируете пост, указывая, что новый документ представляет собой актуальную версию поста с таким-то role_sha256, но data_sha256 будет уже от блоба новой версии. А в ссылках на пост "путешествие" можно одновременно указывать и role_sha256, и data_sha256 той версии, которая была актуальна на момент создания ссылки. Если реципиентов устраивает подпись на новой версии (в большинстве случаев достаточно, чтобы это была та же подпись, что на первой), то они её принимают как актуальную.
Далее, у документов не обязательно только одна роль. Можно создать роль "Блог Васи" - описание, дата, подпись, посчитали sha256 от блоба. И далее указывать это значение как (например) role_of_whole_sha256 во всех постах блога. Можно отдельными документами создавать дайджесты - полные списки постов (и их актуальных версий) такого-то блога в разные моменты времени. Само описание роли может измениться со временем, и сменить название блога на "Блог Васи о путешествиях", не меняя идентификации. Таким образом решается вечная проблема Wikipedia, где при смене названий статей или вставке disambiguation pages часто остаются поломанные ссылки. Более того, "Блог Васи" может превратиться в "Блог Васи и Маши", если новое состояние этой роли содержит некое указание, что в блог теперь можно писать и с подписью Маши, а не только с подписью Васи.
В пределе описание роли может содержать смарт-контракт, описывающий все возможности изменения состояний, её представляющих. Однако, в большинстве случаев достаточно самого наличия первой версии документа и указания role_sha256 в любых последующих/альтернативных.
Так что, в 2019 году я перешёл к использованию другого термина - "роль". Сначала сам, потихоньку оценивая, а после дискуссии https://ailev.livejournal.com/1470152.html?thread=16180424#t16180424 термин был применён ailev в новой редакции его книги "Системное мышление", хоть и не в таком широком определении, но тоже к месту. Настало время и мне обновить старые материалы.
Роль - то, что имеет идентификацию, но в разных контекстах представлено разными состояниями/значениями.
Роль "яблоко на столе". Час назад его не было, сейчас оно есть, через 5 минут будет надкушено. Это разные состояния в контексте. Роль "переменная app.current_view.selected_items", значение которой меняется в разные моменты времени. Роль "файл readme.md в git-репозитории такого-то проекта на github" - зависит от ветки и момента запроса или от выбранного коммита. Пост "путешествие" в блоге, который может быть отредактирован спустя некоторое время.
Но насколько хорошо специфицирована роль? Что если в контексте есть несколько столов с возможными яблоками? Что если в блоге несколько постов "путешествие", причём, некоторые из них в одни и те же дни? Ок, можно роль специализировать. "Яблоко на столе сразу слева от входа". Или завести реестр столов, с описаниями и номерами, и использовать "яблоко на столе N1". Аналогично, постам в блоге присваиваются номера или специальные псевдослучайные коды. Номер может быть присвоен через запрос к центральному реестру, которым резервируется данный номер для поста, и никак иначе. Но если реестр будет скомпрометирован или утрачен - идентификация сломается. Псевдослучайный код может быть сгенерирован без реестра, и, при достаточной длине, тоже будет уникально идентифицировать отдельно взятый пост "путешествие". Однако, любой злоумышленник может заявить, что данный код идентифицирует не ваш пост "путешествие", а его статью "100500 лайфхаков успешных людей". Но у этой проблемы есть решение.
В качестве идентификатора роли можно использовать криптохэш от полного описания роли на момент её создания.
Вы пишете пост "путешествие". Его содержимое плюс дата и подпись описывают как роль, так и инициальное состояние/значение этой роли. Далее для идентификации поста можно использовать криптохэш от его же блоба (например, role_sha256). Который изначально совпадает с идентификатором версии (например, data_sha256). Спустя пару дней вы редактируете пост, указывая, что новый документ представляет собой актуальную версию поста с таким-то role_sha256, но data_sha256 будет уже от блоба новой версии. А в ссылках на пост "путешествие" можно одновременно указывать и role_sha256, и data_sha256 той версии, которая была актуальна на момент создания ссылки. Если реципиентов устраивает подпись на новой версии (в большинстве случаев достаточно, чтобы это была та же подпись, что на первой), то они её принимают как актуальную.
Далее, у документов не обязательно только одна роль. Можно создать роль "Блог Васи" - описание, дата, подпись, посчитали sha256 от блоба. И далее указывать это значение как (например) role_of_whole_sha256 во всех постах блога. Можно отдельными документами создавать дайджесты - полные списки постов (и их актуальных версий) такого-то блога в разные моменты времени. Само описание роли может измениться со временем, и сменить название блога на "Блог Васи о путешествиях", не меняя идентификации. Таким образом решается вечная проблема Wikipedia, где при смене названий статей или вставке disambiguation pages часто остаются поломанные ссылки. Более того, "Блог Васи" может превратиться в "Блог Васи и Маши", если новое состояние этой роли содержит некое указание, что в блог теперь можно писать и с подписью Маши, а не только с подписью Васи.
В пределе описание роли может содержать смарт-контракт, описывающий все возможности изменения состояний, её представляющих. Однако, в большинстве случаев достаточно самого наличия первой версии документа и указания role_sha256 в любых последующих/альтернативных.