SAFE Network новини – 19.12.2019
Накратко
Ето някои от основните неща тази седмица:
- Пуснахме нов предварителен преглед на NuGet пакет за MaidSafe.SafeApp
- Направихме нова бета версия на SAFE браузъра.
- Приспособихме се към BLS-базиран подход за пренасяне на маркери за Етикетите на данните RFC.
- Обмисляме да променим начина, по който аргументите на източника и местоназначението се третират от командите
files put/files sync. Моля, присъединете се към нас в дискусиите по този въпрос в GitHub или в тази тема във форума.
Честито ново деситилетие!
С наближаването на края на 2019 г., ние от MaidSafe искаме да пожелаем на всички щастливи празници през следващите седмици. Това беше година на промяна за нас, още от началото й и през всички шокове на криптовалутите, като стигнем разбира се и до шоковете в собственият ни екип, когато някои хора напускаха изведнъж. Кулминацията на промените обаче ни остави вероятно там, където трябваше да сме още преди няколко години. Ние сме предимно инженери, работещи за пускането на потенциално променяща света мрежа.
Връщането към един екип и дори повече от това, фокусиран, всеотдаен екип има много, много хубави ползи. Ние сме по-фокусирани върху цялата мрежа, можем да говорим по-равно и открито и най-вече можем да се забавляваме малко повече на събиранията ни. По-малко бюрокрация и липсата на “политически” игри означава, че можем просто да се съсредоточим 100% върху това, което е важно, SAFE мрежата. Като цел, това е доста голямо усилие и само това е единствената ни цел сега. Не как да я промотираме на пазара, не как да управляваме отдели или да провеждаме междуведомствени срещи и така нататък, а как да дадем на света SAFE мрежата.
Усещаме завърнала се енергия и екипът наистина полага усилия, за да се самоуправлява и това работи чудесно. Новата година ще бъде вълнуваща за нашия екип и се надяваме, че вълнението и увеличеният ни фокус ще продължават да се разпространяват и в общността.
Това са последните седмични новини за десетилетието и няма да имаме други до 9 януари. И така,пожелаваме ви отново чудесно ново десетилетие и не можем да ви благодарим достатъчно за подкрепата ви, тя ни дава цялата енергия, която така ценим.
Трезори – Фаза 2
С внедряването на новия протокол за свързване в Трезорите от днес приключихме с повечето задачи от едно-секционни Трезори и се радваме да стартираме тест за интегриране на множество Трезори с клиенти. Щастливи сме да видим някои първоначално обещаващи резултати, като 3/4 от клиентски тестове преминават успешно в локална среда за разработка. Продължаваме с проучването на неуспешните тестове и целта ни е скоро да започнем вътрешни тестове в по-голям мащаб.
Актуализацията на тестовете за интеграция на Трезорите с помощта на реална маршрутизация и трезорна мрежа също е добавена днес. С тази актуализация, качеството на кода вече може да бъде осигурено допълнително чрез тестова рамка с по-голямо покритие.
В същото време @lionel.faber и @yogesh документираха предварителните проекти за Фаза 2Б (проектът с множеството секции), като започнаха с писането на документацията за съществуващите потоци от заявки. С това трябва да подобрим нашето разбиране за обхвата на работата, необходима да се извърши при Трезорите, за да поддържаме мрежовата комуникация между множество секции.
Също така започнахме да проучваме надстройката на quic-p2p до най-новата версия на Quinn, основна библиотека на QUIC протоколa, която използваме за нашия мрежов слой. Това надграждане трябва да подобри стабилността, съответствието с най-новите тестови версии на QUIC протокол стандарта и по-важното е, че ще внесе код за асинхронизация / изчакване в quic-p2p. Асинхронизация / изчакване е нова синтактична функция, която наскоро беше стабилизирана в Rust 1.39. Тя ни позволява да пишем бърз и ефикасен код по рационализиран начин. Въпреки че все още не правим пълен преход към новия стил на асинхронизация / изчакване, видяхме някои значителни подобрения в яснотата на кода в quic-p2p. Тази промяна трябва да доведе до намаляване на когнитивната сложност, което ще улесни допринасянето ви с код в нашите проекти. В крайна сметка тази промяна в quic-p2p също ще ни позволи да започнем да разпространяваме този кодов стил и в SAFE Клиентските библиотеки и така нататък.
SAFE API
През миналата седмица обединихме няколко PR-а, за да подобрим и опростим нашия CI процес за safe-api хранилището. След преминаването ни към GitHub Actions, и пълното премахване на Jenkins и Travis, трябваше да финализираме и изчистим някои от CI скриптовете. Най-важният аспект на тези задачи беше свързан с гарантирането, че все още можем да генерираме safe-ffi библиотеки с обединяването на всеки PR, тъй като активно се използват от нас за разработване на езиковите връзки и мобилни приложения.
В API-то на connect_app в safe-api бе добавена малка функция, за да може приложенията да се свързват с мрежата като нерегистрирани приложение, т.е. да се свързват с разрешения само за четене, ако удостоверителят не им е дал идентификационни данни за регистрирана връзка. Това е често срещан сценарий при мобилните ни приложения сега, когато приложенията винаги изискват подробности за връзката към удостоверителя, както за регистрирани, така и за нерегистрирани връзки към мрежата. Докато, десктоп програмите ни не се нуждаят от това, тъй като понастоящем получават информация за връзката на трезора от локален път, но в бъдеще някои десктоп програми могат да започнат да използват удостоверителя за връзки само с права за четене.
Успяхме да финализираме реализацията за генериране на XOR-URL адреси за файлове, без да ги качваме в мрежата, както за реализацията в safe_client_libs , така и в тази, която да изложи такава функция от safe-api и safe-cli . Към CLI ще добавим и нова команда $ safe xorurl , като просто ни остава да пишем няколко допълнителни теста и да актуализираме Ръководството за CLI, преди да обединим съответните PR-и, които ще позволят тази функция.
Що се отнася до следващите стъпки в safe-api хранилището в следващите дни, всичко което правим ще е свързано с възможността да направим safe-authd обновяващ се от CLI-то, тъй като знаете, че с $ safe update можем да обновим safe-cli до последната версия, така че ще работим върху създаването на команда, която да ни позволи също така да обновим safe-authd по аналогичен начин.
В следващите няколко седмици може също да се опитаме да променим начина, по който аргументите на източника и местоназначението се третират от командите за files put / files sync , тъй като от известно време насам има много отзиви и коментари за това, така че вероятно е добър момент да се справим и с тази задача. Така че моля, присъединете се към дискусиите ни, ако още не сте го направили, за да ни помогнете да намерим най-добрия подход, или в този страница в GitHub, или в тази тема във форума.
Етикети за данните, индексиране и оторизиране на маркери
Миналата седмица говорихме за подготвяния RFC за етикетите на данните и се насочваме към BLS-базиран подход за маркиране на носител, вдъхновен от макаруни, макар че излезем малко от пътя поради ограниченията в начина, по който макаруните се проверяват (което не е подходящо при нашите децентрализираните стъпки за проверка).
Същността на идеята е, че ви се предоставя подписан жетон, който може да съдържа различни ограничения за използването му (за определени етикети, през определено време, само за тези URL адреси … това ни дава голяма гъвкавост) и може да бъде валидиран както в ClientHandlers срещу заявката, която програмата прави, така и при обработващите данни, срещу разрешенията на самите данни (включително етикетите).
Работейки с BLS по този начин, ние все още можем да активираме споделени данни и се опитваме да разширим подхода, базиран на маркери, за да можем сами да предаваме маркери за споделяне на данни (и така да ни даде възможност да кажем например: „можете да получите достъп до тези данни, но само за следващите 2 дни“).
За тези, които се интересуват от техническите характеристики на това, моля, преминете към RFC, прочетете, коментирайте и задайте въпроси! Всичко помага 
!
SAFE Клиентски библиотеки
Миналата седмица пуснахме нови версии на всички SCL контейнери. С приключването на това, започнахме да работим по някои последни задачи за почистване, преди да се върнем назад, за да помогнем с Трезорите. Също така ще продължим да поддържаме всички промени, необходими за интерфейса на приложенията, като корекции на грешки и нови функции. @marcin работи върху нова вълнуваща функционалност в SAFE програмата, като добавя поддръжка за константата GET_NEXT_VERSION на повече места. Подробности можете да намерите в съответната задача и в PR-а, който подготвяме.
От страна на инфраструктурата, изгладихме грешките в публикуването на автоматизираните ни версии и внедрявания, които наскоро добавихме към GitHub Actions, за да ускорим процеса на пускане. Освен това добавихме кеширане към GHA, което в някои случаи води до 50% намаление на времето за изграждане. Също така сме в последните етапи за пълно премахване на Docker от SAFE CLI. Следващите ни цели в GHA са да намалим многословието (вероятно чрез прилагането на собствената ни библиотека с персонализирани действия) и след това да разгърнем промените във всички наши хранилища, замествайки Travis и Appveyor навсякъде.
SAFE Network програма (мобилни устройства)
Тази седмица покрихме още малко от основата на стилистичния и тематичния фронт и подобрихме потребителския интерфейс за двете платформи (Android и iOS). Съсредоточихме се върху привеждане на повече стилове от дизайна към програмата и потребителският интерфейс се оформя прекрасно. Можете бързо да погледнете тези два PR-а (#29, #28) за да добиете представа.
Миналата седмица добавихме малко подобрение, което да подобрява дали мобилният браузър е инсталиран или не. Тази седмица надградихме тази логика и сега съхраняваме резултата в настройките на приложението. Използвайки това, можем да зададем свързани с браузъра условни навигационни бутони навсякъде в приложението. Например, ако браузърът е инсталиран, можете да го отворите от приложението SAFE Network, в противен случай можете да отворите страницата за изтегляне.
SAFE браузър (десктоп)
През изминалата седмица към браузъра беше добавено коригиране, което актуализира поток за удостоверяване в SAFE Network програмата, което пречеше на самия браузър да се удостоверява в мрежата (което пък водеше до неуспех при опит за създаване на нови сайтове чрез браузъра).
Също така включихме и редица актуализации на зависимости, някои от които се превърнаха в нова бета версия, която можете да изтеглите сега от тук.
Започнахме и ъпгрейда до Electron 7, който включваше актуализиране на нашата TestCafe версия (и еднократно PR до тяхното хранилище, така че да сме в крак с последните им промени). За съжаление попаднахме на греда в Electron, където бъг грешно хвърля грешка при получаване на отговори с код различен от 200 (което означава, че нашите полезни страници за грешки никога не се показват). Изглежда, че има решение за това, което вече се подготвя, просто не е добавено в новото издание на Electron 7.x, така че веднага щом го имаме, можем да обновим браузъра до най-новата версия.
SAFE браузър (мобилни устройства)
През последните няколко седмици се сблъскваме със сривове при iOS устройства, докато версията за Android работеше отлично. Този проблем със забиването на приложението беше решен тази седмица чрез актуализиране до най-новия пакет за преглед. Актуализирахме приложението, за да използваме някои нови API-та и съответно променихме кода. С разрешаването и на проблема за срив при отстраняване на грешки в приложението (повече подробности в секцията SAFE App C # по-долу), вече можем да продължим и да напреднем със задачите за предоставяне на първоначалните функции на pWeb и при мобилните устройства.
SAFE App C#
Днес пуснахме нов предварителен преглед на NuGet пакета за MaidSafe.SafeApp . Този пакет включва множество корекции, нови API-та и някои преструктуриращи промени.
В новия пакет поправихме проблем, свързан с основните библиотеки на iOS, който причиняваше срив на приложението при използването на iPhone симулатори и физически устройства. Поради този проблем не успявахме да отстраним грешки при нито едно от нашите приложения за iOS. От страна на преструктурирането премахнахме всички остарели API-та на SAFE Клиентските библиотеки от пакета, както и премахнахме някои неизползвани зависимости.
Също така добавихме и тествахме ново AuthAppAsync API за да подобрим процеса на разработка. Програмистите могат да използват това API в своите C# десктоп приложения и потребителите ще могат да удостоверяват приложенията с safe-cli и процеса на удостоверяването. В следващите седмици ще подобрим това API, за да предоставим същата функция и за мобилни устройства.
Стареене на възел (Node Ageing)
Тази седмица приключихме с големия PR, над който работихме от известно време. С добавянето на първоначалната работа по повишаване / понижаване, вече имаме основните компоненти на Стареенето на възлите: Фиксиран брой на Старейшините в секцията и останалите възли като Възрастни.
Възлите вече могат да бъдат повишавани и понижавани между възрастни и старейшини според нуждите когато бъдат премествани, при отпадането на възел, присъединяването на нов възел или разделянето на секция. Тази работа беше от съществено значение по редица причини. За надеждно / сигурно доставяне на съобщения сега използваме постоянен брой допълнителни съобщения. За Parsec представянето е постоянно. И накрая, това е ключът към нашата устойчивост на Сибил атаки, тъй като само възли, които са извършили най-много работа, могат да участват във вземането на решения.
Значителен брой промени трябваше да бъдат добавени, за да се подкрепи тази работа във времето. Допълнително надграждахме върху тази основна промяна, за да завършим останалите елементи, за да финализираме повишенията и пониженията.
Полезни линкове
- Официален сайт на SAFE Network
- Обобщено представяне на SAFE Network
- SAFE Network Фундаменти
- Карта на проекта
Подробна информация може да намерите както винаги във форума на международната общност: SAFE Network Forum
Ако имате въпроси може да ги зададете във Facebook групата на българската SAFE общност: Redirecting...
Ако искате да следите последните новини заповядайте във Facebook страницата на SAFE Network България: Safe Network България