SafeNetwork открий новия интернет

SAFE Network новини – 15.8.2019

Накратко

Ето някои от основните неща тази седмица:

  • Екипът ще присъства на Web3 Summit следващата седмица в Берлин :de:
  • Автоматизирахме процесът за издаване на нови версии за safe-cli, safe-authenticator-cli и safe_vault така че когато публикуваме промяна PR, ще се публикува нова версия не само на страницата ни в GitHub, но за safe_vault ще се публикува и в crates.io :tada:
  • SAFE Network програмата се движи с добра скорост, в процес сме на интегриране на функционалности за инсталация/сваляне и първоначалния процес за включване
  • Проблемът, който спираше връзката между SAFE Клиентските Библиотеки и Трезорите е отстранен :muscle:
  • QA екипа прехвърли трезорите към разработка с musl libc вместо с glibc
  • Вече имаме първата част от крайното решение за SMD
  • И бързо обобщение до къде сме в плана на проекта

Маркетинг

Работихме усилено цяла седмица и много скоро ще имаме някои доста, доста вълнуващи новини… Първата версия, която наричаме Фаза I (прочетете по-долу) е близо до завършване – може да видите GitHub страницата и ще забележите много отметки в колоната за завършване! И работата по Фаза II вече започна. Точно така, действаме с пълна сила. Може да видите работата ни в повече подробности описани по долу, но накратко работата от целия екип е невероятна. Сигурен съм, че ще се съгласите. Всяка фаза е огромна стъпка напред към Флеминг (Алфа 3) и работим под пълна пара за да е възможно най-скоро на ваше разположение. На заден план, маркетинговия ни екип разработва плановете ни как най-добре да споделим това с вас.

Подготвяме се и за Web3 Summit. Нашият представител  @dugcampbell ще бъде на сцената и ще говори за децентрализираното съхранение на информация (20.08 / 17:30 – не закъснявайте!) @joshuef и @cgray също ще присъстват, с идеята да се включат в дебата за децентрализираното бъдеще. Надяваме се и тези година да сме толкова вдъхновяващи като миналата, ако желаете да си припомните представянето на @dugcampbell от миналогодишното събитие. Ако ще бъдете там или близо до Берлин ела те да си кажем здрасти.

Също така има ли все още хора, който не са се записали за събирането в Брайтън? @JimCollinson, нашият UX/UI специалист ще присъства там лично. Подробности тук.

ФАЗА 1

Както може да видите от последен проект на диаграма на Гант, разделихме работата необходима за достигане до Алфа 3 на фази: 4 фази за трезорите + стареенето на възлите (node ageing). Всяка от тези фази е разделяна допълнително вътрешно, за да ни даде повече яснота и обхват, но погледа от високо ни дава правилната насока.

Завършването на Фаза 1 е кулминацията на някои от “изграждащите блокове” на мрежата. Финалната версия на мрежата ще бъде изградена от три “изграждащи блокове”: клиентите, трезорите и рутинга. Фаза 1 включва основите за клиентите и трезорите. Тази версия ще бъде един трезор, който ще симулира цялата мрежа на един компютър, и ще имате новите типове данни и SAFE CLI, които да тествате.

SAFE CLI

План на проекта

С завършването на процеса по обновяване и публикуване на safe-cli чрез Jenkins, и първото ни успешно използване на self_update, тази седмица DevOps/QA екипът насочи вниманието си към safe-authenticator-cli и  мигрирането на процеса му по обновяване и публикуване също към Jenkins. Safe-authenticator-cli и safe-cli са близко свързани, затова е важно тези двете да се конфигурират постоянно и да могат да се обновяват заедно, когато има нужда. Разгледахме възможността да обновяваме safe-cli и safe-authenticator-cli с musl libc, но открихме, че има зависимости, които усложняват това за сега – и ще го оставим за по натам. За повече относно musl libc, вижте по долу в частта с Трезорите.

DevOps/QA екипът също така разгледа и въведе създаването на ежедневни версии на safe-authenticator-cli, така че да може да се използва от safe-cli CI, премахвайки необходимостта да се изгражда всеки път от нулата, когато се стартира CI-то. Това се постига чрез Jenkins и ще намали значително времето от настоящата работа на CI. Колкото по-бързо работи CI, по-бързо ще получаваме обратна връзка за версията и по-бързо ще я обновяваме :rocket:

Следващата стъпка е да добавимself_update към safe-authenticator-cli. Тази команда self_updateпозволява най-новата версия да бъде свалена от GitHub страницата ни, ако има нова версия, когато потребителя използваupdate командата от CLI-то. Това спестява нуждата ръчно да се сваля и инсталира последната версия на CLI Удостоверителя, вместо това с въвеждането на проста команда в терминала ви, програмата ще се обновява сама.

Добавихме и дребна функция към safe_cli, която ще е много полезна за проверка на настоящето състояние на NRS Картата на контейнера. Когато използватеcat командата, вече е възможно да добавите флаг  --info за да получите списък със всички поддомейни, създадени към дадено публично име и тяхната метаинформация, например свързаното съдържание. Обновихме секцията с “SAFE URL адреси” в Потребителското Ръководство с обяснение как това може да се използва, и примери на видовете информация, които може да се извличат с този флаг.

Миналата седмица започнахме работата по промените необходими в safe_cli и safe_auth_cli за да се обновят SCL библиотеките до последните версии и се надяваме да сме готови скоро. Това ще ни позволи да използваме CLI-тата не само с тестовата локална мрежа, но и с Трезорите в настоящите версии на мрежата.

Постигнахме и добър прогрес в опитите ни да свържем Node.js с новите Rust API-та (високите нива API-та, които разработваме в safe_cli). Това ще ни позволи да имаме Node.js програми, които да ги използват, както и SAFE браузъра и в последствие ще могат да се използват и от уеб програми. Този път тестваме neon-bindings, защото изглежда лесно за поддръжка, вместо досегашния node-ffi. Щом приключим с това ще може да разширим използването на Rust API-тата до много повече приложения и ще поддържаме всички нови видове данни.

SAFE Network приложение/програма (app)

План на проекта

SAFE Network програмата продължава да се разраства. Добавихме повече от реалната външност на приложението (досега имахме функционална, но груба версия за разработчици). Вижте PR тук, има нужда от някои подобрения, но изглежда много добре. Вече имаме началото на въвеждащия процес и макар да е прост като за начало, в бъдеще ще създаде основите за първото взаимодействие на хората с мрежата, включително създаването на акаунт и влизането в мрежата. Интегрирахме и функционалности за инсталиране/сваляне в потребителския интерфейс, така че вече имаме визуална връзка за прогреса и обновяването лесно може да се постави на пауза/откаже. Ако всичко продължава да върви така добре се надяваме следващата седмица да представим публична тестова версия.

SAFE Мобилен Браузър

План на проекта

Тази седмица работихме по някои нови функции за мобилния браузър. Една от тях ще позволи на потребителя да споделя лог файловете си. Това ще ни помогне да откриваме и отстраняваме проблеми по-бързо. Също така почти завършихме тъмния режим за двете платформи (Android и iOS). Сега се фокусираме върху някои дребни проблеми, преди да изпратим приложението към QA екипа за финални тестове.

SAFE Клиентски Библиотеки

План на проекта

SAFE Програмата е прехвърлена да използва новите типове данни. Съществуващото API използващо старата MutableData е прехвърлено към новите последователни MutableData (все още не поддържаме непоследователните MD). Това ни приближава към пълното премахване на старото API и типове данни от кода изцяло. PR за това е в процес на преглед в момента.

Публикувахме няколко версии на safe-nd. Документацията за това е значително подобрена и вече е лесно достъпна тук. Също така стабилизирахме и замразихме API-то, което значи, че няма да има повече промени преди да преминем към Фаза 2 на Трезорите, но може да добавим нови функционалности ако го намерим за достатъчно полезно. Пуснахме версия 0.2.0 и смятаме бъдещите версии да са обратно съвместими с нея, като версия 0.2.1 ще добави нови публични функционалности. Така бъдещите версии ще добавят малки промени, което ще ни позволи значително да опростим част от AppendOnlyData тестовия код. Но при всички случаи смятаме да променяме минимално този код.

Справихме се и с проблем, който пречеше на свързването между  SAFE Клиентските Библиотеки и Трезорите. Клиента на трезора създава карта с адресите към клиентските идентичности (публичните ключове). Понякога, когато стара връзка със същия публичен ключ все още съществува, Трезора взима грешен адрес, към който да изпрати отговор и “истинският” клиент никога не получава отговора.

След известни усилия от наша страна (заслугата е на  @fraser@ustulation и @nbaksalyar) проблемът е отстранен и сме в процес на тестове преди интегриране, което ни помогна да открием малък бъг в quic-p2p: за ефективност не сериализираме бинарните съобщения над 1 килобайт и при получаващата страна винаги предполагаме, че не се налага да разсериализираме големите съобщения. Но понякога, бинарния сериализиращ формат добавя няколко допълнителни байта сам, така че quic-p2p грешно предполага, че е не-сериализирано съобщение, което води до отказ. Оправихме и този проблем и скоро ще пуснем нова quic-p2p версия с поправките. С всичко това вече пълните тестове на Клиентските Библиотеки с локалния Трезор изглеждат доста обещаващи!

Трезори

Тестовете по интегрирането на локалния Трезор със SAFE Клиентските Библиотеки показаха известно несъответствие между баланса на Safecoin и логиката по създаването му. Тестовия Трезор позволи да използваме тест функция за създаване, на който и да е акаунт с всякакъв ключ и баланс, докато локалния Трезор позволява (грешно) всички заявки да преминават дори и клиента да няма никакви пари. И въпреки, че двата подхода имат логика в тестова среда, решихме да се придържаме по-близо до реалната мрежа. В момента може да създаваме какъвто и да е баланс Safecoin от въздуха, но само ако правите това за себе си (т.е. за клиентския ключ, който използвате за връзка с Трезора). За да е още по магично няма лимит на Safecoin-ните, които може да създадете за себе си, така че бъдете готови да тествате тази функционалност и да се забавлявате!

Миналата седмица DevOps/QA екипът завърши работата по мигрирането на основното от safe CI Трезора към Jenkins. Заедно с това те автоматизираха процеса по обновяване, така че сега, когато направим нови промени PR ще се задейства не само обновяване на GitHub страницата ни, но ще се публикува и в crates.io :tada: Досега това се правеше ръчно, така че автоматизирането на процеса ни позволява да освободим повече ресурс за други неща и намалява възможността за човешка грешка.

DevOps/QA екипът също така прехвърли трезорите да се създават чрез musl libc  вместо с glibc. Това значи, че програмния код на трезорите ще работи на много повече Linux дистрибуции, отколкото досега, така че по-малко работа по поддръжката им :smile:

Но не се задоволихме само с това, добавихме иself_update към най-новия код на трезора. Това позволява на self_update да свали нова версия от GitHub страницата ни, ако има такава, всеки път когато трезора се стартира. Това е целенасочено различно поведение от нуждата на ръчна команда update необходима за обновяване на safe-cli и safe-authenticator-cli. Това ни спестява нуждата да приканваме общността да сваля и инсталира последната версия трезори, така ще е необходимо само да ви приканим да рестартирате трезора си и той ще се самообнови. Предполагам ще се съгласите доста елегантно решение за тестова фаза :wink:

Сигурно Доставяне на Съобщения (Secure Message Delivery)

План на проекта

Вече имаме първата част от крайното решение: Съобщенията в секцията вече се подписват и верифицират при получаване. Всички тестове минават и сме сигурни в работата на Сигурното Доставяне на Съобщения.

Надграждаме над това първоначално решение и успешно решихме проблем, който ни създаваше трудности в предишните схеми: вече може да изчистим доказателството за изпращане и да потвърдим, че съобщенията се валидират. И за финал разчистваме кода от старите схеми.

Със завършването на тези 2 големи задачи, оставащата работа е ясна и я добавихме към плана на проекта. Напредваме и в завършването на тези последни задачи. Една от най-големите оставащи задачи е да разрешим проблем, който се откри наскоро при интегрирането на Parsec. Идентифицирахме точното място на проблема и работим по отстраняването му.

Подробна информация може да намерите както винаги във форума на международната общност: SAFE Network Forum

Ако имате въпроси може да ги зададете във Facebook групата на българската SAFE общност: https://www.facebook.com/groups/SafeNetworkBulgaria/

Ако искате да следите последните новини заповядайте във Facebook страницата на SAFE Network България: https://www.facebook.com/SafeNetworkBulgaria/