SAFE Network новини – 12.12.2019
Накратко
Ето някои от основните неща тази седмица:
- Споделеният Трезор е актуализиран до последната версия и съответно изисква нов конфигурационен файл.
- Разглеждаме по-подробно как можем технически да приложим Данни с етикети.
- В CLI бяха внедрени някои незначителни подобрения, като например възможността да се използва CLI в режим само за четене при заявяване на публични данни.
- Членът на общността @danda представи друга функция за изпълнение, за да позволи на командата
files addда чете съдържанието на файла, който се добавя от stdin (вместо от локален път).
Обновяване за Споделения трезор
Днес актуализирахме Споделения трезор от версия 0.19.2 до версия 0.20.1. Както винаги, всяко рестартиране на трезора означава нов конфигурационен файл за него, така че качихме последния конфигурационен файл в S3 тук. Ако искате да използвате Споделения трезор, моля, изтеглете този файл и го запишете на подходящото място на компютъра ви. Обърнете внимание, че решихме да извадим конфигурационния файл на трезора от GitHub и да го хостваме в S3, така че той не се отнася до нито една конкретна версия на GitHub.
Можете да си припомните как да се свържете със Споделения трезор, къде да запазите този конфигурационен файл или как да стартирате свой собствен локален трезор тук.
Важна забележка - в SAFE трезора версия 0.20.x форматът на данните е несъвместим с формата на данните от версия 0.19.x, следователно новият Споделен трезор, който стартирахме, е изчистен, без данни в него. Ако имате локален трезор, работещ с версия 0.19.x и надграждате до 0.20.x, ще откриете, че данните от този трезор не се показват както се очаква. Препоръчваме да качите отново всички данни / сайтове и т.н. в новия трезор, локален или споделен.
Трезори – Фаза 2
Напреднахме добре в тестовете на трезорите и интегрирането им реалната маршрутизация (с тестови parsec). Клиентските заявки вече могат да се обработват от виртуалната мрежа от трезори, създадена от маршрутизацията, и можем да започнем да тестваме различни сценарии, свързани с наличието на мрежа от много трезори. Искането за въвеждане на промените в момента се преглежда и се очаква да бъде обединено, след като разрешим проблем със случайния генератор. Предварително захранения RNG е важен за предсказуеми тестове, но установихме, че той се държи несъвместимо между контейнерите на маршрутизацията и трезорите.
Актуализираният процес на съгласуване на клиентите за свързване към трезорите напредва по-нататък, както от страна на клиента, така и от трезора, и заявката за въвеждане в момента се преглежда. Изглежда, че работи добре, но трябва да проведем още няколко теста, преди да можем да я обединим в кода.
SAFE API
След пускането на версията от миналата седмица, през последните няколко дни се фокусирахме върху технически задачи, който ни бяха останали за довършване в хранилището на safe-api. Например актуализирахме скриптовете за публикуване, за да пускаме само файлове за свързване към истински трезор, тъй като вече няма да публикуваме файлове за използване на тестовата мрежа в Safe-api версиите ни. Използването на тестовата мрежа все още е възможно, но разработчиците, желаещи да направят това, ще трябва сами да изградят артефактите, следвайки инструкциите от съответните README файлове.
Успяхме да надстроим до последния версия в хранилището safe_client_libs, което ни позволява да активираме отново тестове от край до край (e2e) в CI процеса. Автоматичните тестове за safe-cli вече ще се изпълняват в GitHub Actions (GHA) за всеки PR, както беше преди в Jenkins. Тази първа група от e2e тестове все още използва тестовата мрежа, но вече имаме всичко готово да ги стартираме и с локален трезор в GHA, веднага щом открит проблем (очевидно в трезора) е решен.
Някои незначителни подобрения също бяха внедрени в CLI, като например CLI да може да се използва в режим само за четене, когато се работи с обществени данни. Например използването на командата cat или dog на публичен уебсайт няма да изисква CLI-то да бъде упълномощено. Това е хубава стъпка по отношение на UX, тъй като потребителят може да иска да работи с публични данни от мрежата с помощта на CLI и няма да е необходимо да се логва в системата и / или да упълномощава CLI за това, което го прави толкова лесно, колкото разглеждането на обществени данни от SAFE браузъра.
Друга реализация на функция, представена от @danda през последните няколко дни, беше да се даде възможност на командата files add да чете съдържанието на файла, който се добавя от stdin (вместо от местен път). Това отваря възможността за използване на командата files add във верига от команди, което е нещо, което @danda също проучва, за да определи подходяща стратегия за всички команди в CLI.
И накрая, започнахме да разглеждаме добавяне на функция, предложена от общността, чиято цел е да можем да получаваме XOR-адреси на файлове, без да ги качваме в мрежата, т.е. да разширим --dry-run опцията да работи с файлове, а не само с контейнерите им когато се изпълняват командите files put или files sync . Работим върху добавянето на такава възможност първо в SAFE Клиентските библиотеки, така че след това да можем правилно да дадем достъп до нея от safe-api и CLI, заедно с нова safe xorurl команда от най-високо ниво, която да може да предоставя такава информация директно за локални файлове / папки.
SAFE Клиентски библиотеки
Екипът започна работа по връщането на куп тестове, които бяха деактивирани по време на миграцията от тестово маршрутизиране към мениджъра на връзката. Тези тестове са предназначени предимно за тестване на настройката за тестовата мрежа в SAFE Клиентските библиотеки, без да се отчита какъвто и да е клиент или акаунт. С обединяването на PR-и #1106 и #1109, тестовете вече са активирани отново.
Междувременно помагаме и на останалата част от екипа с Етикетите на данни RFC. Все още сме в началните фази на дискусията и вече има много коментари. Присъединете се към нас в конкретната тема, ако още не сте го направили.
На CI / CD фронта напълно пренесохме нашата работа в GitHub Actions и пуснахме най-новите версии на библиотеките ни. Обърнете внимание, че новите версии на контейнерите все още не са публикувани. Публикуването на нови версии и на трите контейнера (SAFE Core, Authenticator и App) е доста просто. Търсим подход, при който бихме могли селективно да надстройваме конкретни контейнери. Това е последната стъпка към първоначалната миграция към GitHub Actions. Ще търсим начини да подобрим скоростта на изграждане, като използваме кеширане и т.н.
Продължаваме да разработваме подробностите и API-тата за новия мениджър на връзки. Сега, когато внедрихме новия процес на свързване за клиентите, липсват още някои подробности: някои от API-тата, свързани с прекъсване на връзката и уведомяване за промените в състоянието на връзката, трябва да бъдат преразгледани по отношение на новия подход за свързване с трезорите. След като обединим новата реализация на протокола за свързване при Трезорите, най-накрая ще можем да започнем да тестваме клиента с множество трезори, работещи в рамките на секция.
Етикети за данните и споделяне
След много дискусии в темата за предварителното RFC върху етикетите за данни, разглеждаме по-подробно как можем технически да приложим това и каква работа ще бъде включена.
Дискусиите все още продължават, но вече се концентрираме около подход, който използва споделяне на BLS ключове за обработка и проверка на етикетите на данните. Този подход ще използва нашата сегашна система от разрешения за данни, която поддържа нещата гъвкави там, но също така ни дава допълнително предимство: способността да споделяме частна информация.
С помощта на споделянето на BLS ключовете, приложенията ще бъдат снабдени със собствени ключове за подписване, които DataHandler ще може да провери и да верифицира присъствието на етикета върху дадени данни. Което означава, че споделянето на данни ще бъде възможно чрез генериране на нов KeyShare , който ще бъде даден на друг акаунт, и докато съответният етикет присъства на данните, обработващият данните ще разреши работата с тях. (Оставяйки ClientHandler да управлява приложенията и да проверява нещата на ниво акаунт.)
Така че сега влизаме в нестабилната част на предложението, проверяваме структурата на данните и търсим частни случаи. Всичко това ще подготвим скоро в пълноправен RFC.
SAFE Network програма (мобилни устройства)
Тази седмица се фокусирахме единствено върху приложението SAFE Network за мобилни устройства и постигнахме значителен напредък, като става въпрос за добавяне на нови страници и подобрения. Добавихме страница за създаване на акаунт, подробности за приложението и страница с настройки. Останаха само две страници, които да бъдат добавени в приложението от страна на дизайна.
Добавихме проверка в приложението, за да проверим дали SAFE мобилния браузър вече е инсталиран на устройството или не. Ако браузъра е инсталиран, тогава страницата за стартиране показва банер, от който потребителят може директно да премине от SAFE Network програмата към браузъра, а ако не е инсталиран ще предоставим връзка, от която можете да изтеглите мобилния браузър.
Подобрихме логиката за навигация и жестове, така че сега е лесно да навигираме между всички страници. Тези подобрения включват също добавяне на жестове за навигация за множество изгледи тип въртележка, реализирани на различни страници и затваряне / отваряне на изскачащи страници.
Тъй като първоначално прескочихме задачите за стилизиране за всички страници, тази седмица започнахме да пренасяме цветове, теми и стилове от дизайните към кода и да актуализираме страниците, за да използваме същите.
SAFE Удостоверител (мобилни устройства)
Направихме някои малки преструкториращи промени в приложението за удостоверяване на мобилни устройства, за да подобрим потребителското изживяване около избора за свързване с различни трезори, PR за същото се преглежда и скоро ще бъде обединен.
Стареене на възел (Node Ageing)
Все още напредваме с работата по повишенията (възрастни към старейшини) и пониженията (старейшини към възрастни) (PR 1929). Обединихме редица PR, които извадихме като самостоятелни части, необходими за завършването на тази работа. В момента работим по по редките провалили се тестове. Основната оставаща трудност е подсигуряването във всички случаи, че в случай на промяна на старейшина или разделяне на секция, всички необходими старейшини получават и гласуват за събитията, които се нуждаят от консенсус.
Полезни линкове
- Официален сайт на SAFE Network
- Обобщено представяне на SAFE Network
- SAFE Network Фундаменти
- Карта на проекта
Подробна информация може да намерите както винаги във форума на международната общност: SAFE Network Forum
Ако имате въпроси може да ги зададете във Facebook групата на българската SAFE общност: SAFEnetwork България | Facebook
Ако искате да следите последните новини заповядайте във Facebook страницата на SAFE Network България: Safe Network България