SAFE Network новини - 20.2.2020

SAFE Network новини - 20.2.2020

Накратко

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

Трезори – Фаза 2

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

Няколко малки, но необходими подобрения се правят около опциите за логовете на трезорите. Работихме над няколко PR-а, за да предоставим на потребителя опции за изпращане на логовете във файлове.

Както споменахме миналата седмица започнахме да създаваме прост инструмент, който ще направи стартирането на локална (едносекционна) тестова мрежа много лесно. Постигнахме добър напредък и сега извършваме някои тестове на всички платформи и се опитваме да съставим проста документация за ръководство на потребителя.

SAFE API

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

От обявяването на изданието Rust v1.39, въвеждащо асинхронни/изчакващи изрази, работим паралелно и с нисък приоритет върху опит да мигрираме кодовата база от safe-authd към новия стил на асинхронни/изчакващи изрази. Тази седмица успяхме да финализираме тази работа в safe-authd и jsonrpc-quic контейнерите, прехвърлявйки цялата логика, където Futures се използваха с прости асинхронни изрази. Това, както се очакваше, опрости много кодовата база на тези два контейнера и ни позволи също така да започнем да правим по-добро разделяне на проблемите между jsonrpc-quic и safe-authd контейнерите. Това също ни позволи да актуализираме зависимостта на quinn до последната му версия (v0.5), която вече излага своя API с функции на асинхронизация.

Ще продължим с тази миграция сега на самият safe-api контейнер, отново като задача с нисък приоритет и успоредно с другите задачи, над които работим, за да имаме в крайна сметка API-та за асинхронизация в Rust и в Node.js обвързвания с Promises.

Заедно с подготовката за първата Фаза-2 тестова мрежа започнахме да добавяме и нов набор от подкоманди към CLI-то, този път не само за да позволим на потребителите да инсталират safe_vault в тяхната система, но и да могат да стартират локална мрежа с една секция чрез проста команда.

Успяхме да създадем първи проект за изпълнение и го тестваме на всички платформи. Въпреки че вече е функционален правим някои подобрения, за да гарантираме, че UX е възможно най-доброто. Само за да дадем представа за това, към което се стремим, за да стартираме локална мрежа с една секция с CLI, първо трябва да бъде инсталиран safe_vault във вашата система с $ safe vault install, последван от втора команда за стартиране на локалната мрежа , напр .:

$ safe vault run-baby-fleming
Storing vaults' generated data at ~/.safe/vault/baby-fleming-vaults
Launching local SAFE network...
Launching with vault executable from: ~/.safe/vault/safe_vault
Network size: 8 vaults
Launching genesis vault (#1)...
Genesis vault contact info: ["127.0.0.1:44794"]
Launching vault #2...
Launching vault #3...
Launching vault #4...
Launching vault #5...
Launching vault #6...
Launching vault #7...
Launching vault #8...
Done!

Етикети за данните, индексиране и оторизиране на маркери

RFC, RFC на маркерите, План на проекта

През последната седмица се наблюдаваше стабилен напредък. С актуализираната ни Token структура и въвеждането на потвърждаването в тестовите мрежи плюс финализиране на още един PR, актуализиращ AppKey хранилището ни от Удостоверителя, за да съхраняваме и AuthTokens. Това означава, че вече ще можем да преиздаваме маркери от Удостоверителя, без да се налага да питаме отново потребителя.

Когато приключим с тези последни промени и достигнем настоящата цел ще започнем да разглеждаме по-задълбочено следващите стъпки към етикетите. Така че започнахме да планираме към кои аспекти да се насочим по-нататък и вероятно скоро ще актуализираме RFC на етикетите с информация за това, преди да започнем работа и там.

SAFE браузър (десктоп)

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

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

SAFE браузър (мобилни устройства)

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

Миналата седмица пуснахме нова версия на мобилния SAFE браузър, която осигури pWeb изживяване на мобилни устройства. След излизането му следим внимателно мнението ви във форума и разглеждаме проблемите, които ни докладвате.

Прехвърлихме всички проблеми от темата към GitHub страницата на браузъра, така че да можем да ги проследим и разрешим.

Вече поправихме и затворихме някои от проблемите от списъка, включително замръзването на анимацията със safe етикет в адресната лента под iOS и проблем с удостоверяването, който подтикваше потребителя да разреши браузъра няколко пъти, преди в крайна сметка да се върне към удостоверения браузър и да остави потребителя да продължи. Работата по другите проблеми продължава.

SAFE Удостоверител (мобилни устройства)

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

Както бе споменато в секцията за SAFE браузъра (мобилни устройства), следим внимателно неговата тема във форума и разглеждаме проблемите, докладвани от общността относно SAFE Удостоверителя (мобилни устройства).

Прехвърлихме всички проблеми от темата към GitHub страницата на Удостоверителя, така че да можем да ги проследим и разрешим.

Често срещано мнение от темата беше, че избора на трезори не е толкова интуитивен, колкото би трябвало да бъде, така че прекарахме известно време в обсъждане, разработване и опитване на различни решения за подобряване на потребителския интерфейс. Пуснахме актуализация и можете да разгледате дизайна на новата страница в този PR. Също така коригирахме няколко други докладвани проблеми, включително един проблем, свързан с тъмната тема за мобилното устройство, отменящ собствените настройки на приложенията за iOS и така правейки някои екрани нечетливи; също така активирахме скролването на страницата за вход, за да работи и на устройства с по-малки екрани, които скриват бутона за вход с екранната клавиатура. Ще продължим да работим и върху другите проблеми, които ни съобщавате.

Получената обратна връзка за мобилния браузър и Удостоверителя беше безценна и бихме искали да благодарим на всички, които отделиха време от собствените си натоварени графици, за да помогнат да подобрим оформлението на тези приложения, както и на самата SAFE мрежа :heart:

SAFE App C#

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

За да поддържаме напредъка на мобилните приложения и пакети в синхрон с CLI и настолните приложения, вече започнахме да тестваме работата на API-тата с едносекционна мрежа. Сблъскахме се с някои проблеми, свързани с основните библиотеки генерирани за мобилните устройства, когато различни хранилища (safe-api и safe_client_libs) бяха актуализирани, за да се използват новите версии на Rust контейнера. С помощта на SCL екипа успяхме да открием проблемите и отново продължаваме напред.

Въз основа на тестовете досега, вярваме, че няма да има прекалено много промени в API-тата, преди да бъдем в състояние да пуснем актуализираните пакети и приложения заедно с новите основни библиотеки.

Safecoin / Фермерство

RFC

Тази седмица продължихме работата върху подписания orswot с доказателство за концепцията, обсъдена миналата седмица, като използвахме rust-crdt контейнера за да интегрираме по-задълбочено подписите в самата структура на данните. Остават някои предизвикателства, но изглежда стъпка в правилната посока.

Маршрутизиране и quic-p2p

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

Продължаваме да правим значителни подобрения в нашата мрежова библиотека, quic-p2p. Първото нещо, към което искаме да се обърнем, е поддръжката на IGD. IGD (Internet Gateway Device Protocol) се използва за UPnP в домашни рутери; той позволява на потребителите автоматично да активират пренасочване на портове за приложения, които се нуждаят от него, като VoIP, сървъри за игри и - разбира се - мрежи тип потребител към потребител. И както показа резултатите от теста на Crust, има изненадващо голям брой домашни рутери, поддържащи този протокол и наистина помага да се опрости настройката на Трезорите от вкъщи. Преди имахме поддръжка на IGD в Crust и затова търсим да начин да добавим тази реализация и към quic-p2p.

Друго важно нещо за quic-p2p е поддръжката на услугата Ехо. Всеки трезор има вграден ехо сървър, който позволява на клиентите да намерят своя публичен IP адрес, което е важна стъпка за присъединяване към мрежата. Въпреки това, настоящият клиентски код на quic-p2p има ограничение: той използва само един адрес от списъка с контакти, за да изпрати такава заявка. В случай, че този адрес не отговаря (напр. поради това, че трезорът е офлайн), заявката ще се провали. Това, което искаме вместо това, е нещо подобно на процеса на зареждане: изпращане на запитване към всички наши контакти наведнъж и асинхронно. По този начин бихме постигнали много по-стабилни и добри резултати.

@lionel.faber също работи, за да гарантира, че мрежата работи добре и на мобилни устройства. Той изпрати обновление за quinn , Rust QUIC протокол библиотеката, за да отстрани проблемите, които открива на устройства, базирани на iOS.

Освен всичко това искаме също да опростим API-то на quic-p2p за разработчици, използващи библиотеката. Всички тези промени трябва да са налични в следващото издание, което подготвяме сега.

От страна на маршрутизирането, продължаваме да работим за подобряване на съобщенията - това е механизмът, чрез който трезорите обменят информация, за да постигнат консенсус. Както бе споменато в предишните новини, премахнахме изкуственото забавяне, което забавяше съобщенията. Това означава, че вече можем да постигнем консенсус по-бързо, но сме изправени пред нов проблем - сега създаваме твърде много съобщения и те бързо могат да наводнят мрежата. В момента работим върху решаването на този проблем.

  • Подробна информация може да намерите както винаги във форума на международната общност: SAFE Network Forum
  • Ако имате въпроси може да ги зададете във Facebook групата на българската SAFE общност: Redirecting...
  • Ако искате да следите последните новини заповядайте във Facebook страницата на SAFE Network България: Safe Network България