Накратко
Ето някои от основните неща тази седмица:
- CRDT Tree хранилището вече е публично достояние и контейнера е публикуван на crates.io
- Продължава преструктурирането на кодова база за Маршрутизирането и Трезорите, за да се използва асинхронизация.
- Работата по преструктурирането на преместването на маршрутизирането и премахването на Парсек ще бъде комбинирана в един PR, като това вече е в последните етапи на разработване.
- Подготвихме предварителен преглед на ‘Менюто за работа‘ от потребителския интерфейс на SAFE Network програмата.
CRDT
safe-fs
Прекарахме седмицата в писане на тестове за потвърждаване коректността Tree CRDT типовете данни, както и незначително преструктуриране, за да направим API-то по-чисто и да намалим броят на clone() повикванията. Всички аспекти на CRDT (идемпотентност, комутативност, асоциативност) вече преминават тестовете, както и други специфични Tree тестове, посочени в академичния труд. В GitHub е създадено crdt_tree хранилище и контейнера е публикуван на crates.io
С приключването на Tree CRDT, фокусът ни вече може да се насочи към слоя на файловата система, който ще го използва.
SAFE Клиентски библиотеки и Трезор
SAFE Клиентски библиотеки план на проекта
SAFE Трезор план на проекта
SAFE Клиентски библиотеки и интеграция на Трезора
През последната седмица работихме върху някои по-малки промени, за да сме готови за новия асинхронен quic-p2p, и някои подреждания на CI хранилището, както и върху подобряването на обработката на съобщения в клиента. Основната работа по преструктурирането ни доведе до точка, в която можехме да получаваме отговори на заявки от целия раздел, макар че това доведе до проблем, ако не се получаваше отговор от Старейшина (не се получаваше какъвто и да е отговор … въпреки че всъщност имахме шест ). Затова използвахме някои от future опциите на Rust, за да проверим кои отговори имаме, когато постъпят, и след това да изберем най-подходящите отговори от тези, които получаваме от старейшините. Това ни приближава до ‘кворум‘ версия на отговора и означава, че можем да го върнем веднага щом го получим, без да се налага да чакаме всички 7 старейшини да отговорят.
Подготвяме още една промяна в начина, по който обработваме известията от мрежата от страна на клиента. Преди имахме само една връзка quic-p2p от клиентите към трезорите, чрез които се осъществяват всички средства за комуникация (Заявки / Отговори и Известия). Но сега, когато quic-p2p е актуализиран до асинхронизация и ни позволява да създаваме множество връзки към всеки Трезор, можем да се възползваме от това предимство, като имаме две връзки, основната, която ще се използва за изпращане на заявки, след което изчаква отговори, и вторична връзка, на която слушаме само за Известия. Известията са нещо, което можем да получим дори без да се включваме. Например когато някой изпраща към портфейла ни пари,това не е нещо, което ние правим, но все пак ще получим известието. Следователно това трябва да е връзка, която трябва да е отворена през цялото време, докато сме свързани, и не можем да използваме основната връзка по същата причина, тъй като тя би била доста активна в очакване на собствените си отговори.
Асинхронизация на Трезорите и тестове
Преструктурирането на кодовата база за маршрутизацията и Трезорите, за да се използва асинхронизация, напредва добре. Успяхме да започнем да използваме новото асинхронизирано API на quic-p2p и имаме излагане излагане на async API-то при Маршрутизирането, което Трезора използва за получаване на мрежови съобщения. В момента се опитваме да завършим свързването на логиката за обработка на съобщенията за маршрутизация в това ново изпълнение. Досега успяхме да накараме клиентите и трезорите да разговарят помежду си и почти приключихме с повторното активиране на процеса на първоначално стартиране, над който ще работим през следващите няколко дни.
Тъй като работим паралелно върху целия стек, от quic-p2p, през маршрутизиращ слой и Трезорите, докато напредваме и тестваме всички тези промени, правим корекции на всеки от тези слоеве, ако е необходимо, което е същото, което наскоро направихме с новото асинхронно API на quic-p2p при тестване на трезорите, които се опитват да стартират първоначално.
Маршрутизиране
На първо място, маршрутизиращият клон на Флеминг вече е обединен в основния клон и той е зададен като клон на хранилището по подразбиране. Създадохме pre-fleming таг като отправна точка за предишния „главен“ клон. Вярваме, че е време да предприемем тази стъпка, тъй като се приближаваме към Флеминг целите в маршрутизирането, както и за да бъдем в съответствие с други контейнери, за да избегнем объркване.
По време на работата от миналата седмица за използване на рамката за тестване на Трезорите за проверка на поведението на маршрутизацията при реална употреба на мрежата, открихме някои проблеми. Първият беше свързан с dkg_voter и беше разрешен с PR за записване на завършен DKG section_key_index. Друг проблем е, че нулираме parsec консенсуса на SectionInfo и OurKey, но това вече не са parsec събития, което означава, че не са силно подредени спрямо други събития. Това ще бъде решено, след като премахнем parsec.
Също така работим за подобряване на устойчивостта на DKGVoter срещу злонамерената атака в Акомулиране на DKGOldElders съобщения PR, който бе обединен днес.
Работата по преструктурирането на преместването продължава, като Адам прави голям напредък там. Докато разрешавахме неуспешни тестове, осъзнахме, че би имало смисъл да се премахне parsec едновременно, в същия PR, тъй като разделянето на работата се оказва особено сложно и е загуба на ресурс, да се опитваме да го накараме да работи докато parsec е все още на място. И така, окончателният PR, който все още не е готов да бъде официално повдигнат, ще съдържа както работата по преместването на преструктурирането плюс премахването на парсек. Адам ще почива през следващата седмица, така че тази работа ще бъде предадена на Qi за финализиране.
SAFE Network App UX
Проследяване на функциите / Екрани и движение на потребителя
Тази седмица ви показваме предварителна функция, която е по средата на процеса на проектиране. Няма да я намерите в линка към Екрани и движение на потребителя публикуван по-горе, но тя отмята доста от задачите по пътя към Минималното устойчиво изживяване (MVE), което изграждаме, и може да се окаже доста полезен модел на дизайна, особено когато започнем прехода към потребителските интерфейси за работния плот.
Това наричаме ‘Меню за действие‘. Навигационна система за SAFE Network програмата, която дава едновременно достъп до някои от отклоненията в информационната архитектура и позволява по-бърз достъп до редовно повтарящи се действия, като същевременно осигурява интерфейс за стартиране с леки текстови команди. Нека да го разгледаме.
Достъп до Менюто за действие се осъществява от големия бутон долу вляво …
Елементите в това меню могат да бъдат кликнати / докоснати чрез основните елементи на менюто по начина, по който може да очаквате …
Но тук започва забавата, тази лента за въвеждане в горната част ни позволява да възприемам по-текстови подход, търсейки в елементите от менюто и командите:
И може да стигнем още по-далеч, като напишем по-специфична команда на естествен език. В този пример превеждаме някои средства от портфейла си на приятел:
Което след това ще ни придвижи до края на потока на плащане, с коригиращо обобщение, готово за изпращане:
Освен това виждане история на това, което сме търсили тук, за бърз достъп до скорошни действия:
Освен това може да фиксираме команди към началния екран на менюто, за още по-бърз достъп до команди, които искаме да са ни под ръка:
Освен това, малка екстра, която може да забележите при отворено меню за действие, е, че бутонът за затваряне в долния ляв ъгъл може да се влачи / придвижва, за да излезе потребителят от сесията.
Идеята е да разширим този жест до самия бутон в менюто за действие, позволявайки на потребителя да го задържи и придвижи бързо, за да излезе бързо от почти всяко място в приложението.
И така, надяваме се да сте харесали до къде сме стигнали. Менюто все още е доста грубо, но ще бъде усъвършенствано и обновено през следващите седмици. Кажете ни какво мислите!
Стандартизация
Вероятно сте прочели за текущата работа по стандартизация в новините от миналата седмица, тази седмица започнаха някои допълнителни протоколи за именуване на хранилища и контейнери. С течение на годините сме работили между различни протоколи и в крайна сметка сме получили някаква комбинация между snake_case и kebab-case. Преди нашето намерение беше да стандартизираме с kebab-case, но това доведе до усложнения в Rust, което в някои случаи превръща - в _ и затова повечето имена на контейнерите останаха със snake_case. Сега стигнахме до решение, че трябва да превключим всички имена на контейнери и хранилища на snake_case, за да стандартизираме това най-накрая.
В допълнение към това решихме, че имената на нашите контейнери и хранилища в някои случаи са несъвместими, вече не са точни или са неясни, предвид промените в нашата кодова структура през годините, особено наскоро. Ще прегледаме всеки контейнер и хранилище и ще преименуваме, където е подходящо. Всички, които са специфични за Safe мрежата ще имат префикс sn_.
Тези промени ще бъдат направени през следващите дни/седмици.
- Официален сайт на Safe Network
- Обобщено представяне на Safe Network
- Safe Network Фундаменти
- Карта на проекта
- Подробна информация може да намерите както винаги във форума на международната общност: Safe Network Forum
- Ако имате въпроси може да ги зададете във Facebook групата на българската Safe общност: Redirecting...
- Ако искате да следите последните новини заповядайте във Facebook страницата на Safe Network България: Safe Network България