SAFE Network новини – 12.9.2019
Маркетинг
Тази седмица маркетинговия екип беше фокусиран върху създаването на ново съдържание. Публикувахме нова статия в Medium разглеждаща новите типове данни (въпреки, че технически публикувахме статията миналата седмица 
) за да покажем някои от различните вариации на данните и как те могат да се свържат заедно за да създадат нещо невероятно. Също така публикувахме продължение към Фаза 1 на Трезорите, разглеждащо малко по-подробно какво е включено (основно фокуса е върху новите CLI-та). Все още не сме публикували тези статии във форума, затова ако искате да ги има и само кажете и ще ги добавим веднага!
Сутринта изпратихме и имейл с първите септемврийски новини, разглеждащ фалшификатите. Ако не сте се абонирали за имейл новините, защо да не го направите сега?! Посетете safenetwork.tech за да получавате имейл на всеки две седмици. Пуснахме и туитър буря фокусирана върху новини от изминалата седмица и нещо.
И докато създавахме всички тези материали също така работихме и върху план за маркетинговия ни фокус в следващите няколко месеца, като идеята е да се насочим основно към DApp разработчиците. С напредването на работата по новите CLI-та и Трезори е перфектното време да вдъхнем отново живот към тях и да приканим нови програмисти да се включат. Ще споделим плановете ни с напредването на работата.
Трезори - Фаза 2
Фаза 2 на Трезорите премина от плануване към разработка 
Фаза 1 (единичен, истински трезор) е завършена и се насочваме с пълна сила към Фаза 2.
Както е видно идеята ни е да създадем минимално необходимото работеще решение и в последствие да надграждаме върху него. С тази цел Фаза 2 на Трезорите е разделена на две подфази. Фаза 2а ще разшири архитектурата на единичния трезор от Фаза 1 до няколко трезора, но само в една секция. Фаза 2б ще надгради над това и ще има освен множество трезори и множество секции.
Това е доста вълнуващо, защото това е фазата, в която гумите се срещат с пътя. Това е частта, в която продължаваме към създаването на децентрализирана мрежа и интегрираме консенсусния механизъм.
Отбелязали сме основните задачи в плана на проекта, покриващи най-важните изисквания, като най-голямото е интегрирането на трезора с рутинга на PARSEC.
Поради комплексността на Фаза 2 ще добавяме в плана конкретните задачи за всяка основна част от плана след като завършим предната. Така въпреки че основните частти ще останат статични, с напредването на работата ще забележите нарастването на броя нови задачи. Но разбира се това ще значи, че сме завършили голяма част от тях
Екипа за Трезорите започна първоначалната работа по добавянето на тестови рутинг към Трезорите преди да интегрираме истинския.
Друга част от разработката е в рутинга и по точно как ще се справя с изчистването (Pruning) на Parsec. Това е нужно за да гарантираме, че няма постоянно да увеличаваме използването на памет от компютъра и количеството информация, която ще трябва да се изпраща към новоприсъединяващи се компютри. За да постигнем това ще използваме настоящия механизъм, който създава нова Parsec връзка в случай на разделяне на секция.
Още една новина свързана с трезорите от тази седмица. По време на тестовете @karamu откри прекъсващ проблем, при който файл, който изглежда качен на споделен трезор не може да се свали обратно. След известно разследване @nbaksalyar успя да останови първопричината: споделения трезор е качен на Mac компютър, който от време на време изчиства временната информация и това може да доведе до загуба на непроменими парчета данни. Проблемът е въпрос на конфигурация и днес направихме необходимите промени в конфигурацията на споделения трезор за да го отстраним. Поправка в PR форма ще бъде пусната също така. За да се свържете със споделен трезор ще трябва да обновите вашия файл vault_connection_info.config с последната версия от нашия GitHub . Вижте оригиналната публикация Трезор Фаза 1 (истински трезор) тук за пълни инструкции за това как да се свържете със споделен трезор или как да стартирате собствен трезор.
SAFE CLI
След като пуснахме миналата седмица версия 0.3.0 на SAFE CLI, подновихме работата по разработката на API-то от Високо Ниво и излагането му към други програмни езици като NodeJS. Успяхме да напреднем доста и въпреки че все още сме в ранен етап успяхме да създадем NodeJS свързаности за NRS , FilesContainers и fetch API-тата, и дори да ги използваме за SAFE Browser-а. Пуснахме и първия план на проек за NodeJS свързаността заедно с първите задачи върху, които ще работим.
От страната на SAFE CLI тази седмица работихме по въвеждането на Медия-тип (т.е. MIME-типове) в XOR-URL адресите генерирани при качване на файлове в мрежата. Вече имахме резервирано място за тях в XOR-URL кодирането, но не го използвахме досега. Това ще позволи на апликации, като SAFE Browser, да работят с файловете според медия-тип информацията записана в XOR-URL адреса. Това се прави чрез fetch HL API-то, както и с $ safe cat командата когато --info е предоставено.
Започнахме и въвеждането на ново API от високо ниво (и съответната $ files add команда към него), което ще позволи на потребителите да добавят файл към съществуващ FilesContainer . Това ще добави единичен файл (и като опция ще го презапише ако вече съществува) към FilesContainer или към локален път/ликация, или към safe:// локация. Последното ще покрие сценариите, в които някой файлове са вече качени в мрежата и искаме да създадем връзка към тях от други FilesContainers също така.
Може би разбирате, че това са първите ни стъпки в това да позволим такива операции със safe:// съдържание, очакваме в бъдеще да може да синхронизираме FilesContainer със safe:// URL адрес като първоначална локация, в допълнение към локалната папка/път.
SAFE Network приложение/програма (SNAPP)
SNAPP получи PR оправящ редица стилистични и компонентни проблеми. Също така финализираме процедурата по автоматично обновяване с някой финални тестове със създаването на CI системи в момента.
Всички тези неща добавяме и към десктоп версията на SAFE Браузъра, което ще позволи обновяването на апликации директно от самите SNAPP.
SAFE Десктоп Браузър
POC браузъра е подреден и вече е основния ни dev отдел. Това наложи поправката на множество проблеми след-electron-обновявания, както и поправки на тестовете и настройки, сега след като премахнахме вградения удостоверител.
Но вече dev отдела ни изглежда по-подреден, от когато и да е било. С новата NEON API поправка и работеща версия под Windows (предната версия вече има версия за Windows!), и нашите E2E тестове работещи под всички платформи (за момента без Windows CI). Това досега не беше възможно изобщо под Windows, заради някои забавни Windows “капризи”. Така всичко това изглежда много позитивно.
След като оправихме Windows-а, насочихме вниманието си към новата safe_nodejs библиотека, която изграждаме над CLI изложените dev API-та. Вече имаме основните API-та изложени, с NRS създаване/обновяване и files създаване/синхронизиране както и fetch, която вече беше в POC. Така разбира се, започнахме да излагаме тези API-та към DOM, който сега работи добре, след като отстранихме проблемите с пакетирането, работим и по някои хубави UI подобрения за да гарантираме лесно регистриране на Публични Имена.
Всичко това ще намерите в този PR.
Върху тази интеграция с браузъра, разглеждаме и пакетирането на safe_nodejs библиотеката за да помогнем на по-бързото изграждането на апликации (в момента изграждането от сорс кода добавя около 45 минути към CI тестовете ни, така че работим доста енергично за да свалим това време). Първоначалните тестове с node-pre-gyp също изглеждат обещаващи!
SAFE Мобилен Браузър
Опцията Pull to Refresh от PR #137 е въведена Тази опция позволява на потребителя да обнови уеб страницата, която разглежда като издърпа надолу, без да използва бутона за презареждане в менюто и за двете платформи (iOS и Android).
В момента се опитваме да пуснем автоматичните UI тестове за хранилището на мобилния браузър използвайки Xamarin.UITest инструментите. UI тестването е критичен компонент за да се установи дали някои от съществуващите опции е счупена или дали са се появили нови бъгове, заедно с въвеждането на нови опции или поправката на друг проблем.
Автоматизацията на UI тестовете гарантира, че ще се правят по-бързо и по-често, и че няма да имаме връщания назад - особенно с увеличаване на сложността на проекта заедно с увеличаващата се бройка проекти. Следващата седмица ще конфигурираме CI да пусне тестовете на множество устройства с различни API нива/OS версии и хардуерни спецификации на множество платформи, за да подсигурим единно потребителско изживяване за всички потребители.
SAFE App C#
Тази седмица отделихме време в преглед на safe-cli кода и разгледахме как да пуснем FFI свързаностите от safe-cli за да дадем възможност на API-то да използва C# със същия програмен код.
Целтани е да имаме структура, която ще се използва за предостави .NET API за функции като качване и сваляне на информация от новите трезори. Щом имаме основната структура ще разширим API-то да покрива и другите съществуващи функционалности, които включват работата с новите типове данни, ключове, XOR-URL адреси, NRS, и портфейла.
SAFE Клиентски Библиотеки
С подготвянето на предстоящата Фаза 2 на Трезорите разрешихме и множество проблеми. Един от тях е PR #1034 и се отнася до разрешенията за програми изпращащи обновления към мрежата от името на потребителя. Досега, програмите използваха transfer_coins като единствената порта за промяна на информацията, четяха койн баланса и изпращаха койни от името на потребителя. Решихме че това трябва да бъде разбито на различни нива за разрешение за всяка специфична операция. Затова добавихме няколко порти за разрешение allow_mutation и get_balance .
@marcin пусна PR за повторно включване на не-тестовите форми, които работят отново след всичките промени в SCL, в Travis, който използваме за Непрекъсната Интеграция. В допълнение, този PR оправя и връща бинарните тестове за съвместимост, които също бяха спрени, и добавя малко преструкториране, след като така и така правим промени. Последно, този PR премахва частта от кода, която стартира cargo check преди cargo clippy в нашия clippy-all скрипт, което беше необходимо заради бъг, на който се натъкнахме и съобщихме. Много добро обяснение на бъг-а, анализа му и поправката може да бъде открита тук.
BLS криптография
Завършихме с плануването на BLS стадия, заедно с задачите по Фаза 2. Този проект отново е подновен от там, където го бяхме поставили на пауза и може да добавим работата, която бяхме свършили преди за Parsec към BLS Разпределено генериране на ключове (Distributed Key Generation=DKG), заедно с разчистването към Сигурно Доставяне на Съобщения (Secure Message Delivery=SMD) проекта, за да започнем с генерирането на истински ключове на BLS Секция и да ги използваме в рутинга.
Започнахме и първоначалните промени по превключването на BLS от кворум към 1/3 съгласие, което ще направи емулирания BLS по съвместим с истинския BLS.
Сигурно Доставяне на Съобщения (Secure Message Delivery)
Приключихме с последната задължителна задача от SMD плана Добавихме още тестове за да гарантираме, че съобщенията са правилно защитени и неправилни съобщения се засичат и отказват. Има няколко допълнителни задачи останали за SMD, които са на пауза за сега и ще се решат, когато времето позволи.
За да завършим въвеждането на SMD така че да отговаря на RFC-ра, ще трябва да изчакаме докато BLS проекта е завършен. На този етап ще можем да направим финалния QA и да го обявим за завършен. До тогава ще държим този проект отворен само с една задача за завършване.
Полезни линкове
- Официален сайт на SAFE Network
- Обобщено представяне на SAFE Network
- SAFE Network Фундаменти
- Карта на проекта
Подробна информация може да намерите както винаги във форума на международната общност: SAFE Network Forum
Ако имате въпроси може да ги зададете във Facebook групата на българската SAFE общност: SAFEnetwork България | Facebook
Ако искате да следите последните новини заповядайте във Facebook страницата на SAFE Network България: Safe Network България