SAFE Network новини – 6.2.2020
Накратко
Ето някои от основните неща тази седмица:
- Пуснахме първия стабилен MaidSafe.SafeApp NuGet пакет, създаден с помощта на safe-api библиотеката
- Пуснахме нова алфа версия на SAFE браузъра.
- Направихме някои значителни опростявания и корекции на кода както в библиотеките за маршрутизация, така и в quic-p2p библиотеките.
- Тестването на Трезорите Фаза 2 продължава, като скоро ще има тестова мрежа.
Информационни табла за проекта
Тази седмица решихме да премахнем 3-те публични табла на проекта, които имахме в GitHub, но които не бяхме обновявали от няколко месеца (благодарим на @Cryptoskeptic и @Antifragile, че ни обърнаха внимание за това). Ние проследяваме ежедневно работата си чрез индивидуално табло на всяко хранилище и въпреки че несъмнено е полезно да имаме споделени табла, където напредъкът от всяко отделно табло може да се събира на едно място, на практика това се превърна в загуба на време, след като намалихме размера на нашия екип и в крайна сметка ги изоставихме и следователно в момента са подвеждащи за външни хора. Искаме да направим всичко възможно, за да избегнем разсейване, докато се движим напред. За напред, където е приложимо, всеки раздел в седмичните ни новини ще има връзка към информационно табло и ще работим, за да ги поддържаме актуални, така че да съответстват на нашите писмени актуализации за напредъка ни.
Трезори – Фаза 2
Продължихме с тестовете на Трезорите и направихме някои интересни наблюдения. Едно нещо, което наблюдавахме е, че проблемът с използването на паметта може да се дължи на задържането на диаграмата на PARSEC в паметта. Имайки това предвид, разглеждаме различни опции за оптимизиране на съхранението на диаграмата, като потенциално я запишем на хард диска или като я подрязваме по-често, отколкото правим в момента. Анализираме различни параметри, преди да направим крачка в тази посока. Друго наблюдение, което направихме, е, че има значителен скок в използването на паметта, когато Трезор излезе офлайн. Библиотеката за маршрутизиране се опитва да изпрати съобщението няколко пъти, преди да го обяви за „Неуспешно изпращане“ и разглеждаме възможни подобрения, които могат да бъдат направени тук, за да избегнем покачването на използваната памет. С тези нови наблюдения разглеждаме потенциална тестова мрежа (с определени ограничения), за да можем да тестваме различните компоненти, работещи заедно в реална среда. Това предизвика много вътрешни обсъждания и разглеждаме идеи за пренареждане на някаква работа, която да ни позволи да повтаряме тестовете по-бързо и с по-ясна цел при всяка итерация.
SAFE API
Направихме някои малки корекции / поправки на CI скриптове ни, тъй като имаше разработки, необходими за тестването при мобилните устройства, които не бяха публикувани на S3. Тези артефакти не са необходими за потребителите, а само за мобилната разработка и тестване.
След това инвестирахме по-голямата част от времето си, анализирайки как да продължим напред със safe-api и CLI по отношение на това как се вписват в следващите етапи и планове, напр. Fleming и след него. Все още се опитваме да финализираме плана, но изглежда, че се придвижваме към прилагането на новите типове данни от край до край (E2E), т.е. от трезорите към CLI, като се уверим, че същите случаи на използване и сценарии все още работят както сега с актуалните функции на safe-api и CLI. Да поясним, правим това успоредно с усилията ни по разработката на Fleming и затова ще започнем да работим по отделни клонове за въвеждане на новите типове данни в съответните хранилища, включително safe-api.
Започваме да изпълняваме и някои E2E тестове, използвайки тестовия CLI пакет срещу едносекционна мрежа, като подаваме ръка за процеса на тестване, който вече е в ход за версиите на Трезорите от Фаза 2. Надяваме се, че това може да помогне в процеса на отстраняване на проблемите и да се уверим, че е достатъчно стабилна за споделяне с общността, както и да получим по-добра картина как се държи едносекционна мрежа с тестовете CLI E2E и с различните начини за използване, които разглеждаме последните няколко месеца.
Етикети за данните, индексиране и оторизиране на маркери
През изминалата седмица задълбахме по-дълбоко в маркерите, правейки добър напредък в съхраняването на маркерите за преиздаване (което включва промени в клиента за удостоверяването), като по този начин даваме възможност на вече регистрираните приложения да актуализират своя маркер, ако е имало промени в разрешението. Също така обновяваме нашите тестови реализации, за да започнем да изискваме валидни маркери от връзките с приложенията/програмите. Така че в момента напредваме през тестовете, като идентифицираме къде в тези тестове липсва генериране на маркери или къде има нужда от настройване.
Уточняване на видовете данни
Работата по този RFC продължава с по-бавни темпове, успоредно с други задачи с по-висок приоритет за Флеминг.
Някои промени, които се появиха при прегледа на PR последователността, въведоха регресии, които в крайна сметка бяха решени. Сега този клон само чака сливане. След това ще конвертирате safe_client_libs да работи с типа Sequence, за да проведем повече тестове. След това остават safe-api и safe_vault и когато Sequence е внедрена и тествана от край до край, ще продължим с Map в safe-nd.
Дискусиите в темата за RFC на Типовете Данни за използването на ресурсите за различните случаи на използване на Карта в частен обхват, доведоха до нови идеи, предложени от @tfa за разрешаването на този проблем.
Освен това, в сътрудничество с @tfa, беше моделирана нова реализация на полезна функция за Частна Карта, която ще позволи да се върне историята на ключовете обратно към по-ранна версия.
SAFE Network програма
Табло за проследяване на функциите
Продължихме да развиваме взаимодействията около настройването на разрешенията за отделните файлове, папки и приложения.
Сега със силата на Етикетирани данни сме в състояние да разширим това допълнително, като даваме възможност на потребителите да задават отделни разрешения за това, което едно приложение може да направи със собствените си данни - и данните, които създавате с него - и разрешения, които приложенията получават върху останалата част от вашите данни.
Това ограждане на данните трябва да позволи по-леко докосване до упълномощаването на новите приложения при стартиране и използване, за да осигури по-плавно изживяване, като същевременно продължи да поддържа защитата на данните. Това означаваше да преработим някои интерфейси и да променим подхода за разрешения по подразбиране за нови приложения, но си струваше малкото допълнителни инвестиции за по-голямата гъвкавост.
Заедно с етикетите идва и възможността за „умни папки“. Това е не само начин за групиране на данните в общ изглед за управление на файлове без твърда дървовидна структура, но и начин за по-нататъшно подобряване на разрешенията.
Например, бихте могли да искате да изключите всички данни за местоположение от споделяне или публикуване, или да бъдете помолен да проверите два пъти, преди да може да се сподели някоя снимка, независимо къде се намират тези данни или какво приложение е използвано за създаването им.
Има много начини да намалим и подредим тези данни, което означава нюансиран и понякога предизвикателен поток при проектирането, но напредваме с големи крачки и ще имаме още какво да ви покажем скоро!
SAFE браузър (десктоп)
В края на миналата седмица най-накрая отстранихме дългосрочен проблем в браузъра, който блокираше работата на @latch. Вече можете да използвате fetch API-то на браузъра, за да изискате файлове директно от SAFE чрез стандартните JavaScript (т.е. не safe) API-та.
Можете да тествате това с най-новата версия на SAFE Browser Alpha, която пуснахме в началото на тази седмица, съдържаща описаната поправка, заедно с bump на safe-nodejs версията и различни други актуализации на зависимостите.
SAFE браузър (мобилни устройства)
Тази седмица продължихме с щателното тестване на мобилния браузър. Успяхме да поправим множество открити проблеми и да направим някои предложени подобрения. Например мобилният браузър сега показва списък на всички файлове от контейнер за файлове, ако файл index.html не съществува в контейнера с насочени файлове - това възпроизвежда поведението в десктоп браузъра и е особено забележимо на сайтове, където някои версиите имат index.html, докато други не. Поправките включват разрешаване на потребителя да се свърже с различен трезор след повторно удостоверяване, без да се налага напълно да се затваря браузъра, и да скрие навигационните бутони за промяна на версията, когато на екрана се показва някоя страница с грешки.
Остават ни един-два последни проблема, по-специално около съвместимостта с по-стари версии на Android и iOS, които в идеалния случай бихме искали да поддържаме, когато е възможно. Ще продължим да работим върху това през следващата седмица и ще видим какво можем да измислим.
SAFE Удостоверител (мобилни устройства)
Тази седмица, докато тествахме мобилното приложение за удостоверяване установихме, че при някои приложения се запазваха новите разрешения за тестовите монети при оттегляне на разрешенията и повторното удостоверяване. Проследихме проблема до safe_authenticator библиотеката в safe_client_libs и SCL екипът ни пусна корекция. В резултат на това актуализирахме основните библиотеки, които Удостоверителя използваше до последната им версия. Наскоро решихме и друг проблем, открит по време на тестването, за да предотвратим припокриването на полето за въвеждане със софтуерни клавиатури на устройства с малък екран.
Както и при SAFE мобилния браузър и тук стигаме до последните няколко проблема. Основният проблем, който искаме да разрешим, също е около съвместимостта с по-стари версии на Android и iOS, така че ще продължим да работим за намирането на най-доброто решение за това.
SAFE App C#
През последните няколко месеца наблюдаваме чести промени в safe-api и за да сме в крак с това, бяхме пуснали 3 NuGet Release Candidate пакета. Тъй като API-тата вече са по-стабилни, тази седмица пуснахме първия стабилен MaidSafe.SafeApp NuGet пакет, създаден с помощта на safe-api библиотеката . Тази версия съдържа всички промени от всички предишни RC пакети. За да научите повече за промените, моля, проверете пълния регистър на промените. Ще бъде чудесно да видим какви готини приложения може да разработите, използвайки този нов пакет и ако срещнете проблеми, моля, пуснете съобщение в GitHub хранилището.
Safecoin / Фермерство
Тази седмица направихме бърз прототип на bounded counter (bcounter) CRDT на интерпретиран език, за да го разберем по-задълбочено и написахме набор от бележки въз основа на този опит.
Има потенциал за загуба на данни, когато репликата на bcounter премине офлайн, преди да се синхронизират последните му промени с другите участници. При типичното използване на центрове за данни това не е голям проблем, тъй като те могат да използват всеки център за данни като логична реплика с множество физически възли за гарантиране на съхранението. За същото в SAFE мрежата е необходимо да се използва алтернативен подход. Освен това има някои трудности, когато реплики се добавят или премахват от групата, която трябва да бъде обработвана. Работата по тези въпроси започва.
На DBC фронта подготвихме втори документ за дизайна въз основа на дискусиите от първия. Основна идея на тази хибридна система е, че с DBC може:
- да се съхранява в портфейла на потребителя и да се изпраща в мрежата като чек на каса, така че само получателят да може да го депозира. - или -
- да се изнася извън системата като истински сертификат на приносител, който всеки може да осребри / похарчи, подобно на пари в брой или карта за подарък.
Маршрутизиране и quic-p2p
Тази седмица направихме някои значителни опростявания и корекции на кода и в двете библиотеки. Тази работа продължава с известно темпо, тъй като тези подобрения са част от следващите версии. Опростяванията включват:
- Премахване на изискването за получаване на сертификати от quic-p2p и връщане им обратно. Това ни спестява да обработваме картографиране на сертификати в Маршрутизирането и позволява премахването на код. Това премахва състояние, което не се изисква и ще помогне за рестартиране и обновяване. Обърнете внимание, че удостоверяването на възли (трезори) вече се обработва при маршрутизирането чрез криптографски ключове. Това означава че за трезорите, SAFE вече действа като валиден сертификатен орган от гледна точка на автентичността и невъзвръщаемостта. SAFE също се справя с отмяната на удостоверяването и прави това изключително ефективно. Следователно всичко, от което се нуждаем от TLS 1.3 и quic, е защитена и криптирана комуникация, но не и удостоверяване.
- Работа с връзките по по-устойчив начин. Това ни избавя от това да виждаме отпадане на връзката като неуспех и вместо това винаги се опитваме да се свържем, за да открием NotAvailable трезори. Това ще подпомогне рестартирането и обновяването скоро.
- Унификацията на съобщенията ни позволи значително да изчистим инфраструктурата за съобщения, което спомага за сигурността и преглеждането на кода. Тук имаме още малко работа, докато почистваме обработката на връзката и проверката на отзивчивостта.
- Изравняване на мрежовата структура, за да може Секциите да комуникират директно (чрез секцията от Старейшини). Това ще намали значително разстоянието между трезорите и ще позволи по-бързо изграждане на първоначалната мрежа, след което ще може да увеличим разстоянието, докато мрежата расте. Това също ни дава малко повече информация, ако се случи разделяне на мрежата в огромен мащаб (например държава, която прекъсва интернета на ниво IP и така нататък). Процесът тук позволява по-опростен код и възможност на секциите да наваксат информация, докато съобщенията обикалят мрежата (т.е. актуализирането на секции на заден план).
Разглеждаме и стабилна non-responsive проверка за трезорите. Това позволява бързо съгласие, за това кои възли не участват активно (така затваряме вектор на атака).
- Официален сайт на SAFE Network
- Обобщено представяне на SAFE Network
- SAFE Network Фундаменти
- Карта на проекта
- Подробна информация може да намерите както винаги във форума на международната общност: SAFE Network Forum
- Ако имате въпроси може да ги зададете във Facebook групата на българската SAFE общност: Redirecting...
- Ако искате да следите последните новини заповядайте във Facebook страницата на SAFE Network България: Safe Network България