SAFE Network новини – 26.9.2019
Накратко
Ето някои от основните неща тази седмица:
- Пуснахме нова версия на SAFE Браузъра, добавяща някои много добри функции на вУеб (Вечната мрежа).
- Като част от работата по Фаза 2 на Трезорите започнахме да правим необходимите промени, за да сме сигурни, че Трезорите виждат по един и същи начин състоянието на информацията за всички мрежови операции.
- В SAFE CLI хранилището беше извършена много работа за да подготвим първите FFI (Интерфейс на Чуждите Функции / Foreign Function Interface) функции за SAFE API-тата. PR-а който включва настройките за генерирането на основните библиотеки, C# свързаностите и покриващ повечето от API-та беше прегледан и обединен.
- Работата по въвеждането на Стареенето на възлите (Node Ageing) започна.
Маркетинг
Това са последните новини за Септември 
- колко вълнуващо! И както обикновенно имаме множество новини за вас и тази седмица. Като начало за маркетинга ви изпратихме двуседмичния ни новинарски имейл, който трябва да сте получили днес след обяд (UK време). Обсъдихме раждането на безКешовите общества, какво води до тях и къде крипто валутите намират своето място във всичко това. Ще го публикуваме и в Medium скоро, за да не го изпуснете - но защо да не се запишете за новинарския ни имейл и да получавате историите директно в пощата си?!
Пуснахме и насочена върху наблюдението туитър буря, така че хвърлете едно око в Twitter. Ако сме изпуснали някоя важна новина може да ни пишете във форума или да ни тагнете в Twitter.
Трезори - Фаза 2
Продължаваме да напредваме през задачите на Фаза 2, основно сме фокусирани на два фронта: тестовия Рутинг и рестартирането на операциите на Трезора, по отношение на постигането на консенсус.
Спряхме се върху тестовия Рутинг в новините от миналата седмица, но това е само част от историята. Във Фаза 1 на Трезорите повечето заявки за товарене са въведени наивно: защото нямаме нужда от консенсус в контекста на единичен Трезор, потокът от операции използва някои кратки пътища, които няма да работят с множество Трезори. Сега правим необходимите промени за да сме сигурни, че Трезорите имат едно и също виждане за състоянието на информацията на всички поддържани операции в мрежата. Това е добре известна задача и сме завършили етапа на проектиране. Подхода, който избрахме налага някои малки промени в Рутинг API-то и в кода на Трезора. Промените започват да се появяват с PR#852, който поставя началната структура за работа с консенсуса и PR#854 където изтриването, трансфера на койни и заявки на пакет за вход (LoginPacket) се насочват през консенсус алгоритъма.
С завършването на PR#1034 , AppPermissions са готови за оптимизация и преработка (обяснено е тук в SCL секцията) в тестовия трезор вътре в SAFE Клиентските Библиотеки. Съответните промени са на път и за истинските трезори, за да ги подготвим за новия начин за работа с разрешенията на програмите.
В рамките на Рутинг щайгата, имаме обединени PR-и за справяне с PARSEC кривата, когато трябва да се извърши изчистване (pruning). Бъдещета работа за справяне с подробното изчистване (pruning) на работата също напредва добре.
И докато сме тук си струва да отбележим, че споделения Трезор (като част от Фаза 1 на Трезорите) беше рестартиран по рано тази седмица и vault_connection_info.config файла беше обновен в GitHub страницата на трезора. Вижте последната версия на Трезора за новия vault_connection_info.config файл - ако смятате да използвате споделения трезор, трябва да го свалите в съответната локация на платформата ви 
SAFE CLI
Както знаете създадохме първия комплект от SAFE API свързаности за NodeJS. Това значи, че уеб програмите (apps) и самият SAFE Браузър могат да използват едни и същи API-та, каквито се използват от SAFE CLI. Но последните няколко седмици (и особенно последните няколко дни) много работа беше извършена за да подготвим първия комплект FFI (Интерфейс за чужди функции / Foreign Function Interface) функции за SAFE API-тата. Това ни позволява да започнем работа по създаването на SAFE API свързаности за C# езика (и в последствие за Java и други езици). Това значи, че API-тата ще бъдат използваеми и от мобилния браузър.
Създадохме и някои автоматични тестове за NodeJS свързаностите (с Jest), което гарантира, че информацията е съхранена и извлечена правилно, когато се използва кое и да е от SAFE API-тата. След като всичката функционалност и логика на API-тата се намира в Rust нивото и множество сценарии се тестват на това ниво, тестовете на NodeJS свързаностите, както и която и да е друга свързаност, стават по прости. Те просто гарантират, че информацията е правилно изпратена и получена през слоя на свързване.
В момента обмисляме рефакторинг и преструкториране в хранилището, след като вече имаме три щайги за управление: 1) safe-api излагащо Rust SAFE API-то, 2) safe-cli съдържащ SAFE CLI сорс кода на програмата и зависимостта от safe-api , и 3) safe-api-ffi който е слоя съдържаш всички FFI функции напълно изолирани/отделени от останалите, и очевидно зависими от safe-api . Така че ще продължим да работим върху това за да финализираме някои реорганизации, които вече са готови.
И накрая, паралелно продължаваме да опитваме да оправим някои малки проблеми и да добавим нова функция, която ще позволи да се избере специфичен баланс за харчене от портфейл ( Wallet ) за всяка от поддеържаните операции. За момента всички команди на портфейла използват баланса за харчене по подразбиране като източника/целта за всяко действие извършено с Wallet . Сега се опитваме да позволим на потребителите да зададът лесно име на баланса за харчене в URL адрес, така че командата да може да работи с него вместо с баланса за харчене по подразбиране. Т.е. ако имате баланс за харчене с име за-плащане-на-бири в портфейл с URL адрес safe://mywallet ще може да проверите баланса по него с командата:
$ safe wallet balance safe://mywallet/to-pay-beers
SAFE Десктоп Браузър
Днес публикувахме нова версия на SAFE Браузъра! Представяме някои много добри функции на вУеб (Вечната мрежа), позволяващи на потребителите не само да преглеждат SAFE сайтове и техните стари версии, но също така да регистрират NRS имена (Система за разрешаване на имена / Name Resolution System) директно от браузъра. Потребителите вече могат и да качват и променят сайтовете си (директно от браузъра).
В настоящия момент не сме положили много усилия върху UI/стилът на тези функции. Просто ги направихме публични с базова функционалност за да може да опитате бъдещето на Интернет тук и сега!
Може да го свалите от GitHub страницата ни тук и да си поиграете с тези хубави функции. Напомняме, че ще имате нужда от safe_auth CLI работещо и свързано или към споделен Трезор или към локален Трезор, който сте стартирали.
Просто за да ви дадем идея за нещата, които ще може да правите в тази нова версия, ето някои най-общи описания:
- Изтегля уебсайтове използвайки NRS-URL адреси и XOR-URL адреси, разглежда напред и назад тяхната история, виждайки всеки уеб сайт във всяка от версиите му.
- Ако се опитате да отворите сайт чрез NRS име, което все още не е регистрирано ще получите възможност да създадете и регистрирате това NRS име със своя акаунт! За тези от вас, които знаят как работи настоящето DNS регистриране това ще е интересно преживяване
- Ако посетите сайт, който вече притежавате ще може да го редактирате директно в Браузъра, като изберете локална папка (само папка може да бъде избрана в тази версия) от където ще може да качите новите файлове за сайта си. Браузърът ще качи и публикува информацията ви с вашето NRS име и URL адрес.
- Уеб сайтовете алтернативно могат да бъдат качвани и публикувани под NRS име чрез SAFE CLI. Веднъж след като са публикувани могат да се изтеглят или чрез CLI или да се отварят с SAFE Browser (въпреки че не е възможно все още да се променя сайт чрез браузъра ако е качен с CLI, нито обратното, ограничение върху, което ще работим скоро във връзка с поддръжката на споделени права между различните програми).
Ако създадете сайт на споделения Трезор защо не споделите NRS или XOR URL адреса във форума за да го видят и други!
Напомняме, че тази версия на браузъра не е съвместима с Алфа 2 тест мрежата, а работи само с новия споделен или локален Трезор както е обяснено в тази тема.
SAFE Мобилен Браузър
Тази седмица приключихме с автоматичната настройка за UI тестване на SAFE мобилния браузър. За да валидираме тестовата настройка добавихме някои UI тестове за сценарии за тестване на долните бутони за навигация, промяна на темата на приложението, отваряне на FAQ страницата и т.н. Тези тестове показаха че автоматичното UI тестване е възможно и е лесно за въвеждане. Въпреки това, работата по мобилния браузър е поставена на пауза за сега заради продължаващата разработка на safe_app_csharp , който е основния ни фокус в момента.
SAFE App C#
Тази седмица продължихме с добавянето на свързаности за новите API-та и покрихме множество възможни употреби. This week we continued to expose more bindings for the new APIs and covered lots of use cases. PR-а който включва настройките за генериране на основните библиотеки, C# свързаностите и покриващ повечето от API-та беше прегледан и обединен. Все още ни остава да преструкторираме и подобрим кода за да е готов за публично използване.
Веднъж след като приключим, свързаностите ще ни позволят да предоставим прост и изчистен API за C# и множество други езици.
Паралелно добавихме нови задачи в GitHub хранилището ни за всички останали API-та, върху които ще работим нататък. Това ще помогне на екипа да следи прогреса на работата. Също така започнахме работа върху свързаностите за C# API-то за мобилни и десктоп устройства.
Стареене на възел (Node Ageing)
Както някои от вас забелязаха започнахме да работим върху въвеждането на Стараенето на възела (Node Ageing) 
Решихме стартираме с малък и фокусиран екип за момента (Представете си Делта Форс, само че по-яки ). Тази работа включва въвеждането на персоните на Възрастните (Adult) и Малчуганите (Infant), както и затвърждаването на статуса на Старейшините (Elder). Това намалява процеса по въвеждане и присъединяване до много по прост механизъм и ни позволява да премахнем кандидатурата и доказателството за ресурс.
Добавихме първоначалните задачи към плана на проекта и ще ги разширим в последствие щом напреднем във фазата на въвеждането им.
Стареенето на възела ни позволява да реализираме значимостта на устойчивостта на Сибил атаки и да се възползваме от тази придобивка, особенно сега когато имаме PARSEC в играта. Междувременно работим и по BLS и това ще помогне неимоверно.
Накратко това е голям напредък от екипа и те показват големи умения и отдаденост да се справят с агресивните срокове и натовареност на работата.
BLS криптография
След като пренасочихме част от екипа да работи върху стараенето на възлите, BLS ще се забави леко, но въвеждането на DKG (Генериране на Разпределен Ключ / Distributed Key Generation) продължава да напредва и обединихме работата с използването на PARSEC за събирането на споделени подписи за Секциите (SectionInfo).
След като завършим работата по зареждането/присъединяването към стареенето на връзките, BLS ще може да продължи с пълна скорост напред.
Полезни линкове
- Официален сайт на SAFE Network
- Обобщено представяне на SAFE Network
- SAFE Network Фундаменти
- Карта на проекта
Подробна информация може да намерите както винаги във форума на международната общност: SAFE Network Forum
Ако имате въпроси може да ги зададете във Facebook групата на българската SAFE общност: SAFEnetwork България | Facebook
Ако искате да следите последните новини заповядайте във Facebook страницата на SAFE Network България: Safe Network България