Мы взяли идею использования WebIds для управления идентификацией в Интернете и применили ее к Сети SAFE.
Это продемонстрировало не только то, как самоутентификация может упростить множество проблем, возникающих в клиренсе (см. Аутентификацию ниже). Но также и то, как SAFE может обеспечить разработку приложений с нулевой инфраструктурой, позволяя любому легко создавать децентрализованные приложения такого масштаба.
Здесь мы поговорим о некоторых структурах данных в SAFE, которые обеспечивают наш WebId POC.
Это означает, что только с помощью url вы можете легко идентифицировать себя в сети для приложений и предоставлять этим приложениям информацию о себе (например, ... где находится ваш почтовый ящик).
Теперь с этой настройкой WebId мы используем стандартную настройку данных RDF и FOAF подробнее о RDF здесь и FOAF здесь ». Поэтому я не буду вдаваться в подробности этих. Выше вы можете увидеть, как это может быть полезно.
Я собираюсь рассказать о том, где мы храним RDF-данные WebId в SAFE, и как все это работает с нашей publicName системой.
Аутентификация
Прежде чем мы перейдем к сути управления данными, стоит отметить, как вы авторизуете свои веб-идентификаторы в SAFE.
В чистой сети вам понадобится совместимый сервер SOLID, сертификаты и браузер, настроенный для их использования. (Дополнительную информацию см. В вики)
В SAFE мы избегаем этой сложности, поскольку все ваши данные защищены системой Самоаутентификация. Это означает, что ваши данные надежно децентрализованы, без каких-либо проверок на серверах, все, что вам нужно для управления своими веб-идентификаторами, - это войти в систему!
Таким образом, в SAFE WebId становится намного намного проще в использовании. В конце концов, это просто данные ...
"Просто" данные
Документ профиля WebId - это набор данных, описывающих физическое или юридическое лицо (например, name, nickname, email), и чтобы он был действительным, он должен иметь разрешаемый URL. В SAFE, когда у нас есть данные с адресацией к контенту (что мы стремимся реализовать в ближайшее время), любые Изменяемые или неизменяемые данные (подробнее об этих типах данных см. В devHub) могут иметь такой адрес. На данный момент мы используем publicName систему SAFE, чтобы обеспечить простую, децентрализованную, удобочитаемую систему доменов. Таким образом, на документ вашего профиля ссылаются из вашего домена, что дает вам хороший URL-адрес, который можно передать людям.
_That_ Данные WebId
Сами данные WebId могут быть представлены таким образом (если вы используете JSON):
Он хранится в #me графике документа вашего профиля, который является RDF-эмуляцией изменяемых данных (дополнительную информацию о RDF в SAFE можно найти здесь).
Это этот документ профиля WebId, на который мы ссылаемся через наш subdomain RDF-MD ...
Поддомены
Каждый publicName в SAFE указывает на Mutable Data xorname, и именно эти Mutable Data фактически являются картой <subdomain>: <services>.
Так, например, сохраненные данные могут быть:
www : <NFS container xorname>, // link to website data on the network @email : <email inbox xorname>, // link to a MD used as an inbox, myid: <WebId xorname>
Прямо сейчас, с нашей веткой WebId Proof of Concept (POC), safe_app_nodejs, MD поддомена является RDF-MD (и, следовательно, самоописывающимся 🎉), который функционирует почти так же, как RDF в открытой сети (хотя лучший способ получить к нему доступ - через вилку RDF API safe_app_nodejs).
Дружественные домены
В SAFE наша система DNS представляет собой просто этот поддомен MD, но он расположен в хеш-коде sha3 имени домена (который разрешает быть допустимой сетью xorname).
Вот как мы создаем удобные для человека URL-адреса. Для каждого publicName, который мы создаем, ссылка сохраняется в _publicNames контейнере пользователя, чтобы он мог найти свой MD (права на управление которым есть только у них) для обновления поддоменов и последующих служб.
Все это позволяет нам легко хранить и ссылаться на ваш WebId по удобному для человека URL-адресу. И с помощью этого URL-адреса вы можете получить доступ к своей личности или личности других людей. И взаимодействуйте с ними через наше простое социальное приложение
Помощники
Последней частью новой настройки WebId стало использование «каталога» для помощи в поиске WebId (чтобы избежать повторения и расшифровки publicNames, получить subdomains, а затем проверить каждый service, чтобы убедиться, что это документ профиля!)
Поэтому мы решили хранить каждый созданный WebId в качестве ключа в public контейнере, обеспечивая удобную точку отсчета для получения всех WebId (что можно сделать с помощью функции новые DOM API app.web.getWebIds()).
Использование веб-идентификаторов
Как только мы выяснили, как хранить веб-идентификаторы в сети, мы столкнулись с вопросом, как, черт возьми, пользователь будет управлять своими новыми найденными идентификаторами (при условии, что они создали некоторые из них с помощью веб-идентификатор-менеджер ).
С этой целью мы реализовали раскрывающийся список в Просмотр (наш БЕЗОПАСНЫЙ браузер), чтобы пользователи могли выбирать веб-идентификатор вкладки для использования. (Сам браузер Peruse использует указанный выше getWebIds() для получения этого списка.)
И с этим мы реализовали другой метод для веб-приложений, чтобы легко получить предоставленный WebId из DOM. Таким образом, веб-приложениям вообще не нужно беспокоиться об управлении веб-идентификаторами, они могут сосредоточиться на использовании данных. Не нужно запрашивать разрешения для _public контейнера, если он вам не нужен!
Есть два способа передачи веб-идентификаторов в DOM:
Если WebId был установлен или обновлен на вкладке, currentWebId был обновлен. Это объект javascript, который содержит полные данные документа профиля.
Каждый раз, когда WebId вкладки обновляется, в DOM запускается событие. Вот как patter.js с этим справляется.
window.webIdEventEmitter.once( 'update', ( webId ) =>
{
console.log('WebId updated!', webId)
} );
};
И теперь вы готовы обновить свое приложение, указав желаемый идентификатор пользователя. Укажите имена, изображения профиля или их расположение в почтовом ящике.
С помощью WebId, подтверждающего концептуальные приложения и API, вы действительно можете сосредоточиться на создании отличного децентрализованного приложения. Вам не нужно беспокоиться об инфраструктуре, серверах REST API или аутентификации пользователей. Просто создайте.
Если вы хотите узнать больше о Безопасной сети, перейдите на DevHub или присоединяйтесь к нам на форумах!
