Одна из первых проблем, с которыми мы столкнулись при использовании системы p2p для обмена данными
, заключается в том, как создать единый источник истины, когда вы можете захотеть отозвать
доступ или изменить данные в любой момент? Как эти изменения
отразятся в p2p-сети? Мы рассмотрели несколько идей по этому поводу, используя
базу данных SQL, использование HyperDB, рекурсивное шифрование с использованием HMAC, а также базу данных NoSQL. В основе каждого использования мы используем Dat, чтобы в конечном итоге обмениваться этими данными через встроенную сеть p2p. Чтобы ответить, какое из этих решений будет работать лучше всего, нам нужно ответить на несколько вопросов о том, что является единым источником истины, что означает подписка на данные и как можно реализовать детальный контроль для каждого набора данных? Я отвечу на эти вопросы в следующих разделах.

Единый источник истины

Так что же является единственным источником истины? В Lens мы определили, что это данные, в которых исходный набор данных принадлежит конечному пользователю и может быть изменен только этим конечным пользователем. Все остальные изменения могут быть легко отклонены базовой сетью. Кроме того, любое изменение, которое делает пользователь, в конечном итоге отразится на всей сети. Поэтому, если я хочу поделиться своим номером телефона с несколькими различными службами или пользователями, я даю им ссылку на этот номер. В результате, когда мне нужно изменить этот номер, мне не нужно обращаться к каждой из этих сущностей отдельно и обновлять номер телефона. Я просто обновляю номер в одном месте, и все остальные подписчики получат эти изменения. Таким образом, единый источник правды
действительно означает, что вы можете обновлять информацию для всех, кто в ней заинтересован! Это подводит нас к следующему вопросу: как мы можем детально контролировать эти данные? Т.е. может быть, я хочу поделиться своим рабочим телефоном только с одним человеком, а мой мобильный - с другим, как мы можем реализовать это с помощью единого источника правды?

Детальный контроль доступа

Есть несколько способов реализовать контроль доступа к данным. По сути,
мы хотим предоставить аналогичную систему, которую Linux предоставляет пользователям на одной машине. Например, каталоги пользователей полностью скрыты от других пользователей, если явный доступ не предоставляется другому пользователю от владельца. Это известно как безопасность на основе возможностей и представляет собой механизм, который используется в Lens для предоставления детализированного доступа заинтересованным сторонам от владельца данных. Мы распространяем эту идею на одноранговую сеть, чтобы данные можно было публиковать и подписывать на них из одного блока данных. Итак, как мы можем достичь этой цели?

Реализация списков контроля доступа в сети P2P

Как мы уже упоминали ранее, мы строим большую часть нашей P2P-инфраструктуры из библиотек, созданных для datProject. Сам datProject - это система возможностей. Другими словами, ключ шифрования, размещенный в P2P-сети, невозможно определить, поэтому он должен быть передан желаемой стороне вне полосы пропускания. Таким образом, единственный способ получить доступ к моим данным - это узнать мой URL-адрес dat. Например, я мог бы создать следующий объект JSON для представления моей контактной информации и сохранить этот файл в каталоге:

{
          firstName: "Cody",
          lastName: "Eilar",
          phoneNumber: "+15051234567"
}

Теперь, чтобы поделиться этой информацией с другой стороной, я бы просто зашел в свою директорию
и затем запустил `dat share .`. Это сгенерирует хороший URL-адрес, например:

dat://9a09dfc51caaa261d71024742888868b7a440fff1474235850713e5dec69f685

Теперь, когда я дам этот URL этой стороне, они смогут сделать dat clone dat: 9a0…, чтобы получить мои данные! Вуаля, у нас есть система возможностей. Теперь, если я хочу поделиться своим единственным источником истины с другими пользователями, я просто даю им свой URL-адрес. Таким образом, если бы мой номер телефона действительно изменился, все, что мне нужно было бы сделать, это обновить данные в моем каталоге данных. Однако есть небольшая проблема. Что, если я хочу сейчас запретить доступ конкретному человеку? Одним из способов было бы удалить данные в этом URL-адресе данных, создать новый и передать этот новый URL-адрес всем людям, у которых должен быть доступ. Этот процесс станет довольно громоздким, и его будет трудно отслеживать. Вот где действительно может пригодиться программирование!

Первый метод, который мы реализовали здесь, в Lens, связан с синхронизацией всех исходных данных со всеми объективами, которые являются общими. Процесс состоит из нескольких этапов:

  1. Пользователь создает источник данных
  2. Пользователь создает линзу из одного или нескольких источников данных и их полей.
  3. Пользователь делится Объективом с заинтересованными сторонами.
  4. Когда пользователь обновляет какие-либо поля в источниках данных, линза обновляется автоматически.

Поэтому, когда пользователь обновляет свои данные, все подписки на линзы также обновляются. Именно здесь наличие линзы к данным становится очень действенной концепцией. С помощью этого метода компании, которым нужна законная подписка на ваши данные, просто подписываются на ваш объектив. Затем, если им когда-нибудь понадобится загрузить это в базу данных, у них всегда будет последняя версия данных, которыми вы хотите поделиться с ними. В качестве примера предположим, что у вас есть друзья, которые хотят открыть мороженое. В качестве одного из первых шагов в поиске ресурсов для этого нового бизнеса они просят у вас линзу для вашего любимого мороженого, а также на ваш адрес электронной почты, чтобы они могли связаться с вами по поводу вашего любимого мороженого. В результате вы даете им индекс Lens, который объединяется с различными схемами данных, которые хранятся в вашем Lumen. Первая схема данных называется «Контактная информация» - здесь вы храните свою последнюю контактную информацию, которую хотите предоставить. Вторая схема называется «Избранное» - здесь вы хотите сохранить список избранных в мороженом, пиве и т. Д. Вам не нужно делиться каждой схемой полностью, вы просто хотите поделиться частью каждого. В результате программное обеспечение объектива создает объектив из каждого из этих источников данных и ссылается на исходный набор данных, таким образом, все можно синхронизировать. На рисунке ниже показан этот процесс.

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

Недостатки текущей реализации

Одна из проблем с реализацией выше заключается в том, что теперь мы должны создать URL-адрес dat для каждого бита данных, который может быть запрошен у нас. Сначала это может показаться не проблемой, но наше цифровое «я» только растет, а не сокращается. Все больше и больше нашей жизни оцифровываются для удобства, подотчетности, доступности и многого другого. Сегодня я немного просмотрел свой менеджер паролей и понял, что у меня более 200 учетных записей на разных сайтах. Конечно, я создавал эти учетные записи на протяжении всей жизни, но их количество не уменьшится. Таким образом, у наших пользователей могут быть как минимум сотни, если не тысячи линз. Это становится трудным с технической точки зрения, потому что в системе доступно не так много портов и дескрипторов файлов, что в конечном итоге у нас закончится. Не говоря уже о том, что текущие реализации протокола Dat используют довольно много памяти на общий ресурс. Однако для нашего раннего продукта это ограничение не будет проблемой.

Будущие реализации

Разработчики Lens проводят мозговой штурм, чтобы преодолеть ограничения, связанные с тем, что тысячи данных используются в одном Lumen. Один из альтернативных методов, который мы использовали, - это идея иерархического шифрования всех источников данных в просвете и выдачи ключей заинтересованным сторонам. С такой системой нам больше не придется поддерживать парадигму привязки данных, представленную в предыдущих разделах, а скорее придется отслеживать список управления доступом для каждого значения данных внутри каждой схемы. Мы провели несколько экспериментов, основанных на отличном посте от Substack.

Завершение

Я использовал много слов, чтобы описать, как мы работаем над единственным источником истины, но более технически подкованные люди могут быть заинтересованы в простой реализации. Я написал небольшой тестовый скрипт с использованием PouchDB, базового шифрования паролей и некоторых имитационных функций для создания общих ресурсов Dat (логика для этого может быть довольно сложной, и в результате я не включил ее). Пожалуйста, взгляните ЗДЕСЬ и дайте мне знать, что вы думаете!