Български (Bulgarian) 🇧🇬 Добре дошли в Safe Forum

Често Задавани Въпроси

06. За програмисти

Какво ще печелят програмистите?

15% от всичкия добиван Safecoin ще бъде запазван в общ запас за програмистите. Това ще подсигури силно мотивирана общност от програмисти и ще ги награди за създаването на безплатни за използване от потребителите приложения. Програмистите ще могат да публикуват програмите си в SAFE Network. Тези разработчици на приложения са наречени Строители и мрежата ще ги награждава за със Safecoin за използването на приложенията им от потребителите. Това е възможно, защото разработчиците на приложения могат да добавят адрес на свой портфейл в програмите си. Това създава напълно автоматичен модел за печелене на пари от проекти с отворен код както от частни индивиди, така и от фирми за разработване на програми. Програмисти, които работят за подобряване или оправяне на бъгове в SAFE Network, също ще могат да печелят Safecoin при приемане на кода им в ядрото на мрежата.

Причини да разработвате за SAFE мрежата:

  • Достъп до програмите ви от всякъде
  • Без API ключове — просто сваляте кода ни и започвате да го използвате
  • Изключително ниски разходи за привличане на клиенти и никакви инфраструктурни разходи
  • Програми, които се адаптират в реално време към промени в натовареността
  • Подсигурявате сигурност, поверителност и анонимност на всичките си потребители

Аз съм програмист, как мога да се включа?

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

Посетете Dev Hub

Защо SAFE мрежата е с отворен код?

Защото SAFE Network има потенциала да стане важна част от живота на всеки свързан към интернет човек на планетата, MaidSafe са 100% отдадени на идеята всичкия софтуер да е предоставен с отворен код лиценз. Това насърчава иновациите и пречи, който и да е човек, компания или организация да поеме контрол над технологията.

Какъв лиценз с отворен код използва SAFE мрежата?

Всичкия SAFE Network и MaidSafe код е достъпен под GPLv3,BSD или MIT лиценз.

Често Задавани Въпроси

Други

Кой контролира данните, когато се изтрият?

Една от основните характеристики на SAFE мрежата е нейната автономност. Местоположението и движението от един Трезор в друг се контролира само и единствено от SAFE мрежата.

Ако данните от даден Трезор се изтрият недобронамерено/в следствие на авария то те се възстановяват на друг Трезор някъде в мрежата, според ръководните принципи заложени в програмния й код.

Ако потребител изтрие своите данни се случва следното:
– ако данните са уникални за потребителя (т.е. лични) се премахват изцяло от мрежата, заедно с всичките налични копия.
– ‎ако данните не са уникални (т.е. и други потребители ги имат – виж дедубликация) за потребителя, то се премахва само достъпа му до тях, без да се изтриват самите данни (защото ги притежават и други хора).

Какво се случва със старите данни, които се изтриват? Как се заменят?

SAFE мрежата съхранява копия от всеки файл на различни Трезори. Ако някой изтрие данните от своя Трезор, от другите налични в мрежата копия ще се създаде още едно резервно копие, което да замени изтритото.

Какво ще кажете за износването на компютрите и хората, които се нуждаят от закупуване на нов хардуер?

SAFE мрежата е проектирана да използва свободния ресурс, на компютрите на хората, които те използват за лична употреба.

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

Ако компютъра ви се износи, вие ще си вземете нов компютър за да може да го използвате и отново ще може да предоставите свободния му ресурс на мрежата.

Информацията, която се е съхранявала на стария ви компютър и е представлявала част от Safe мрежата не е заплашена от изчезване, защото от всеки файл се съхраняват множество копия на различни компютри. Така когато вашия компютър се развали на други Трезори в мрежата се създават копия на информацията, която преди това се е съхранявала на стария ви компютър.

Какво се случва, ако голям брой хора изведнъж напуснат мрежата?

SAFE мрежата е проектирана да се самовъзстановява. При природен катаклизъм или злонамерена атака (виж Google атака), при които голям брой Трезори изчезнат едновременно от мрежата тя може да се самовъзстанови.

Това става чрез поддържането на множество резервни копия от всеки файл на различни Трезори. Когато 9 от 10 копия изчезнат едновременно, мрежата създава нови 9 копия на нови Трезори.

Ако катаклизма/атаката е засегнала 10 от 10 копия SAFE мрежата отново разполага с механизъм за самовъзстановяване – Датачейн.

Датачейн позволява SAFE мрежата да разбере кои са липсващите части от даден файл и да потвърди “оригиналността” им, когато Трезор съхраняващ конкретния файл се върне онлайн.

SAFE Network новини – 6.2.2020

Накратко

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

  • Пуснахме първия стабилен MaidSafe.SafeApp NuGet пакет, създаден с помощта на safe-api библиотеката :tada:
  • Пуснахме нова алфа версия на 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, План на проекта

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

Уточняване на видовете данни

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

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

Някои промени, които се появиха при прегледа на PR последователността, въведоха регресии, които в крайна сметка бяха решени. Сега този клон само чака сливане. След това ще конвертирате safe_client_libs да работи с типа Sequence, за да проведем повече тестове. След това остават safe-api и safe_vault и когато Sequence е внедрена и тествана от край до край, ще продължим с Map в safe-nd.

Дискусиите в темата за RFC на Типовете Данни за използването на ресурсите за различните случаи на използване на Карта в частен обхват, доведоха до нови идеи, предложени от @tfa за разрешаването на този проблем.

Освен това, в сътрудничество с @tfa, беше моделирана нова реализация на полезна функция за Частна Карта, която ще позволи да се върне историята на ключовете обратно към по-ранна версия.

SAFE Network програма

Табло за проследяване на функциите

Продължихме да развиваме взаимодействията около настройването на разрешенията за отделните файлове, папки и приложения.

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

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

Заедно с етикетите идва и възможността за „умни папки“. Това е не само начин за групиране на данните в общ изглед за управление на файлове без твърда дървовидна структура, но и начин за по-нататъшно подобряване на разрешенията.

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

Има много начини да намалим и подредим тези данни, което означава нюансиран и понякога предизвикателен поток при проектирането, но напредваме с големи крачки и ще имаме още какво да ви покажем скоро!

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

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

В края на миналата седмица най-накрая отстранихме дългосрочен проблем в браузъра, който блокираше работата на @anon57419684. Вече можете да използвате 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 библиотеката :tada:. Тази версия съдържа всички промени от всички предишни RC пакети. За да научите повече за промените, моля, проверете пълния регистър на промените. Ще бъде чудесно да видим какви готини приложения може да разработите, използвайки този нов пакет и ако срещнете проблеми, моля, пуснете съобщение в GitHub хранилището.

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

RFC

Тази седмица направихме бърз прототип на bounded counter (bcounter) CRDT на интерпретиран език, за да го разберем по-задълбочено и написахме набор от бележки въз основа на този опит.

Има потенциал за загуба на данни, когато репликата на bcounter премине офлайн, преди да се синхронизират последните му промени с другите участници. При типичното използване на центрове за данни това не е голям проблем, тъй като те могат да използват всеки център за данни като логична реплика с множество физически възли за гарантиране на съхранението. За същото в SAFE мрежата е необходимо да се използва алтернативен подход. Освен това има някои трудности, когато реплики се добавят или премахват от групата, която трябва да бъде обработвана. Работата по тези въпроси започва.

На DBC фронта подготвихме втори документ за дизайна въз основа на дискусиите от първия. Основна идея на тази хибридна система е, че с DBC може:

  1. да се съхранява в портфейла на потребителя и да се изпраща в мрежата като чек на каса, така че само получателят да може да го депозира. - или -
  2. да се изнася извън системата като истински сертификат на приносител, който всеки може да осребри / похарчи, подобно на пари в брой или карта за подарък.

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

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

Тази седмица направихме някои значителни опростявания и корекции на кода и в двете библиотеки. Тази работа продължава с известно темпо, тъй като тези подобрения са част от следващите версии. Опростяванията включват:

  1. Премахване на изискването за получаване на сертификати от quic-p2p и връщане им обратно. Това ни спестява да обработваме картографиране на сертификати в Маршрутизирането и позволява премахването на код. Това премахва състояние, което не се изисква и ще помогне за рестартиране и обновяване. Обърнете внимание, че удостоверяването на възли (трезори) вече се обработва при маршрутизирането чрез криптографски ключове. Това означава че за трезорите, SAFE вече действа като валиден сертификатен орган от гледна точка на автентичността и невъзвръщаемостта. SAFE също се справя с отмяната на удостоверяването и прави това изключително ефективно. Следователно всичко, от което се нуждаем от TLS 1.3 и quic, е защитена и криптирана комуникация, но не и удостоверяване.
  2. Работа с връзките по по-устойчив начин. Това ни избавя от това да виждаме отпадане на връзката като неуспех и вместо това винаги се опитваме да се свържем, за да открием NotAvailable трезори. Това ще подпомогне рестартирането и обновяването скоро.
  3. Унификацията на съобщенията ни позволи значително да изчистим инфраструктурата за съобщения, което спомага за сигурността и преглеждането на кода. Тук имаме още малко работа, докато почистваме обработката на връзката и проверката на отзивчивостта.
  4. Изравняване на мрежовата структура, за да може Секциите да комуникират директно (чрез секцията от Старейшини). Това ще намали значително разстоянието между трезорите и ще позволи по-бързо изграждане на първоначалната мрежа, след което ще може да увеличим разстоянието, докато мрежата расте. Това също ни дава малко повече информация, ако се случи разделяне на мрежата в огромен мащаб (например държава, която прекъсва интернета на ниво IP и така нататък). Процесът тук позволява по-опростен код и възможност на секциите да наваксат информация, докато съобщенията обикалят мрежата (т.е. актуализирането на секции на заден план).

Разглеждаме и стабилна non-responsive проверка за трезорите. Това позволява бързо съгласие, за това кои възли не участват активно (така затваряме вектор на атака).

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

SAFE Network новини - 13.2.2020

Накратко

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

Екипът

Жан-Филип ще си вземе малко почивка за следващите 2 месеца и нещо. Напоследък беше натоварен период с много бързо движещи се части и Жан чувства, че трябва да се погрижи малко по-добре за себе си. Това значи малко почивка и отдалечаване от компютъра за известно време. Затова му пожелаваме всичко добро и се надяваме той да се почувства освежен много скоро.

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

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

След като направихме някои наблюдения от тестовете ни, се насочихме към различните движещи се части (Маршрутизация, quic-p2p, Трезори и SAFE Клиентските Библиотеки), за да направим някои корекции, опитвайки се да разрешим някои от проблемите, пред които сме изправени. Quic-p2p вече има отделни канали за съобщения от Клиентите и Трезорите в мрежата. Това също така премахна използването на сертификати, което опростява нашата настройка за тестване и самата мрежа. Също така установихме, че маршрутизиращите възли изпращат съобщения на редовни интервали от време, което в крайна сметка означава, че този интервал ще определи скоростта на самата мрежа. Поиграхме си с този параметър определящ продължителността между съобщенията и забелязахме, че с по-ниски интервали на съобщенията мрежата е по-бърза. Затова решихме да го настроим на нула :smile:. Да, точно така. С други думи, премахваме изцяло интервала на съобщенията и преминаваме към подход, основан на събития, така че съобщенията да бъдат задействани от клиентски и мрежови събития. Това подобрение е в процес на разработка и ще продължим с такива тестове от край до край, за да идентифицираме и други области на подобрение.

Както споменахме в предишните новини, започнахме да използваме CLI и safe-api тестовете с локална мрежа с една секция и сме много щастливи да видим успешното им преминаване! Въпреки това, както беше казано по-горе, все още трябва да направим някои подобрения във времето за реакция на мрежата, преди да я считаме за готова.

Тъй като развитието на трезорите напредва към създаването на първата тестова мрежа Фаза-2а, тази седмица започваме с разработването на прост инструмент за стартиране на мрежата, който ще позволи на потребителите да стартират локална мрежа с една секция. Все още мислим за подробностите за внедряването, които скоро ще бъдат отразени в плана на проекта за инструмента.

Съществуват и някои идеи около това да дадем на CLI-то достъп до този инструмент, така че стартирането и използването на локална Фаза-2a мрежа да може да става изцяло от CLI-то. Но това е само груб план за момента, ще видим как нещата се развиват в следващите няколко дни на всички фронтове. Както винаги, се стремим да направим нещата възможно най-прости от UX гледна точка.

SAFE API

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

Работейки върху някои актуализации на SAFE Network App, които включват използването на самото приложение за управление на инсталации на CLI и AuthD, отново се натъкнахме на проблеми с libso под Linux, които блокират CI сървърите там. Вследствие на това разгледахме какви опции имаме за да се справим с това, което доведе до PR към self_update контейнера (контейнера, който в действителност носи зависимостите libso/openssl), за да използваме основна реализация на rust. В момента чакаме известна обратна връзка за този PR и след като имаме това (и някои свързани quic-p2p промени), ще можем да актуализираме библиотеките и след това да ги използваме за SAFE Network App.

Обновяването на quic-p2p във всички контейнери, включително safe_client_libs, би ни позволило да обновим quinn в safe-authd и safe-api, и върху това започнахме да работим като подготовка за следващото ни издание на safe-api и CLI, което е планирано да бъде за първата фаза-2a на тестовата мрежа.

Тъй като сега фокусът е върху Фаза-2a на тестовата мрежа, започнахме да работим и върху нов набор от CLI подкоманди, които биха позволили на потребителите да инсталират трезор в тяхната локална система, напр. с команда $ safe vault install. Планът е CLI да може да се използва за изтегляне и стартиране на safe_vault за създаване на локална мрежа с една секция (Фаза-2a). Тази команда се планира да бъде в помощ на инструмента за стартиране на мрежата, който ще пуснем в следващите няколко дни. За момента няма повече подробности, но в следващите дни ще видите някаква активност в съответните хранилища.

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

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

Вече завършихме интеграцията на тестове за маркери, като пълният пакет тестове преминава добре, което означава, че ще можем да преминем към изпълнение на същите тестове и за Трезорите и ще имаме маркери, работещи нявсякъде. Междувременно @yogesh продължи работата по съхраняване/извличане на маркерите, за да се даде възможност за актуализиране на маркери и промени в разрешенията от Удостоверителя, без да се налага да актуализирате самото приложение.

Публикувахме и „нов“ Маркер RFC, който всъщност не е много нов, но се надяваме да показва по-ясно обхвата на работата, включена в маркерите, без всички допълнителни концепции от предишните етикети/индексиране/удостоверяване-промени-прихващане-на-всичко-RFC. Има някои малки подобрения там за тези от вас, които се интересуват от такива неща.

SAFE Network програма (десктоп)

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

Тази седмица свършихме и малко работа тук, с първоначален опит да заобиколим CLI / Authd зависимостта ни, но в крайна сметка решихме да запазим CI на SAFE Network програмата, използвайки истински библиотеки, за да гарантираме, че всичко ще се държи според очакванията. Това ни дава повече увереност не само в самата SAFE Network програма, но също така ще подчертае всички евентуални проблеми в свързаните мрежови компоненти.

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

План на проекта за Браузъра, План на проекта за Удостоверителя

През последните няколко месеца работим върху множество независими компоненти, за да внесем някои нови функции и особености при мобилни устройства. След множество разработки и тестване на основните етапи в различни хранилища, тази седмица пуснахме нови версии както на мобилните приложения за удостоверяване, така и на браузъра :tada:.

Новите версии включват мрежова поддръжка за един Трезор и за двете приложения, и pWeb възможности в мобилния браузър - вече можете да преглеждате историята на всеки SAFE сайт :exploding_head:

Ако все още не сте започнали да използвате новите приложения, вижте темата за изданието, за да научите повече за всички нови промени и как можете да ги изпробвате на мобилните си устройства (Android и iOS). Развълнувани сме да видим как двете приложения подобряват SAFE потребителското изживяване на мобилни устройства.

Благодарим на всички, които вече изпробваха приложенията и ни предоставиха безценни отзиви. Моля, продължете с отзивите, заявките за функции и дори съобщенията за грешки :smile:, за да можем да започнем да планираме следващата версия.

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

RFC

CRDT типовете данни обикновено се използват в надеждна среда, напр. между центровете за данни. Тази седмица проучваме идеята за добавяне на агрегиране на подписи (множество подписи за транзакция) към типове набори от CRDT като orswot, за да предоставим криптографско доказателство, че кворум от старейшини се съгласява за дадена информация. След постигане на кворума теоретично може да се осигури съкращението/наличността, необходимо на bounded counte CRDT, който разгледахме миналата седмица.

За тази цел реализирахме малко доказателство за концепцията чрез Rust, което демонстрира 7 старейшини, които подписват част от данните, добавяйки ги към orswot и след това валидирайки подписите на другите старейшини, за да се гарантира, че е постигнат кворум, преди данните да могат да бъдат използвани. Тази работа е все още в много ранно/грубо състояние и продължава, но резултатите изглеждат много обещаващи и в крайна сметка биха могли да имат ползи/последствия в области извън Safecoin.

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

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

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

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

Тази седмица завършихме работата по премахване на използването на quic сертификати, опростявайки допълнително кода ни.

Освен това завършихме работата позволяваща на трезорите да обработват клиентски съобщения директно, без да е необходимо маршрутизирането да действат като посредник между тях.

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

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

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

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 общност: SAFEnetwork България | Facebook
  • Ако искате да следите последните новини заповядайте във Facebook страницата на SAFE Network България: Safe Network България

SAFE Network новини - 27.2.2020

Накратко

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

Обобщение

Наехме експерт по безконфликтни репликирани типове данни да прегледа SAFE мрежата и също така да помогнем за създаването на прототип на византийско CRDT решение, устойчиво на откази. Това би могло да ни позволи да боравим ефективно с едновременни данни, както и с офлайн работата и още много неща. Това също, което може би е по-важното, ще осигури по-нататъшното формализиране на типове данни с конкретни гаранции за коректността. Голяма част от данните ни са много близки до CRDT решението, но формално не е така. Това упражнение ще ни осигури поне по-голяма яснота относно правилността на мутациите на данните. Тази работа е планирана да започне на 5 март и се очаква да отнеме около 8 седмици. Ще споделим повече подробности с напредването на работата.

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

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

От наблюденията ни върху вътрешните тестови мрежи направихме много подобрения в маршрутизацията, PARSEC и SAFE Клиентските библиотеки, което ни приближава до началото Бейби Флеминг. С подобренията в обмяната на съобщенията (повече подробности в раздела „Маршрутизация“) наблюдаваме стабилизирано използване на процесора и паметта от трезорите и също така тестовете преминават успешно. Направихме някои подобрения в клиентските библиотеки, за да подобрим скоростта, като пропускаме частта, в която чакаме всички трезори да отговорят на GET заявките.

Първата версия на инструмента за стартиране на мрежата (за да може да се стартира локална мрежа Бейби Флеминг) също беше завършена и успешно тествана върху всички (Linux / macOS / Windows) платформи. Този инструмент покрива само най-основните изисквания за предстоящото издание и вече е интегриран в CLI, което означава, че няма да има нужда да го пускате отделно, може да го използвате с конкретни CLI команди (вижте по-долу за подробности) ,

SAFE API

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

Миналата седмица финализирахме подобрение, направено в CLI командата за синхронизиране на файлове ( files sync) , което добавя поддръжка за откриване на модифицирани файлове, дори когато размерът им не се промени. Това стана възможно благодарение на разработката ни по изчисляването на XOR-URL адреса на локалните файлове, без да е необходимо да ги качваме в мрежата, което ни позволява да правим това по много ефективен начин. Чрез просто сравняване на XOR-URL адресите на локалните файлове с тези, които вече са свързани с целевия FilesContainer, можем да открием кои файлове са променени и следователно да ги качим отново с операция за синхронизиране.

Успяхме да финализираме и обединим PR, за да имаме команди, свързани с трезорите в CLI и добавихме подробни инструкции към CLI Ръководството за потребителя, за това как да ги използвате за инсталиране на safe_vault и за стартиране на локална Бейби Флеминг мрежа, използвайки инструмента за стартиране на мрежата. Ако погледнете ръководството за потребителя, вече ще можете да разберете колко лесно ще бъде да стартирате локален Бейби Флеминг чрез CLI, след като го завършим и пуснем.

Тъй като подготвяме всички PR-и и контейнери за предстоящето излизане на Бейби Флеминг, текущото състояние на master клона на safe-api хранилището не е съвместимо с Трезорите версия v0.20.1, нито на локално ниво, нито със споделения трезор. Следователно изграждането на CLI / authd от главния клон не може да се използва с мрежа с един трезор и ще може да се използва само с Бейби Флеминг мрежата.

Също така започнахме да правим необходимите промени в safe-api-то, за да можем да поддържаме поточно съдържание, като позволимда извличането на файлове, предоставящи диапазон от байтове. Това ще трябва да бъде изложено от настолния SAFE браузър, за да може всяка уеб страница да предава видеоклипове или всякакъв друг вид съдържание по стандартния начин, т.е. чрез HTTP Range.

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

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

Тази седмица довършихме огромната част от прилагането на маркерите :tada:. С прегледа на окончателния PR за трезора, позволяващ правилната проверка на маркерите и възраженията в трезорите, проверяването на тези маркери спрямо запаметените идентификационни данни в приложението, което ни позволява да откриваме и отхвърляме текущи (по-рано издадени) маркери за дадено приложение.

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

Някои поправки се правят в клиентските библиотеки, за да отделят специфичния за FFI код от основната логика. Това разчиства пътя към новите промени, идващи в SAFE Клиентските библиотеки, които ще ускорят разработването на нови функции, подобрения и поправки.

SAFE Network програма

Работихме усилено по отношение на UX разрешенията за файловете и данните, може да видите напредъка до този момент представен от @jimcollinson в този видеоклип:

Building the SAFE Network UX | Controlling Access to your Personal Data

Кажете ни какво мислите за това как всичко се оформя!

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

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

След някои класически болки в Windows-CI през изминалата седмица, решихме да да преобразуваме нашата система за непрекъсната интеграция (Continuous Integration - CI) в GitHub Actions. Това - донякъде шокиращо за работата на CI - беше доста приятна афера. GitHub Actions се оказват мощни, гъвкави и бързи. Най-накрая CI системата подписва всички наши излизащи продукти. (Преди това под Windows това трябваше да се прави ръчно). Тъй като това работи добре, решихме да преминем през тестове и да автоматизираме повечето от процеса на пускане на нови версии. Всички това изглежда работи по-бързо, отколкото беше под Travis CI.

Сега автоматично ще генерираме алфа / бета версии само от един маркер (изобщо няма да е необходима човешка намеса!). Което ще освободи доста от бюрото на Стивън.

Единственият проблем, който имахме в новия процес, беше подкарването на тестовете за macOS под GitHub Actions. Това се оказа трудно, тъй като изглежда, че е необходимо някакво потребителско взаимодействие, за да се приемат някои разрешения, и няма очевиден начин за автоматизиране (ако някой има опит с GHA E2E и има решение за това моля да ни уведоми!). Междувременно ще продължим да тестваме macOS e2e тестове под Travis CI.

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

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

Днес пуснахме версия 0.3.1 на SAFE браузъра за мобилни устройства :tada:

Тази версия идва 2 седмици след изданието ни v0.3.0, поддържаща Вечната мрежа и включва няколко корекции и подобрения въз основа на обратната връзка, получена от тази версия. Например, поправихме веригата за удостоверяване под iOS, както и проблемът с претоварването на тъмната тема под iOS и добавихме логика на поддръжка за аудио стрийминг в Android.

За пълен списък на промените в това издание вижте списъка с промени тук или разгледайте колоната Done в Плана на проекта тук, където ще видите проблемите и PR-тата с v0.3.1 етикета.

За пълни инструкции за инсталиране на браузъра на вашето мобилно устройство и за това как да го свържете към Трезора, моля, вижте предишната публикация във форума тук.

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

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

За да придружим новия мобилен браузър, днес пуснахме и версия 0.2.1 на SAFE Удостоверителя за мибилни устройства :tada:

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

Отново за пълен списък на промените в това издание вижте списъка с промени тук 2 или разгледайте колоната Done в Плана на проекта тук, където ще видите проблемите и PR-тата с v0.2.1 етикета.

Не забравяйте да прочетете предишната публикация във форума тук за пълни подробности относно Удостоверителя и Браузъра и как да ги инсталирате и използвате.

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

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

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

Тази седмица най-накрая приключихме работата по подобряването на клюките (както беше споменато в предишните две седмици - клюките са механизмът, чрез който възлите обменят съобщения за актуализиране на вътрешното си състояние, за да постигнат консенсус по напълно децентрализиран начин). След като проучихме няколко проблемни места, в крайна сметка намерихме подход, който премахва изкуственото забавяне между съобщенията за клюки, като същевременно избягва наводняването на мрежата с твърде много съобщения. Това доведе до доста приятно подобрение на производителността в нашите вътрешни тестове на Бейби Флеминг. Освен това, разкрихме няколко параметъра, които ни позволяват да подобрим мрежата допълнително, като по този начин е възможно да постигнем още повишаване на производителността след повече тестове.

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

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

SAFE Network новини - 12.3.2020

Накратко

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

  • Пуснахме SAFE браузър v0.16.0, който е съвместим с локалната / споделена версия на Трезора. Но не и с версията за Бейби Флеминг.
  • Пуснахме и SAFE браузър v0.17.0-alpha.0, който е съвместим с Бейби Флеминг. Но не и с локалния / споделен трезор.
  • Създадохме инсталационен скрипт за SAFE CLI. Вече е възможно да инсталирате SAFE CLI v0.9.0 с него.
  • Благодарим ви за отзивите относно версия 1 на Бейби Флеминг. Наближаваме бързо към версия 2.

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

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

След като пуснахме миналата седмица Бейби Флеминг, получихме много отзиви и резултати от тестове от общността. На първо място, благодарим на всичките ви за отзивите. Много ги ценим, особено по време на тестовите версии. Продължавайте да ни пишете!

Както може би сте виждали, повечето от тези проблеми се дължат на известно закъснение и голямо използване на паметта от Старейшините (отговарящи за клиентите). Това е така, защото всички клиентски заявки, свързани с харченето на safecoin, бяха изпращани чрез PARSEC за постигане на консенсус, преди да се обработи допълнително заявката. Това може да отнеме известно време в зависимост от размера на заявката, броя на заявките, които се обработват и т.н. Наясно сме с това и ще работим да го подобрим през следващите седмици. Имайки това пред очи, за да помогнем с тестването на останалите функции (API, CLI команди и т.н.), ще премахнем PARSEC от потока за обработка на заявки от клиентите и ще пуснем нова версия на трезора. Тестваме това вътрешно и след като сме готови, ще пуснем следващата итерация на тестовата мрежа Фаза 2a. С по-бързи времена на реакция, би трябвало да можем да пуснем и трезори, хоствани на облачни машини, което значи, че ще имаме и споделена Секция :wink:Останете на линия!

SAFE API

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

През последните няколко седмици успяхме да внедрим още няколко функции към CLI-то. Една от тях е добавянето на files rm команда, която може да се използва за премахване на файл или цял път от съществуващ FilesContainer. Това беше финализирано точно навреме, за да бъде част от Бейби Флеминг миналата седмица, така че можете да го използвате вече със SAFE CLI v0.9.0.

Веднага след пускането на Бейби Флеминг, продължихме с още една функция, която ни дава възможност да изброяваме файлове в дървовидна форма с добавяне на files tree команда, която може да бъде наистина полезна за потребителите, които се опитват да разберат йерархията на файловете в FilesContainer, например:

$ safe files tree safe://hnyynysurwzoiudugs47d7fjx7hwg3i7ch1ryowdm7gpgj4538n1mwqukgbnc
Files of FilesContainer (version 0) at "safe://hnyynysurwzoiudugs47d7fjx7hwg3i7ch1ryowdm7gpgj4538n1mwqukgbnc"
SIZE CREATED MODIFIED NAME
/
6 2020-03-03T22:31:21Z 2020-03-03T22:31:21Z ├── another.md
0 2020-03-03T22:31:21Z 2020-03-03T22:31:21Z ├── noextension
├── subfolder
4 2020-03-03T22:31:21Z 2020-03-03T22:31:21Z │ ├── sub2.md
23 2020-03-03T22:31:21Z 2020-03-03T22:31:21Z │ └── subexists.md
12 2020-03-03T22:31:21Z 2020-03-03T22:31:21Z └── test.md

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

Като паралелна задача и както се очакваше от предишните новини, продължихме с миграцията към използването на Rust async/await в safe-api хранилището, задача, която стартирахме още през ноември 2019 г. и най-накрая я добавихме в основния клон, който мигрира цялата кодова база от safe-api, за да използва async/await. Тъй като се опитваме да направим тази миграция, без да засягаме други компоненти, в тази първа стъпка излагаме SAFE API-тата на Rust като async, но вътрешно те все още се заключват, когато се обаждаме към API-то на safe_client_libs. Следващата ни стъпка е да се опитаме да мигрираме не само safe_client_libs, за да разкрием API-тата на async, но и API-тата на safe-nodejs, за да могат да върнат Promises.

След цялата упорита работа на общността в темата за тестовата мрежа, преглеждаме възможността да настроим правилно тестване в CLI с помощта на Бейби Флеминг мрежата. Надяваме се, че ще успеем да направим това по начин, който ще помогне на онези от вас, които вече правят отлични тестови скриптове, за да направите пряк принос в тестовете за сравнителен анализ на мрежата. Тези тестове ще се изпълняват на CI, но също така трябва да имат за цел да бъдат достатъчно лесни за използване / промяна, така че да можем да ги използваме за тестване локално възпроизводимо ниво във всяка система.

И накрая, успяхме да създадем инсталационен скрипт за SAFE CLI. Този скрипт не само изтегля най-новата налична SAFE CLI, но и инсталира CLI в папката ~/.safe/cli/ (C:\Users<user>.safe\cli\ в Windows), като го и задава в PATH, така че можете да стартирате safe файла от всяко място, когато отваряте конзола. Актуализирахме Ръководството за потребителя с инструкции как да използвате този метод на инсталиране на CLI. Вече е възможно да инсталирате SAFE CLI v0.9.0 с помощта на този скрипт.

Обърнете внимание, че има съобщения че скрипта за инсталиране не се добавя към PATH за zsh и fish конзоли, може да се наложи да добавите ръчно към вашия .bashrc еквивалент, ако скриптът не го добави към PATH на вашита конзола.

SAFE Network програма

Продължава работата по проектирането на потребителските интерфейси и потоци за разрешенията на файловете и споделянето.

Тази седмица започнахме разделянето на първоначално комбинираната емисия в отделни списъци с опции за достъп до програмата (App access) и споделянето (Sharing). Това прави малко по-различните потоци за всеки от тях по-ясни, а също така избягва излишното персонализиране на приложения; Достъпът до приложения е предимно за управление на достъпа ви до вашите собствени данни, а не за да предоставяте на разрешения на други потребители.

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

2c26a9100d3c5b76c93c219845732ea9dfee9f70_2_615x500

Достъп до програма спрямо споделяне

Готови сме и с пълното оформление на екраните с подробности за файлове, папки и етикети, както и настройки за тяхното навигиране и манипулиране.

09c873d80edc295b49358428dc473d5f2d82180c_2_247x499

Управление на файлове

Сега работим по потоците за публикуване и споделяне на файлове чрез SAFE Network програмата.

3af187e83f3f1759ffc9fa3bfe6754f639ac78b6_2_310x500

Публикуване и споделяне

Относно разработката, след като актуализирахме всички зависимости, за да премахнем болезнената зависимост от openssl (и да използваме основните rust rustls), започнахме да актуализираме SAFE Network програмата, за да работи отново със CI, но също така и да е съвместима с любимата на всички Бейби Флеминг. :baby:

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

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

Тази седмица най-накрая пуснахме SAFE браузър версия 0.16.0, която има няколко подобрения: Възможност за контрол на достъпа за опростяване на уеб разработката, даваща възможност за извличане на API-то и актуализиране на safe-nodejs до 0.8.0. Но внимавайте! Това не е съвместимо с Бейби Флеминг.

За онези безстрашни хора, които искат възможността да тестват сами, предлагаме v0.17.0-alpha.0. Тази версия носи съвместимост с Бейби Флеминг, както и прескача използването на safe-nodejs библиотеката за предотвратяване на достъпа до файловата система без да минава през API-тата на браузъра (благодарим на @shane). Това все още не е напълно завършено. Планираме да дадем възможност на API-тата в браузъра да работят директно с файлови обекти, за да улесним живота на всички. Но засега това поне подобрява сигурността и ни насочва към по-финализирани API-та.

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

След като пуснахме Бейби Флеминг се заехме да актуализираме всички необходими хранилища (quic-p2p, safe_client_libs, safe-api), за да сме готови да поддържаме същия набор от функции на мобилни устройства, както и да актуализираме NuGet пакета ни. Използваме отделен клон baby-fleming-mobile във всички тези хранилища, за да проследим необходимите корекции и промени. След като получим надстройките, работещи върху CI и получим работния набор от местни библиотеки, ще тестваме API-то на C # и мобилните приложения с Бейби Флеминг и ще пуснем новите версии за мобилния удостоверител и браузър.

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

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

Тъй като екипът за маршрутизирането е в отпуск, има само малък напредък, който да отчетем тази седмица. Една текуща задача, която се приближава към завършване, е подобряването на доставката на съобщения при наличие на изоставащи трезори (PR 2068). Работим и върху подобряването на тестовете ни, за да отразяваме по-точно реалността, което би трябвало да ги направи по-надеждни и евентуално дори по-бързи (това е във фаза на планиране, така че все още няма PR). Ще дадем повече информация за тези промени, когато те са по-близо до завършване.

Също така започнахме работа по схема за групово подписване, използвайки разпределено генериране на ключове (BLS-DKG, без централно ръководство/ управление), което да се използва за постигане на консенсус, когато клиентите заявяват данни от мрежата (въпреки че това потенциално е насочено да се използва за много повече неща в бъдеще), без да е необходимо винаги да преминавате през PARSEC. В момента тази работа е в начална фаза. Както винаги ще информираме общността, докато напредваме.

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

SAFE Network новини - 19.3.2020

Накратко

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

  • Пуснахме версия 2 на Бейби Флеминг. :tada: Тази актуализация се състои от нова версия на safe_vault (v0.22.0), която премахва PARSEC за клиентски заявки.
  • Пуснахме SAFE CLI v0.10.0, която включва (наред с други подобрения) нова команда files tree.
  • Пуснахме нов пакет RC MaidSafe.SafeApp NuGet, който поддържа заявки с различен обхват и работи с Бейби Флеминг мрежата.

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

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

Днес пускаме втората версия на Бейби Флеминг, известна още като Трезори Фаза 2a :tada:

Както беше подробно описано в новините от миналата седмица, проблемите с производителността при първата версия на Бейби Флеминг се дължаха основно на всички клиентски заявки при харченето на Safecoin чрез PARSEC за постигане на консенсус, преди да се обработи допълнително заявката. Версия 2, която пускаме днес, премахването PARSEC от потока за обработка на заявка на клиента.

Разбира се, все още ще трябва да постигнем консенсус в този поток и там ще използваме BLS - разпределеното генериране на ключове, за да облекчим натоварването върху PARSEC. Повече за това в раздела BLS - Разпределено генериране на ключове - по-долу. Засега обаче има смисъл да премахнем това ограничение на производителността ви позволим да тествате Бейби Флеминг.

Как да обновите до версия 2 на Бейби Флеминг?

Тази актуализация се състои от нова версия на safe_vault - v0.22.0.

С помощта на CLI можете да инсталирате тази нова версия с помощта на командата safe vault install. Вижте CLI ръководството за пълни инструкции за инсталиране на трезора, както и за инструкции как да пуснете собствена секция от трезори на компютъра си.

Известни проблеми

При качване на данни може да възникнат периодични грешки (AccessDenied или NetDataError - Failed to PUT Sequenced Append Only Data описани тук). Наясно сме с това и разследваме.

Кога MaidSafe ще пусне споделена Секция?

Намерението ни е да пуснем споделена Секция веднага щом тестването покаже, че секциите са стабилни, а основните грешки са решени.

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

SAFE API

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

Пуснахме нова версия на safe-api (v0.10.0), както и нов safe-cli (v0.10.0), който включва всички функции, които сме внедрили след излизането на Бейби Флеминг. Актуализирахме Ръководството за потребителя за CLI с инструкции за новата files tree команда.

Тази нова версия на safe-api е първата версия, която излага API-то си като async, което е важна стъпка към пълната поддръжка на асинхронни заявки от тези API-та. Както бе споменато в предишните новини, вътрешно те все още не са асинхронни и това ще бъде следващата ни стъпка в това отношение.

През последните няколко седмици мобилните библиотеки на safe-ffi бяха деактивирани. Проблемът беше свързан с мобилната поддръжка за някои от външните контейнери на Rust. Тази седмица решихме проблема с изграждането на safe-ffi в отделен клон (baby-fleming-mobile). След като имаме стабилни версии на външните контейнери, които работят правилно със собствените си библиотеки, ще обединим кода с главното хранилище. Тези актуализирани библиотеки ще ни помогнат да подкрепим пускането на мобилните приложения за мрежата с една секция.

Финализирахме основен набор от показатели, които да се изпълняват в Бейби Флеминг мрежата. Тези тестове са просто за качване на данни в мрежата (файлове с размер 0.5, 1, 2 и 4 мегабайта). Тестовете бъдат X пъти (търсейки разумен размер на извадката, надяваме се поне ~ 50 пъти), макар че това ще зависи от напредъка за подобряването на качването на данни като цяло. За тези, които се интересуват от това (или да допринесат за повече тестове), можете да проверите PR черновата, която добавя -t или–test аргумент на любимия на всички safe vault run-baby-fleming -t за автоматично стартиране на мрежата, рестартира удостоверителя и създава тестов акаунт за CLI-то. (Забележете, за да работи това се нуждае както от safe командата, така и от authd, да бъдат инсталирани на стандартните им места).

SAFE Network програма

Тази седмица работихме върху някои малки подобрения на SAFE Network програмата, актуализирайки зависимостта от Node.js, за да се подготвим за съвместимо издание с Бейби Флеминг и поправихме теста на E2E.

Актуализацията на Node.js подчерта някои потенциални грешки там, така че разглеждаме и това. Но след като ги оправим, ще можем да я пуснем за да си поиграете с :baby:

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

План за Удостоверителя, План за браузъра

Тази седмица актуализирахме Удостоверителя, за да поддържаме Бейби Флеминг и тествахме програмата на двете платформи (Android, iOS).

Днес пуснахме и нов пакет RC MaidSafe.SafeApp NuGet, за да можем да актуализираме мобилния браузър и да поддържаме Бейби Флеминг. В момента вътрешно тестваме мобилния браузър и ще пуснем нови актуализирани версии и на двете мобилни приложения, след като сме доволни от тях.

SAFE App C#

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

Миналата седмица API за извличане (fetch) на Rust беше актуализирано, за да поддържа извличането на диапазон от байтове от файл, така че тази седмица актуализирахме C# API-тата за fetch и get_immutable_data за да поддържаме и заявки с обхват. Това ще позволи на разработчиците да извличат съдържанието между дадения начален и краен индекс. Пуснахме и нов RC MaidSafe.SafeApp NuGet пакет. Този нов пакет осигурява поддръжка за мрежата с една секция / Бейби Флеминг.

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

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

Обединихме и подобрена се доставка на съобщения в присъствието на изоставащи с работата трезори в PR (PR 2068). Друг голям напредък, който постигнахме включва обединяването на работата по опростяване на моментното състояние на машината: одобряването на Старейшини и Възрастни (PR 2071), както и BoostrappingPeer и JoiningPeer в едно (PR 2072). Те много опростяват състоянието на машината и в крайна сметка ще се стремим да го премахнем изцяло. Друго подобрение през тази седмица беше обединяването на идентификатора за регистрация PR (PR 2073). Това намалява нашия код и гарантира, че цялото влизане в контейнера за маршрутизиране идентифицира възела, за който е бил записът в журнала.

Също така започваме да мислим за провеждането на още няколко quic-p2p тестове, за да получим по-добри данни за неговата мащабируемост и потребности от ресурси. Очакваме той да обработва стотици (или дори хиляди!) връзки наведнъж и е важно да знаем лимитите и да ги планирате съответно, за да сме сигурни, че мрежовите системи няма да бъдат претоварени. Планираме да стартираме тези тестове след новата версия, която ще включва поддръжката на IGD и най-новите подобрения на внедряването на протокола QUIC от Quinn, основната мрежова библиотека, която използваме.

BLS - Разпределено генериране на ключове

Разчитайки на PARSEC, гръбначния стълб на мрежата, за всички видове консенсус може просто натоварим мрежата по начини, които обикновено не виждаме. Например, данните в SAFE мрежата могат да бъдат бързо променящи се и запитването/извличането на такива данни с консенсус от PARSEC ще отнеме известно време, за да бъдат извлечени. Тази продължителност може да е достатъчна, за да се актуализират данните до по-нова версия от изтеглената. Следователно, за да се сведе до минимум натоварването на PARSEC и да се постигне бърз консенсус за операции като запитване на споделени данни, портфейли с множество подписи и др., сме изправени пред изискването да прехвърлим част от консенсуса върху друг механизъм. Тук идва BLS-разпределеното генериране на ключове, криптографска схема за подписване, която позволява на субектите бързо да постигнат консенсус по даден обект чрез естеството на шестте му фази и принуждават 100% участие от съответните възли. Можете да прочетете повече за работата му и подробности тук и тук. Реализацията на доказателство на концепцията е в процес на работа от екипа, като първоначално ще тестваме със споделени данни от клиенти, въпреки че по-голямата цел е да го използваме за случаи като споменатите по-горе и ще бъде общ контейнер, който ще се използва за постигане на консенсус, без да се разчита напълно на PARSEC през цялото време.

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

SAFE Network новини - 26.3.2020

Накратко

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

  • Пуснахме версия 3 на Бейби Флеминг :tada: Тази актуализация се състои от нова версия на safe_vault (v0.23.0), която използва новата версия на quic-p2p, актуализирана, за да използва последната версия на библиотеката Quinn.
  • Пуснахме нови версии на SAFE CLI (v0.11.0) и процеса на Удостоверителя (v0.0.7), които са съвместими с новия safe_vault (v0.23.0) и използваме нови версии на SAFE Клиентските библиотеки, които повтарят процеса на зареждане няколко пъти преди да върнат грешка.
  • @jimcollinson публикува кандидат-дизайни за някои от ключовите потребителски истории, свързани с разрешенията за файлове, навигация на данни и публикуване. Вижте секцията SAFE Network програма UX по-долу.

Бележка от MaidSafe фондацията за актуалната пандемия Covid-19

Фондация MaidSafe - която е регистрирана шотландска благотворителна организация - подкрепя преподаването на науката, технологиите, инженерството и математиката (STEM), както и на изкуството.

Пандемията Covid-19 закрива училища в много части на света и може би се притеснявате дали държите децата си заети и образовани. За да ви помогнем, сме събрали няколко забавни дейности, които са съставени с помощта на STEM указания за преподаване тук, във Великобритания. Дейностите обхващат три възрастови групи с по два проекта за всяка. Като ориентир дейностите на ранното ниво са за деца от 3 до 5 години, първото ниво за деца от 6 до 8 години и второ ниво от 9 до 11 години.

За да получите безплатни материали, просто изпратете имейл на info@maidsafe.foundation и ние ще ви ги изпратим. Вашият имейл адрес няма да бъде споделен с трета страна и ще бъде изтрит, след като ви изпратим информацията.

Също така качваме снимки, видеоклипове и връзки към забавни дейности във Facebook.

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

Искаме да ви помогнем да запазите и възпитавате детето / децата си през това време на несигурност, така че, моля, пазете се и се надяваме всички да се радвате на дейностите.

Искрено Ваши,

Екипът на MaidSafe

Ако искате да дарите на MaidSafe Foundation, моля, следвайте линка по-долу или използвайте QR кода за достъп до нашия PayPal акаунт. Всички дарения ни помагат да подкрепяме образователни проекти в училищата и общностите.

PayPal

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

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

Днес пускаме третата версия на Бейби Флеминг, известна още като Трезори Фаза 2a :tada:. Актуализирахме quic-p2p, за да използва най-новата версия на библиотеката Quinn и актуализирахме всичките ни контейнери, за да използват новата версия на quic-p2p. Заедно с тази актуализация правим някои сравнителни тестове на CLI командите срещу Бейби Флеминг. Забелязахме, че има някои проблеми в моменти, когато Клиентът (CLI в този случай) не е в състояние да стартира мрежата. Това може да възникне по редица причини, като загуба на пакети, прекъсната мрежова връзка и др. Връщането на грешка веднага щом това се случи, няма смисъл, така че внедрихме малка функция в библиотеките на SAFE Клиента, която стартира процеса на зареждане няколко пъти, преди да върне грешка. Като имаме това място, успяхме да сравним CLI командите срещу Бейби Флеминг в 1000+ повторения. Пуснахме нови версии на Трезора и CLI, моля тествайте ги и пишете за ако намерите грешки.

Как да обновите до Бейби Флеминг версия 3?

Тази актуализация се състои от нова версия на safe_vault (v0.23.0), както и нови версии на SAFE CLI (v0.11.0) и процеса на Удостоверителя (v0.0.7).

Ако никога преди не сте използвали CLI, можете да следвате ръководството тук, за да изтеглите и стартирате нашия скрипт за инсталиране.

Ако сте използвали CLI преди, тогава трябва да го актуализирате, като стартирате:

$ safe update

След това трябва да актуализирате процеса на Удостоверителя:

$ safe auth update

Най-простият начин за актуализиране / инсталиране на новата версия на safe_vault е да стартирате:

$ safe vault install

Всички версии вече трябва да са актуални и можете да стартирате своя собствена Бейби Флеминг мрежа. Вижте CLI ръководството за пълни инструкции.

Известен проблем

При качване на данни може да срещнете периодични грешки в AccessDenied, описани тук. Наясно с това и разследваме.

Кога MaidSafe ще пусне споделена Секция?

Вътрешното ни тестване на споделената Секция е обещаващо, но има някои проблеми, които бихме искали да коригираме, преди да пренесем това бебе на следващото ниво. Може да очаквате да чуете от нас за това скоро.

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

SAFE API

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

Коригирахме няколко незначителни проблема в safe-cli, причинени от скорошното ни преминаване към async, което въведе някои конфликти в контейнера за самообновяване и свързаните с него команди. Друг малък проблем, който решихме, се отразяваше на safe-nodejs API-то: в неуспех за стартиране на safe-authd. Пуснахме нова версия на този пакет (v0.10.0), което ще ни позволи да имаме нови версии на браузъра и SAFE Network програмата, надяваме се скоро.

Направен е и незначителен рефактор в тестовете на safe-api , което ги прави по-изчистени, като избягват използването на unwrap и вместо тях връщат грешки. Всичко това е благодарение на нова функция на Rust, която позволява тестовете да връщат Result.

Safe-api хранилището също беше адаптирано, за да се актуализира до най-новата версия на quinn (v0.6.0), което донесе някои проблеми в неговото API, но и някои опростявания, от които искахме да се възползваме.

Днес пуснахме нови версии на safe-cli (v0.11.0) и safe-authd (v0.0.7), които са съвместими с новия safe_vault (v0.23.0) от днес. Моля, уверете се, че сте актуализирали своя CLI и authd, ако планирате да използвате тази нова версия на safe_vault. Не забравяйте, че можете да актуализирате CLI с командата safe update, а също така да актуализирате authd с командата safe auth update. Следвайте инструкциите от Ръководството за потребителя на CLI, ако досега никога не сте инсталирали SAFE CLI и / или процеса за Удостоверяване на вашата система.

Вследствие на откриването на този бъг в safe-nodejs и със силата на Бейби Флеминг, обновявахме Node.js тестовете ни, за да работят с локална мрежа. Това само по себе си също е започна мигриране към GitHub actions хранилище, което трябва да ускори изграждането и тестването.

Успоредно с всичко това, вече започнахме с първия проект за внедряване на API за данни тип Sequence в safe-api, както и върху някои основни CLI команди, които ще позволят на потребителите да създават и мутират съдържание директно в Sequence, напр. safe seq put и safe seq append команди. Това е в много ранен етап и все още нямаме какво да споделим, това са първите ни стъпки към внедряването на последователността като тип данни от CRDT направо в нашата кодова база на Бейби Флеминг. За това се фокусираме в подхода на E2E, т.е. планираме да използваме CLI и неговите интеграционни тестове, за да валидираме прилагането на Sequence CRDT реализация в трезора. Надяваме се, че ще имаме още за споделяне след няколко дни, когато напреднем.

И накрая, правим обновление и вътре в SAFE Клиентските библиотеки, като тази седмица обединихме двойка PR-и, премахвайки части от старата функционалност на FFI, която беше силно преплетена в кодовата база, в полза на по-ясното разделяне на проблемите в самото safe-api, това ни даде код, който е малко по-чист и по-достъпен.

SAFE Network програма - UX

MVE проследяване на напредъка на функциите

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

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

И така, ето някои от основните потребителски истории, които си проправят пътя към вас. Кликнете на тях или ги изтеглете, за да ги разгледате в пълен размер:

Съгласие точно навреме

10419824260748ec8381372736a923089adb951c_2_690x265

Промяна на заявка за съгласие точно на време

fd47c4b9987cb45a943ff17ea6148c9b0e229102_2_690x232

Качване на файл

381cfd2c718308143f8c3aaa4130ab848784ff78_2_690x240

Създаване на нова папка

59474ef4018c0a5b9d2cecb4223f6513cd597014_2_690x345

Промяна на името на файл или папка

a943a03fad660e1a9afb6c81d77c08accaebcb9b_2_690x345

Местене на файлове или папки

491c59481e4f208e780bbdf5f01baac4eef428b9_2_690x250

Преместване на файл в публична папка

77def8bd23acc39d56b85e1e81a31a7dcac1eee9_2_690x210

Публикуване: уникален линк

4c38939173f7ad1b1e8ce8ff0c1e0fe440ab9905_2_690x245

Публикуване: добавяне към съществуващ сайт

ca2bfe2c1e19cca6309cfd8afbfac77b0f09d823_2_690x291

И това е за сега. Както обикновено, ние ще се радваме да чуем мислите, коментарите и неоправдано острите ви критики. :smile:

SAFE Network програма - разработка (декстоп)

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

С оправянето на safe-nodejs API-то навлизаме в процес на финализиране на отдавна разработван PR за SAFE Network програмата, който е пълен с незначителни промени и актуализирани API-та. Той също така включва преминаване към GitHub Actions за тестване и изграждане на кодовата база. Има някои проблеми с конфигурация там, но сме много близо да оправим и това, за да пуснем SAFE Network програмата, съвместима с Бейби Флеминг!

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

Удостоверител - план на проекта, Браузър - план на проекта

Работим върху няколко малки подобрения и корекции на грешки и в двете приложения. Разгледахме грешка в Удостоверителя, която караше приложението да се стартира отново, вместо да се възобнови при удостоверяване на приложение. Намерихме просто решение за грешката, което ще внедрим и тестваме.

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

Не удостоверен

025428a829f662e5894330874d7e4550b769742b_2_690x79

Удостоверен

2725f7e1baf0082777bf9965a5524dcf5d69f5b3_2_690x74

SAFE App C#

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

Тази седмица изложихме ново FilesContainerRemovePath API от safe-api. Тови API ще позволи на разработчиците да премахнат файл / път от съществуващ контейнер за файлове, използвайки XORURL адреса на файла. Добавихме и някои тестове, за да гарантираме правилното функциониране на това API.

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

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

Тази седмица приключихме с голяма задача за обновяване (разделена на няколко PR-а: #2071, #2072, #2073 и #2075). Това е „невидима“ работа в смисъл, че не са внедрени нови функции, но все пак беше важно да се направи. Премахнахме доста несъществени усложнения и технически дълг, който се натрупа с времето. Това доведе до по-опростен код, което е добре, тъй като по-простият код е: по-лесен за тестване, по-лесен за отстраняване на грешки, по-лесен за одит за уязвимости в сигурността и накрая с него по-лесно се включват нови разработчици.

Продължаваме и с усилията си да подобрим тестовия пакет с цел да ни направи по-уверени в кода. Обмислихме някои идеи и сме в процес на изготвяне на доказателства за реализация.

BLS - Разпределено генериране на ключове

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

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

SAFE Network новини - 2.4.2020

Накратко

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

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

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

Тази седмица осъществихме последната стъпка от Фаза 2а, а именно споделена Секция, разположена върху компютри в DigitalOcean. Тази секция се състои от 8 трезора (7 старейшини и 1 възрастен), всеки от които се намира на отделен компютър, които работят заедно, използвайки Маршрутизирането и комуникират с помощта на quic-p2p, за да обработват и отговарят на заявки, изпратени от браузъра или CLI-то чрез SAFE Клиентските библиотеки. Това е нова версия на различните компоненти, които работят заедно, така че ако все още не сте я изпробвали, преминете към този пост във форума и я тествайте.

Вече започнахме да разглеждаме следващата фаза на Флеминг, Фаза 2б - множество секции. Разглеждаме изискванията на тази фаза и планираме стъпките напред. Следете тук за повече информация.

SAFE API

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

safe-nodejs получи някои актуализации тази седмица. Не на последно място актуализация на най-новата версия на Safe-api 0.11.0, която осигурява съвместимост с най-новите тестови мрежи на Бейби Флеминг (това е включено в най-новите алфа версии на браузъра / safe network програмата, въпреки че все още се борим с някои проблеми с подписването на код там).

Също така настроихме хранилището да работи за непрекъсната доставка. Това не е най-вълнуващото нещо в света, но то премахва няколко ръчни / трудоемки и потенциално податливи на грешки стъпки, които трябваше да правим ръчно. Така че сега всичко, което обединим в master хранилището ще генерира собствени промени / тагове за промени и автоматично ще променя версията в зависимост от това кои добавки (функции, нарушаване на промените или корекции на грешки) са включени в най-новия PR. Изглежда, че този подход е работи добре до тук, затова в момента го разгръщаме и в някои от другите ни хранилища.

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

SAFE Network програма (десктоп)

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

Най-накрая SAFE Network програмата получава дългоочаквана актуализация, като тази седмица излиза новата съвместима с Бейби Флеминг алфа версия. Освен настройването на някои CI подобрения за активиране на автоматичните обновления, SAFE Network програмата вече може да:

  • Управлява / инсталира CLI-то и го използва за инсталиране / управление на safe-authd
  • Спира Safe-authd при изключване само ако е отговорна за стартирането му
  • Автофокусира при получаване на заявки за удостоверяване

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

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

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

Десктоп браузърът също получи някои CI подобрения за непрекъсната доставка. Отвъд това, най-новата версия е с актуализирани SAFE API-та и внедрява корекция за сигурност, което позволява contextIsolatio за елементите на уеб преглед в Electron. Това трябва да предотврати някои експлоатационни мерки в сигурността, свързани с JavaScript веригата прототип.

Тази седмица бяха пуснати нови алфа версии на настолния браузър, които включват тези най-нови актуализации, както и съвместимост със споделената секция на Бейби Флеминг. Можете да изтеглите от GitHub тук. Забележете, както беше споменато по-горе имаше някои проблеми с подписването на кода на браузъра и SAFE Network програмата, работата по отстраняването им продължава, така че моля, игнорирайте всички свързани грешки при инсталирането.

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

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

Днес пуснахме нова версия на SAFE Удостоверителя (v0.3.0). Тази актуализирана версия поддържа мрежата с една Секция (версия 3 на Бейби Флеминг), включително споделената секция, пусната от MaidSafe. Можете да изтеглите новото приложение за удостоверяване чрез QR кодовете или връзките, достъпни тук.

Добавихме опция за изтегляне на информация за връзката със споделената Секция на MaidSafe и я зададохме по подразбиране на страницата с Избор на настройки за Трезор. Това опростява процеса за свързване на тези, които искат да използват споделената секция на MaidSafe и избягва необходимостта от ръчна настройка.

Сваляне на настройките за споделената секция на MaidSafe Автоматично добавяне на споделената секция на MaidSafe

Обърнете внимание, че връзката за изтегляне за споделената секция на MaidSafe ще се появи на екрана “Избиране на Трезор”, само ако нямате изброени конфигурационни файлове.

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

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

Днес пуснахме и нова версия на SAFE мобилния браузър (v0.4.0), също съвместима с мрежата с една секция(версия 3 на Бейби Флеминг), включително хостваната от MaidSafe споделена секция. За да изтеглите и започнете да използвате актуализирания мобилен браузър, можете да намерите QR код и връзките за директно изтегляне тук.

За да опростим процеса на удостоверяване, добавихме опция да се свържете и удостоверите с MaidSafe хостваната споделена секция, без да използвате Удостоверителя. За да използвате всяка друга секция, локална или хоствана от някой друг, трябва да използвате Удостоверителя.

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

Обновяване на диалога за удостоверяване Състояние на удостоверяването и бутон за удостоверяване

SAFE App C#

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

Тази седмица реконструирахме вътрешната структура на проекта и опростихме връзките въз основа на последните промени в преработката на FFI в safe_client_libs / safe_app, safe_client_libs / safe_authenticator_ffi и safe-api / safe-ffi библиотеките. Тествахме промените и пуснахме стабилен MaidSafe.SafeApp NuGet пакет, съвместим с мрежата с една секция.

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

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

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

BLS - Разпределено генериране на ключове

Продължаваме с напредъка, споменат миналата седмица, по работата на PoC за прилагането на DKG схемата. Добавихме тестовете за threshold_signature и threshold_encrypt - тези два теста служат също като примери за демонстриране на това как може да се използва основния контейнер. Ще добавяме още тестове, за да разширим обхвата и да демонстрираме повече случаи на използване. От страна на свързаността на нещата, трезорът, използващ този контейнер, трябва да е запознат с фазите на DKG, през които ще премине, следователно това изисква подобен модел на изпълнение като този на архитектурата ни в SAFE Клиентските библиотеки (където свързаността се управлява от States). Тази яснота ни проправи няколко маршрута, които екипът може да предприеме, за да постигне свързаност и смятаме да тестваме този модел през следващата седмица, за да видим дали това ще бъде ефикасен начин за структуриране на контейнера.

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

SAFE Network новини - 9.4.2020

Накратко

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

  • Завършихме преструктурирането в authd (процесът на Удостоверителя), което носи възможност за стартирането му под Windows без администраторски разрешения (започвайки от следващата версия).
  • Командата safe files е завършена и трябва да бъде включена в следващата версия на SAFE CLI.
  • @jimcollinson публикува още няколко примерни дизайна, свързани с SAFE Network App UX (вижте по-долу).
  • Планирането продължава за Трезори Фаза 2b - многосекционна мрежа.

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

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

Надяваме се, че сте се забавлявали с последната версия на тест мрежата. Правим интересни проучвания за някои подобрения в текущата фаза на мрежата с една секция. Успоредно с това планираме и следващата фаза с множество секции. Добавихме няколко страници към плана на проекта. След още малко обмисляне ще ги преобразуваме в задачи с много повече подробности и тогава е време за спринт програмиране!

SAFE API

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

През изминалата седмица успяхме да завършим преструктурирането в authd, което променя начина, по който процесът се стартира в системата ви. Това преструктуриране ни позволи да се отървем от две зависимости, които използвахме за тази цел (съответно за Windows и Linux / macOS), и вече имаме един и същ код за всички платформи, тъй като процесът се стартира с помощта на основните Rust помощни програми. С тази промяна също успяхме да поправим проблема, който имахме под Windows, където authd регистрационните файлове не се генерираха на аналогично място, както се прави за Linux и macOS (~ / .safe / authd / logs / safe-authd.log), т.е. authd на Windows ще запише своите регистрационни файлове на C: \ Users \ \ .safe \ authd \ logs \ safe-authd.log в следващата версия.

Друго интересно подобрение, което това преструктуриране донесе в authd, е възможността да стартирате authd под Windows без администраторски права. Това изискване се дължеше на инсталирането на authd и стартирането му като Windows услуга, но сега ще бъде стартирано като прост процес във фонов режим, точно както се прави под Linux и macOS. Следователно, от следващата версия няма да е необходимо да го инсталирате с администраторски разрешения под Windows, а ще може да се стартира с обикновена команда safe auth start, пак да повторим без администраторски разрешения.

Също така направихме някои малки поправки в CLI-то, включително промяна, за да увеличим прозореца на изчакване в комуникацията между CLI и authd, така че времето на CLI-то да не изтича преди това на authd, когато има проблеми със свързването към мрежата. По този начин ще можем да видим грешка във времето за изчакване, идваща от authd, а не от CLI. Също така подобрихме CLI-то, така че да не се изключва, когато идентификационните данни са невалидни, а вместо това да се връща към свързване с достъп само за четене, което може да е достатъчно добро за някои команди като cat/dog за публично съдържание.

И накрая, работата по safe files get напредва, което ще позволи изтеглянето на файлове и директории от SAFE Network FileContainer в локалната файлова система. Тази команда работи подобно на cp или scp в Linux / macOS или копиране в Windows. Кодът вече е завършен и се тества от екипа. Той трябва да бъде включен в следващата версия на SAFE CLI.

SAFE Network програма - UX

MVE проследяване на напредъка на функциите

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

Кликнете върху тях или ги изтеглете, за да ги разгледате в пълен размер:

Бюлетин с информация за достъпа до данни

272b655cc48765d302ff8348eb1875aa81c4d82c_2_439x500

Множество данни в една заявка за достъп

62512b55582e2f2d099094c0b338ace711e45149_2_690x384

Списъци за филтриране и сортиране

ed07934bb0261a6d67e113a8b31a80d6d44e6fb6_2_348x500

SAFE Network програма (десктоп)

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

Работата по SAFE Network програмата до голяма степен беше задържана тази седмица, тъй като @joshuef се гмурна в клиентските библиотеки, за да разгледа някои концептуални работи на CRDT. Това само по себе си включва малко преправяне на нашия код за управление на връзката, за да се даде възможност за по-лесно тестване на обработката на отговорите. След като направихме това, получихме прост набор от GSet тестове и можем да видим, че получаването / обединяването на някои различни CRDT типове данни не би трябвало да доведе до прекалено много проблеми за клиента. Още веднъж това е само бързо доказателство за концепцията, но изглежда обещаващо засега.

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

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

Удостоверител план, браузър план

Направихме няколко текстови промени в приложението за удостоверяване, основно фокусирани върху страницата за избор на мрежа. От страна на мобилния браузър забелязахме, че някои от уебсайтовете / страниците не се зареждат правилно под iOS, докато работят добре на устройства с Android. Започнахме работа по намирането на първопричината зад този проблем, за да може той да бъде разрешен.

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

SAFE App C#

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

Поправихме доста стар проблем в библиотеката safe_app_csharp. Проблемът водеше до срив на приложението при опит за декодиране на всеки отговор за удостоверяване от приложението за Удостоверителя (мобилния или CLI-то). Поради този проблем не беше възможно да се справяме с различни случаи на грешки. Актуализирахме и тестовете, за да гарантираме правилното функциониране на поправенето API на всички настолни и мобилни платформи.

Премахнахме тестовата настройка на AppVeyor от хранилището и за да опростим допълнително процеса, и използването на единна платформа за целия процес на CI / CD, преместваме кодовото отразяване и настройката за публикуване на API документацията в Azure DevOps.

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

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

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

BLS - Разпределено генериране на ключове

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

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

SAFE Network новини - 16.4.2020

Накратко

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

  • Пуснахме нови версии на SAFE CLI (v0.12.0) и процеса на Удостоверителя (v0.0.8). CLI вече включва подкоманда files get и процесът на Удостоверителя вече не изисква администраторски разрешения под Windows.
  • Пуснахме нова алфа версия на SAFE Network програмата.
  • Пуснахме версия 0.5.0 на SAFE мобилния браузър, която включва необходимите промени за предоставяне на функцията за актуализиране вътре в приложението.
  • Наскоро създадохме общо ръководство за допринасяне към проекта, към което пускаме връзка във файла README.md във всяко хранилище.

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

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

Вече започнахме разработването на следващата фаза на Бейби Флеминг - Трезори Фаза 2б, многосекционна мрежа. Имаме няколко задачи, подредени в плана на проекта и първата заявка за обновление вече е подготвена! Този PR реализира поведението на нови Трезори, присъединяващи се към секцията като Възрастни, които по-късно се повишават към Старейшини, ако се налага. Следващата стъпка е да зададем на възрастните да държат парчета ImmutableData. Започнахме работа и по това. Очакват ни вълнуващи времена напред!

SAFE API

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

По-рано тази седмица пуснахме нови версии на SAFE CLI (v0.12.0) и процеса на Удостоверителя (v0.0.8), които носят няколко подобрения в програмния код, някои корекции на грешки, които наскоро бяха докладвани от общността при тестовете на Бейби Флеминг, както и някои нови функции като възможността за изтегляне на файлове от мрежата локално с въвеждането на подкомандата files get.

Едно важно подобрение, направено в тази нова версия на safe-authd, е, че тя не изисква администраторски разрешения за нейното стартиране в Windows, нито има нужда от инсталиране като Windows услуга, преди да може да бъде стартирана като процес. Сега safe-authd може да бъде стартиран с една команда safe auth start чрез CLI-то под Windows, точно както се прави и на другите платформи.

Както винаги, можете да актуализирате CLI-то си с командата safe update и safe-authd с командата safe auth update. Само една забележка за потребителите на Windows: преди да актуализирате и стартирате новата версия на safe-authd, моля, деинсталирайте първо Windows Service на старата версия на safe-authd, като използвате стария safe-cli (т.е. версия <= v0.11.0). Това може да се направи с администраторски разрешения под Windows и командата safe auth stop последвана от командата safe auth uninstall.

CRDT

Започнахме да разглеждаме CRDT за управление на нашите базови типове данни, за да избегнем необходимостта от строго подреден консенсус тук. Това изглежда много обещаващо за нашите основни типове данни и ще се стремим да подобрим типовете данни MutableData и AppendOnlyData, като същевременно поддържаме API-тата възможно най-сходни.

Ползата от това ще бъде много по-голяма пропускливост при добавяне на данни към или промяна на данни в мрежата, тъй като това се оказва едно от слабите места на Бейби Флеминг.

Като първа стъпка в опита ни да пуснем първия CRDT тип данни, започнахме работа по PoC внедряване на CRDT последователност въз основа на предложената LSeq CRDT. Започнахме с това през последните няколко дни и се опитваме да пуснем първата основна реализация, която може да бъде тествана, за да потвърди, че може да работи в мрежата, където всяка CRDT реплика се държи от всеки Старейшина в секцията. Все още сме в ранните етапи на това, така че остава да потвърдим, че този CRDT ще покрие всичките ни нужди, както първоначално смятахме. След като получим добри резултати, ще започнем с интегрирането му във всички слоеве от трезорите, през API-тата и CLI-то.

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

SAFE Network програма (десктоп)

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

Както обещахме, веднага след новините миналата седмица пуснахме нова алфа версия на SAFE Network програмата. Вижте тази публикация за повече информация относно промените.

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

Удостоверител план, браузър план

Тази седмица работихме върху малка, но вълнуваща функция. Нашата цел беше да подобрим настройката на CI / CD и да интегрираме мобилните приложения с SDK-то на AppCenter за разпространение. Казано по-просто, нашата цел е, ако вече имате инсталирано SAFE мобилно приложение на вашето устройство с тези нови промени и се пусне нова версия на приложението, приложението ще ви подкани автоматично да го актуализирате до най-новата версия. Няма да се налага повече да го изтегляте ръчно от GitHub или AppCenter. Тази седмица успешно тествахме PoC за различни случаи на използване и така внедрихме тази нова функция в мобилния браузър.

Днес пуснахме версия 0.5.0 от мобилния браузър!

Можете да изтеглите тази нова версия, като използвате връзките за изтегляне / QR код от файла README. Последната версия включва необходимите промени за предоставяне на функцията за актуализиране на приложението - след като ръчно сте инсталирали / актуализирали браузъра до версия 0.5.0, всички бъдещи актуализации могат да бъдат обработвани в приложението.

Някои потребители може да предпочитат да продължат да актуализират ръчно - ако искате може да изключите автоматичната актуализация от страницата с настройки на браузъра.

Следващите ни стъпки ще бъдат да обновим мобилния браузър от версия 0.5.0 до 0.5.1. Възнамеряваме да пуснем тази нова версия следващата седмица. Това ще даде на нас и на вас шанс да изпробваме тази функция за автоматично актуализиране на различни устройства. Все още има някои пояснения, които трябва да направим около това как работят по-специално актуализациите под iOS: вярваме, че потребителите на iOS може да се наложи да влязат в AppCenter, за да работи автоматичното актуализиране. Колко удобно ще бъде това в сравнение с текущия процес е нещо, което ще оценим с ваша помощ. Ако всичко върви добре, тогава ще добавим тази функция към мобилното приложение за удостоверяване.

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

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

След като миналата седмица спряхме да проучваме алгоритъма AT2 (повече подробности в CRDT раздела в тези новини), тази седмица се върнахме към работата по правилното маршрутизиране. Няколко пъти споменахме в миналото, че искаме да подобрим тестовия пакет. Тази седмица най-накрая направихме първата стъпка към това. Премахнахме някои нереалистични предположения за синхронност и приближихме тестовете до реалността. Работата все още не е обединена, но вече се оказа полезна: с нея открихме две грешки, които се промъкнаха през стария тестов пакет. И двете е малко вероятно да се появят в реалния свят, но е най-добре да се покрият дори такива крайни случаи. И двете грешки бяха поправени в един и същ PR, който в момента се преглежда и очакваме скоро да бъде обединен.

BLS - Разпределено генериране на ключове

Като първата голяма стъпка към постигането на работещ DKG контейнер, тази седмица PoC PR беше обединен. Този PR включва някои тестове, които също служат като примери за използване. PR-и с допълнителни тестови сценарии са в процес на разработване тук и тук, проектирани са да гарантират, че контейнера работи както се очаква. Работим и върху някои API актуализации, за да позволим на други контейнери лесно да използват DKG. Успоредно с тях, проучваме използването на инструмент за симулация на Маршрутизирането, подобен на този тук, който използвахме преди. Целта ни с това е да се провери използваемостта на контейнера DKG в рамките на секцията, т.е. да се променя редовно членството.

Софтуерно тестване

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

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

SAFE Network новини - 23.4.2020

Накратко

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

  • Пуснахме нов стабилен NuGet пакет от SAFE C# API.
  • Добавихме нова малка функция в мобилния браузър, която позволява на потребителите да преглеждат файловете от FilesContainer. Това ще бъде достъпно от следващата версия.
  • Работихме по адаптирането на dog командата, за да покажем всяка стъпка във веригата за повече подробности.

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

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

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

SAFE API

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

След последната версия на SAFE CLI v0.12.0 миналата седмица, започнахме да работим върху някои нови функции и подобрения, предложени от общността по dog CLI командата. Понастоящем показва информация за това как е насочен URL адрес за намиране на целевото съдържание, но когато тази подробност означава повече от една индирекция, тя не показва всяка стъпка в такава верига за повече подробности. По този начин сега се опитваме да се уверим, че тя показва цялата верига подробно, така че потребителят да разбере напълно какво съдържание е насочено от URL адрес и как.

Някои други незначителни допълнения се правят в API-тата за анализиране на SAFE-URL адреси, като например разбор и възможност за манипулиране на параметрите на заявките и / или фрагмента. Те не се използват от никоя от функциите, които в момента излагаме в CLI-то, но това е нещо, което ще бъде полезно за разработчиците на приложения при работа с SAFE-URL адреси.

CRDT

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

Напредваме и с AT2 внедряването на safecoin, което включва голямо преструктуриране на SAFE Клиентските библиотеки, за да раздели нещата и да улесни разбирането. С приключването на това ще имаме преобразуване до основната настройка за AT2 (без никакво потвърждение и т.н. … т.е. основно преобразуване на това, което бяхме подготвили за следващата стъпка). Това работи добре и ни поставя в добро положение.

Успоредно с това работихме върху създаването на нови тестове и „хаос“, при което можем по-сигурно да потвърдим, че нашата реализация на AT2 работи както се очаква, след като настроим стъпките на консенсус. Това трябва да включва симулиране на отпаднали съобщения, за да се гарантира, че все още се постигаме консенсус или клиентите / трезорите действат злонамерено, така че да може да потвърдим, че подобно поведение ще бъде отхвърлено, както се очаква.

Освен всичко това започнахме и някои модернизации на внедряването на фючърсите на SCL Rust, за да направим различните аспекти по-прости. Това само по себе си е доста голяма задача. Но досега я отлагахме, така че е добре да я започнем.

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

Браузър план, Удостоверител план

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

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

Добавихме нова малка функция в мобилния браузър, която позволява на потребителите да преглеждат файловете от FilesContainer. Използвайки това, потребителите вече могат да разглеждат всеки FilesContainer, чрез неговия XOR-URL / NRS-URL адрес и могат да преглеждат файловете от списък.

Ще продължим да добавяме повече корекции и функции, преди да пуснем нова версия на приложенията.

Направихме актуализация и добавки към страницата с въпроси за Удостоверителя във форума, заедно с поправянето на стар линк в README.

SAFE App C#

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

Тази седмица пуснахме нов стабилен NuGet пакет. Обновеният пакет съдържа корекцията за декодиране на удостоверяващото API. Също така актуализирахме API-тата за XorUrlEncoder, за да поддържаме под-имена. Преди това в API-тата на C# не беше възможно да се генерира XOR-URL с под имена; с последните промени сега можете да предоставите под имена, за да генерирате нов XOR-URL адрес. Също така актуализирахме API-тата за XorUrlEncoder, за да използваме C# списък от низове, вместо да използваме JSON низове при генериране на XorUrlEncoder от XOR-URL.

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

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

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

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

BLS - Разпределено генериране на ключове

Добавихме още тестови сценарии към DKG контейнера. Работата по преструктурирането продължава тук, за да го подобри допълнително. Използваме и BLS-DKG, за да напишем инструмент за симулация на маршрутизацията, който да ни помогне да проучим и интегрираме този контейнер с модула за маршрутизиране. Това ще бъде използвано заедно с Parsec, което прави процеса на консенсус на мрежата много по-лек. Първоначалната настройка би била да се симулира новообразуваща се секция от старейшини, да се симулира откъсване чрез добавяне на старейшини по време на DKG сесията и тест, за да се види как работи секцията при постигане на консенсус. Това също би ни помогнало да проверим използваемостта на контейнера в секция, каквато би била в реалния свят.

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

SAFE Network новини - 30.4.2020

Накратко

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

  • Днес пуснахме версия 0.5.1 на мобилния браузър и версия 0.3.1 на мобилния Удостоверител
  • Първоначалното изпълнение на Трезори Фаза 2б Възрастни и тяхното поведение по време на обработка на заявки за непроменими данни (Immutable Data) е завършено.
  • Завършихме първия тип данни PoC Sequence, реализирани като CRDT и можем да започнем да ги интегрираме в стека на библиотеките.
  • Вече имаме тестова версия на AT2, която работи добре с CLI-то.
  • В момента се преглежда PR за добавяне на UPnP към quic-p2p - това приближава свързването на трезорите от вкъщи в една секция.
  • @jimcollinson започна да работи върху усъвършенстването на кандидатските дизайни, които споделихме преди време (вижте секцията SAFE Network App UX).

Накратко отбелязваме, че Никита приключи договора си с MaidSafe тази седмица, като последният му принос беше представянето на този PRnP PR в quic-p2p (обсъдено по-подробно в секцията quic-p2p по-долу). Никита работи за MaidSafe в продължение на 4 години и съм сигурен, че ще се съгласите, че имаше огромен принос за нашия проект през това време. Миналата година Никита премина на непълно работно време, за да може да отдели време за собствените си проекти и сега настъпи момента да им се отдаде напълно. Знаем, че той няма да иска да бъде споменат по този начин, но моля, присъединете се към нас, като благодарим на @nbaksalyar за приноса му през годините и му пожелаем големи успехи в бъдеще.

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

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

През изминалата седмица продължихме с напредъка към следващата ни фаза. Завършихме първоначалната реализация на Възрастни и тяхното поведение, докато обработват заявки за непроменими данни. Следващата стъпка е да проектираме и внедрим начина, по който секцията се държи по време на разделяне на секции.

Към работата по развитието на трезорите се включиха няколко допълнителни чифра ръце. @ravinderjangra се присъедини към нас, за да помогне за проектирането и прилагането на различни функции, необходими за следващата фаза. @oetyng също помага, започвайки с преструктуриране на клиентския манипулатор, който днес е обединен. Развълнувани сме за предстоящите дни и се надяваме и вие да сте.

SAFE API

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

Извършва се преструктуриране в safe-api хранилището, по-специално в API-то на XorUrlEncoder, който се използва за управление на SAFE-URL адреси. Към него добавяме още няколко функции, така че да може да се използва от всеки разработчик за справяне със SAFE-URL адреси, т.е. както NRS-URL, така и XOR-URL адреси, за да анализира, манипулира и също така да генерира съответните XOR-URL адреси, ако е необходимо. Това не засяга нито една от функционалностите, изложени от CLI-то, а само това специфично API.

CRDT

Както споменахме през последните няколко седмици се опитвахме да получим първи тип данни PoC Sequence, реализиран като CRDT и сега изглежда имаме нещо функционално и достатъчно добро, за да започнем да го интегрираме в библиотечния стек. Ето защо започнахме да работим върху изпълненията, необходими за разкриване на такъв тип последователност от данни в нашите основни библиотеки, като се започне от safe-nd и safe-treult. Планираме да добавим поддръжка за този нов тип данни в пълния стек, без да премахваме или променяме някой от текущите типове данни или поддържани операции, но вместо това първо да го добавим като допълнителен тип данни, който можем да използваме, за да започнем валидиране и тестване на e2e в мрежова среда с една секция.

След като този нов тип данни бъде напълно интегриран и утвърден, ще започнем да мигрираме всички наши клиентски API-та, които използват AppendOnlyData, за да започнат да използват Sequence типа данни. Например в момента FilesContainers и NRS Containers се съхраняват като AppendOnlyData и те ще бъдат мигрирани, за да се използва Sequence тип данни. Това няма да повлияе на излагането на API-то, нито на CLI командите, а само на това как се съхранява това съдържание в мрежата.

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

В момента първоначалната ни реализация на AT2 изглежда като солиден заместител на текущата реализация на safecoin. Имаме тестова версия, която работи добре с CLI-то и сега работим около крайните случаи в самите SCL тестове, за да гарантираме, че всичко е стабилно. Оттам ще разгледаме следващите стъпки за AT2, които ще включват съобщения между трезорите, за да се гарантира, че всички актуализации се предават, което ще гарантира и защита срещу двойно харчене.

SAFE Network програма - UX

MVE проследяване на напредъка на функциите

Ако сте преглеждали MVE проследяването на напредъка на функциите на SAFE Network програмата, ще забележите доста отметната работа в реда Жизненоважни функции. Това разбира се е добра новина, но също така означава, че трябва да започнем да дърпаме това кученце заедно.

Досега го проектирахме и изграждахме около някои доста общи компоненти, върху основата на Material Design системата. Това беше прагматичният избор, който ни позволи сравнително бързо да изградим мултиплатформно приложение, което е използваемо, познато и без прекалено големи разходи за поддръжка.

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

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

И така, ето някои от грубите критерии, към които се целим, когато работим върху горните слоеве на потребителския интерфейс, за да се почувстваме удовлетворени:

  1. Дизайните трябва да дават предимство на използваемостта и функционалността преди всичко друго.
  2. Те трябва да работят добре на различните платформи, използвайки основни елементи на операционните системи, когато става дума за основна използваемост.
  3. Те също трябва да имат познато SAFE усещане, да използват съществуващите активи на марката, да имат достатъчно уникалност за да ориентират потребителите, но не за сметка на 1 и 2.
  4. Трябва да се помисли за адаптиране към многоезичните опции, когато дойде времето.
  5. Разходите за поддръжка трябва да бъдат ниски.
  6. Итеративни, постепенни подобрения, а не големи отскоци.

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

Идеята тук е да вземем някои направления от работата, която свършихме по уебсайта, като същевременно запазим полезността и използваемостта като приоритет. Така че малко по-малко визуална насоченост и малко повече практичност.

Всичко това ще продължи да се развива, седмица след седмица, с напредъка на работата и, разбира се, когато можем да възобновим тестването с потребители.

Функции в Rust

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

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

Браузър план на проекта

Удостоверител план на проекта

Днес пуснахме версия 0.5.1 на мобилния браузър и версия 0.3.1 на мобилния Удостоверител

Ако си спомните в скорошната версия 0.5.0 на мобилния браузър включихме автоматична актуализация за първи път, подробно описана тук. Днешното издание на мобилния браузър версия 0.5.1 ви дава първата възможност да видите този процес на автоматично актуализиране в действие , ако в момента имате инсталирана версия 0.5.0.

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

Ако в момента имате версия на браузър по-стара от 0.5.0 или все още нямате браузъра на устройството си, можете да изтеглите последната версия, като използвате връзките за изтегляне / QR код-а от файла README.

В тази последна версия на браузъра актуализирахме страницата на контейнера с файлове, за да включим връзки към файлове. Потребителят вече може да извлече файловете от контейнера с файлове с помощта на nrs или xorurl. Направихме някои текстови промени в изскачащия диалогов прозорец за удостоверяване, за да направим стъпката за удостоверяване по-ясна. Също така актуализирахме няколко диалога за грешки в приложението, за да бъдем по-прецизни, което би трябвало да улесни потребителите да разбират проблема и да помага с отстраняването му. И накрая, връзката към “Често задавани въпроси” на страницата за настройки на приложението също беше актуализирана до правилната тема на форума.

Наред с браузъра, днес пуснахме и версия 0.3.1 от мобилното приложение за удостоверяване. Имайте предвид, че мобилното приложение за удостоверяване не включва автоматично актуализиране - това приложение се използва като временна мярка за удостоверяване, като средносрочният план е да прехвърли този процес на удостоверяване в SAFE Network програмата, така че не сме изразходвали излишно време за въвеждането на автоматично актуализиране в него.

Удостоверителя версия 0.3.1 включва някои малки актуализации на текста, използван в приложението, за да съответства на браузъра и по-точно за текущия етап на проекта, т.е. сега ние се свързваме със секции, а не с един трезор, както беше във Фаза 2а.

Можете да изтеглите най-новата версия, като използвате връзките за изтегляне / QR код-а от файла README.

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

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

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

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

Както бе споменато в началото на новините, Никита работи усилено, за да завърши внедряването на UPnP в quic-p2p през последните няколко седмици и излезе с този PR, който преминава ревю. UPnP ни предоставя автоматично пренасочване на портове, което означава, че процесът на свързване на трезорите от различни части на света в една секция става много по-опростен и следователно осъществим. След приключване на прегледите, ще започнем вътрешно тестване и ако всичко е добре, ще го представим на общността.

BLS - Разпределено генериране на ключове

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

Тази седмица беше обединен основен преструктуриран PR, който значително подобри BLS-DKG контейнера. Той представя по-прецизен интерфейс за използване и прави реализирания поток от DKG генерирането да следва по-точно DKG документа на протокола. Първоначалната работа по въвеждането на quic-p2p като транспортен слой е в процес на изпълнение. След като това бъде завършено, контейнера ще трябва да бъде тестван усилено, за да се провери как използването на транспортния слой трябва да бъде настроено и конфигурирано по такъв начин, че да поддържа маршрутизиране в симулации от реалния свят. Загубата на връзка към трезори или закъсненията в доставянето на съобщенията поради прекъсвания, са само част от проблемите в мрежата в реалния свят, които трябва да симулираме и да вземем под внимание при проектирането на потока на DKG. В момента пишем такива положителни / отрицателни симулации за път, които да бъдат тествани на DKG сесия, преди да можем уверено да използваме този контейнер в мрежата.

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

SAFE Network новини - 7.5.2020

Накратко

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

  • Изпълнихме първия си вътрешен тест с Трезорите, които работят от вкъщи и се свързват в една секция с добри резултати.
  • RFC-0052 беше актуализиран, за да направи RFC-а и кода съвместими и да направи някои области по-ясни за други изпълнители в бъдеще.
  • Актуализирахме SAFE App C# CI-то, за да публикуваме автоматично документите на API-то в GitHub Pages. Най-новите документи са качени тук.
  • Нашата реализация на AT2 (която изглежда като солиден заместител на текущата реализация на Safecoin) вече има тестове, преминаващи успешно през SAFE Клиентските библиотеки, Трезорите и safe-nd.
  • Актуализирахме safe_core библиотеката, за да използваме функции и асинхронизация/изчакване, и вече сме в процес на работа с SAFE удостоверителя.

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

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

Тази седмица направихме малко отклонение, за да опитаме нещо ново. С добавянето на новите функции в quic-p2p, той вече може да извлича публичния IP адрес на локална мрежа и да препраща определен порт на компютъра към целия Интернет чрез рутера. Сигурен съм, че вече сте се досетили какво се готви. Трезори от вкъщи. Интегрирахме тези нови функции на quic-p2p с SAFE Трезора и с някои малки поправки и преструктуриране стартирахме първия си вътрешен тест днес с Трезори работещи от вкъщи. Видяхме добри резултати и забелязахме, че могат да се направят някои подобрения. Видяхме и някои проблемни точки също, например рутери, които не поддържат IGD, но ей, това се очакваше. Ще работим върху някои подобрения на този фронт през следващата седмица.

Успоредно с това продължихме и с проектирането на многосекционната мрежа. Появиха се няколко интересни идеи, които ще подобрят обработката на данни между Старейшините и Възрастните, и това ще се свърже добре с Трезорите, работещи от вкъщи. Следващата тестова мрежа ще бъде с Трезорите, които работят от вкъщи и тези Трезори ще получат минимални отговорности за обработка на данни, като съхраняване на непроменящи се части от данни. За това е важно да се има предвид, че Трезорите може да се изключват, така че мислим и за начините да се справим с това. Следете случващото се!

SAFE API

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

Тази седмица голямо преструктуриране на XorUrlEncoder беше завършено. XorUrlEncoder е преименуван на SafeUrl, тъй като сега капсулира както URL адреси от типа NRS, така и XOR. Също така, RFC-0052 беше актуализиран за изясняване на някои неясни области, предоставяне на примери и коригиране на номенклатурата, така че кодът и RFC-а да бъдат синхронизирани.

API-то и CLI-то също са актуализирани, за да поддържат рекурсивната разделителна способност на NRS URL адресите за всички операции.

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

SAFE Програма C#

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

Тази седмица поправихме генерирането на документация за API-то и актуализирахме CI-то, за да публикува автоматично актуализираните документи на GitHub Pages. Най-новите документи на API-то са хоствани тук. Актуализирахме файла README, за да посочим най-новите документи.

Въз основа на последните промени в Safe-api, работим върху няколко подобрения и преструктуриране в SafeUrl / XorUrlEncoder API-тата. Промените включват разкриване на повече API-та от safe-api и опростяване на съществуващите API-та за C# разработчици. Ще актуализираме и API-то за проверка за да връща всички предприети стъпки за получаване на някои данни от мрежата.

CRDT

Базовата актуализация на внедряването на AT2 към Safecoin изглежда добре, като тестовете преминават през SAFE Клиентските библиотеки, Трезорите и safe-nd. Сега преминаваме към измислянето на нови API-та, които трябва да дадат възможност на Клиентите да формулират своите транзакции (включително всички необходими зависимости от тази транзакция) и да предадат това на Старейшините за валидиране. След което Клиента получава BLS подпис от всеки старейшина (ако те валидират транзакцията), като това трябва да е всичко, от което клиентът се нуждае за да пусне искане за трансфер.

Тук има някои зависимости по отношение на получаването на ключовете от Секциите, но не очакваме те да блокират напредъка като цяло.

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

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

Функции в Rust

Миналата седмица продължихме с напредъка на SCL, като актуализирахме Само-криптирането. Тази седмица с радост съобщаваме, че добавихме функционалност към библиотеката safe_core, позволяваща използването на асинхронизация/изчакване, и вече работим с safe_authenticator. Това не е бърза работа, нито вълнуваща, но ни дава много по-чист код, както и потенциални ползи от използването на основните Rust функции.

Маршрутизиране

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

Тази седмица пуснахме големо PR преструктуриране, за което споменахме по-рано. В получения по-опростен код някои неефективности и съкращения, които преди това бяха скрити, станаха очевидни и ги премахнахме в последващ PR. Последвахме това с още едно PR преструктуриране, за да опростим кодовата база. Целта беше да се премахне концепцията за версията на Секциите, тя представляваше число, което се увеличава по една при всяка промяна на Старейшините на Секциите. Това число заедно с префикса на раздел служи като уникален идентификатор на Секция в даден момент от време. Но се оказва, че вече имаме такъв идентификатор - ключът на секцията! Така че тази ненужна версия е премахната и кодовата база е малко по-опростена.

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

BLS - Разпределено генериране на ключове

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

Докато се насочваме към завършването на DKG контейнера, го тестваме щателно и изчерпателно, както с транспортния слой, така и без него (тестова мрежа), преди да можем да започнем да го използваме в мрежата на живо. Миналата седмица тествахме процеса с грешки на ниво мрежа като изключващи се трезори, забавяне на съобщенията, разделяне на секции и т.н. В момента преминаваме към следващата стъпка, като добавяме злонамерени Трезори в тестовете и ги караме да изпращат фалшиви стойности по време на сесия. DKG би трябвало да може да се справи с това ефективно, като отстранява тези злонамерени участници, тъй като бихме искали 100% от участниците да не бъдат злонамерени, а отзивчиви по време на сесията.

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

SAFE Network новини - 14.5.2020

Накратко

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

  • След някои подобрения пуснахме още един вътрешен тест-скрипт с Трезори от вкъщи и досега изглежда добре.
  • Пуснахме нова версия на пакета MaidSafe.SafeApp NuGet.
  • Продължихме работата по внедряването и тестването на поддръжката за празни директории, очаквайте PR.
  • Прехвърлихме API-то на FilesContainers и CLI командите да се съхраняват / синхронизират / четат, използвайки Sequence типа данни и всички основни ръчни тестове с локална Секция работят отлично

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

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

Работата по AT2 напредва следвайки точно теоретичната обосновка, както и корекции за специфични SAFE условия. Постигаме добър напредък с прилагането на това както на трезора, така и на клиента. Приближаваме се до етап, в който AT2 е проверен и можем да започнем да изготвяме тестове за него.

След последния вътрешен тест с Трезори от дома, направихме някои подобрения. Основната добавена функция беше премахването на необходимостта от --ip параметъра, който изискваше потребителите да предават локалния си IP адрес при стартиране на Трезор, с цел пренасочване на порт. Премахнахме необходимостта от това, като се свързваме към IGD шлюза и питаме за адреса на локалния сокет. Това в крайна сметка подобрява потребителското изживяване чрез опростяване на процеса на стартиране на трезора, минимизирайки необходимостта от технически подробности. Със завършването на това стартирахме още един тест и досега изглежда добре. Ще продължим да го наблюдаваме през следващите дни и е вероятно да направим допълнителни подобрения и повторения, преди да сме готови да го пуснем публично.

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

SAFE API

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

Продължава работата по внедряване и тестване на поддръжката за празни директории. Това наложи малка промяна в начина на съхранение на данните във FileContainer.

Преди това всеки запис на FileItem във FileContainer представляваше файл с линк, съдържащ SAFE URL адрес, идентифициращ обект на неизменна информация. В предложения нов код, FileItem може да представлява файл, директория или Symlink, идентифициран от типа на атрибута от метаданните. Записите в Directory и Symlink не притежават линк, така че те съществуват само във FileContainer.

Допълнителни метаданни също се създават за всеки файл, ако са локално достъпни: original_create_time, original_modified_time и unix_mode_bits. Целта на тези метаданни е да се даде възможност за архивиране / възстановяване, което запазва метаданните на локалния файл.

Пуснахме малка поправка на files ls, което позволява на ls да връща подробности за единичен файл във FileContainer и също прави съвпадения по компонент на пътя, а не по индивидуален характер.

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

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

SAFE Програма C#

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

Пуснахме нова версия на NuGet пакета MaidSafe.SafeApp. В тази най-нова версия преименувахме XorUrlEncoder на SafeUrl и преструктурирахме съответно API-тата. Добавихме и някои нови API-та, за да генерираме URL адресите за ключове, мутационни данни, приложения и неизменни данни. Поправихме няколко проблема във функциите за обвиване на FFI, които причиняваха сривове и опростихме използването на базовите типове кодиране за URL адресите. Можете да проверите файла с промените за пълния списък с промени.

CRDT

Тази седмица внедрихме, преструкторирахме и опростихме типа данни за последователността (Sequence) и поддържаните заявки в safe-nd, а след това адаптирахме SAFE Клиентските библиотеки и SAFE Трезорите съответно. Също така се опитахме да мигрираме командите на FilesContainers API-то и CLI-то, за да се съхраняват / синхронизират / четат, като се използва последователността като основен тип данни (за разлика от AppendOnlyData) - всички основни ръчни тестове с локална Секция работиха отлично!

По-голямата част от екипа е на ежедневни срещи с нашия изпълнител на CRDT през последните 2 седмици. Те доведоха до дълбоко потапяне в AT2, ORSWOT и обобщена византийска толерантност за всички CRDT в SAFE. Този процес е приет много добре и вероятно ще инвестираме малко повече там, за да имаме одит на нашите конкретни случаи на използване. Това ще помогне за гарантирането на надеждността и коректността на нашите типове данни, както и за обработката на членството в секциите (което ще бъде значително подобрено).

Функции в Rust

Миналата седмица преминахме през огромно количество от промени, необходими за safe_authenticator, макар да попаднахме на някои проблеми, когато се опитваме да актуализираме event_loop кода за safe_authenticator и за safe_core. Това от своя страна ни накара да разгледаме по-отблизо кода тук и се опитваме да решим най-добрия начин да продължим, като изглежда, че ще премахнем този вътрешен event_loop, за да запазим библиотеките ясни и прости, позволявайки библиотеките на по-високо ниво да използват Rust време на изпълнение, както изискват.

Маршрутизиране

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

Тази седмица реализирахме няколко малки подобрения на API-то, които бяха поискани от екипа работещ върху Трезора: Първо добавихме метод за извличане на текущите възрастни от секцията, подредени според XOR-разстоянието към дадено име и добавени събития, които се покачват, когато член се присъедини или напусне секцията. Тази функционалност е необходима за трезорите, за да могат да разпространяват и преразпределят копията на данните между членовете на секцията. След това добавихме getter за текущия дял на секретния ключ за споделяне, като по този начин позволихме на трезорите да участват в схеми за подписване и криптиране - нещо, което досега беше достъпно само за Маршрутизирането, за свои вътрешни нужди.

Все още работим върху модела за изтегляне, както писахме миналата седмица. По-голямата част от новия поток вече е налице, просто трябва да отстраним грешките в някои странни проби на теста и да полираме кода малко, преди да го повишим като PR.

BLS - Разпределено генериране на ключове

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

Миналата седмица тествахме по-дълбоко контейнера с реални мрежови симулации, които въведоха злонамерени сценарии в пакета за тестване. Това разкри няколко грешки, с които трябва да се справим, най-вече по отношение на начина, по който обработваме съобщенията на DKG сред участващите трезори. Те по същество ни показват различни начини за ефективно прилагане на слой със съобщения, за да отговарят на нуждите на мрежа, като например как се опитваме да принудим 100% участие на m от n участници, на практика премахвайки необходимостта от фаза на обосновка в механизма, като се уверим, че всички участващи трезори би трябвало да не са злонамерени, без да оставим място за оплаквания.

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

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

SAFE Network новини - 21.5.2020

Накратко

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

  • quic-p2p v0.6.0, включващ IGD, беше пуснат днес.
  • Новото, все още разработвано, safe-transfers хранилище вече е публично достъпно.
  • Поддръжката за PUT / GET на празни директории е добавена към CLI-то.
  • @jimcollinson представя актуализация за напредъка на UX на SAFE Network програмата.
  • Прогресът на CRDT продължава - вече сме готови да започнем да добавяме действителната CRDT логика към клиента.
  • Обединихме PR на модела за изтегляне в Маршрутизирането, като направихме актуализациите на секциите по-стабилни и ефективни.

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

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

През последната седмица се съсредоточихме основно върху прилагането на начина, по който Трезорите обработват данни, когато Възрастните се присъединят и напуснат мрежата. Това се оформя добре и около 80% от работата е завършена. Има само още няколко неща, които трябва да се разгледат и разбира се много тестове, преди промените да бъдат публикувани. Това ще се впише добре с най-новите промени в quic-p2p, които въвеждат пренасочване на портове с помощта на IGD. Нова версия на quic-p2p беше пусната днес с тези нови функции. Вече приключихме тестовете за интеграция с Маршрутизацията и Трезорите в последните няколко вътрешни тестови мрежи и очакваме следващите тестове, които ще включват и обработката на данните. Очакваме тест с общността, в който тези функции ще са включени, така че се навъртайте наоколо!

SAFE API

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

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

Междувременно понастоящем локално се тества корекция за NRS пътища във files ls (издание 510).

И накрая, направихме малко преструктуриране в интерфейса на чужди функции (FFI), който представя FilesMap като основен тип данни, а не JSON низ.

SAFE Програма C#

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

Както бе споменато в секцията SAFE API по-горе, тази седмица преструктурирахме отново API-та на Files, за да върнем FilesMap инстанция вместо JSON низ. Това опростява използването на API-тата на Files, тъй като разработчиците могат директно да заявяват данните от FilesMap, вместо да преминават през JSON операции.

Успоредно с това постигнахме известен напредък в излагането на API-тата за удостоверяване, използвайки връзките от библиотеката safe-ffi. Остава ни да изложим още няколко API-та и да добавим няколко единични теста, за да гарантираме целостта им. След като това бъде завършено, приложението за удостоверяване може да бъде преструкторирано отново, за да използва API-тата от пакета, което означава, че няма да е необходимо да поддържаме връзките в две различни хранилища. Това също ще опрости развитието на SAFE Network програмата в бъдеще.

SAFE Network програма UX

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

Тук сме насочени към функционалността, така че макар да се стремим да добавим в UX-то малко „SAFE“ брандиране, това никога не трябва да е за сметка на използваемостта и функционалността.

Може да видите само някои фини и постепенни промени на екраните по-долу, като се стремим към нещо, което се надяваме да бъде много полезно и използвано. И разбира се да не забравяме цялата компонентност зад кулисите, която ще направи нещата по-лесни за подобряване и надграждане!

03f69af4c819fb6edf7c0f52961b872cb03ee001_2_318x500

77be89fc8a9c30f8c48ff3e9107c3d5ed78a7073_2_203x499

88d55c91dbec3e97e80b9562a09dc334c2815130_2_318x500

c820081306f58744dacb22f2251bb6062062565f_2_318x500

CRDT

През изминалата седмица продължихме с въвеждането на Sequence типа данни като CRDT. Както бе споменато преди, първите ни стъпки бяха за това всички основни библиотеки да поддържат този тип заявки. Сега добавихме същото към тестовия трезор за safe_client_libs, което ни помага да валидираме цялата логика от страна на клиента за всеки тип заявка.

В допълнение към това, мигрирахме NRSContainer и FilesContainers (в safe-api), за да започнем да използваме Sequence типа данни и успяхме да проверим дали всичко рабтестова мрежа.

Опитахме да стартираме тези E2E тестове и с локална Бейби Флеминг мрежа и сме на същия етап като при по-старите типове данни, което означава, че сега сме готови да започнем да добавяме действителната CRDT логика към клиента, така че проблемите със съдържанието, което не може да бъде намерено в някои несинхронизирани трезори са разрешени.

Трансфери

Следвайки последните няколко седмици проучвания на AT2, създадохме ново safe-transfers хранилище, върху, което все още работим да отчита основните свойства на AT2, приложени в настройките на SAFE Network.

Кратко описание

Имаме Актьори и Реплики, които да изпълняват различните стъпки на AT2 алгоритъма. Процес Актьор се управлява от клиент и той инициира прехвърляния от неговия ключ към друг ключ. Репликите се управляват от мрежовите възли - по-точно Старейшините на секция - за да валидират заявката и да използват няколко подписа, за да докажат съгласието си за нейната валидност.

Секция ще стартира един Актьор за управление на паричния балан на секцията и изплащането на фермерските награди, както и за получаване на плащания за качване на данни.

Следва

Сега работата ще продължи с тестване и гладене на подробности около обработката на ключовете на секциите за техния Актьор процес.

Връзки

Функции в Rust

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

safe_authenticator и safe_app също се компилират сега, като се извършва преобразуване на тестовите пакети и вече сме в началото на преобразуването на safe_authenticator_ffi.

Това беше голяма работа (много код за преглеждане), но с напредъка нещата изглеждат по-стегнати, по-изчистени и по-стройни от всякога!

Маршрутизиране

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

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

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

BLS - Разпределено генериране на ключове

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

Миналата седмица приключихме с тестовия си спринт върху контейнера. Със събраната обратна връзка сега работим върху внедряването на някои промени в механизма, благодарение на които потребителят на DKG вече няма нужда да борави с конкретните особености. В настоящия си вид потребителят трябва да извика ръчно API-тата, за да отговори на съобщения и да задейства прехода към другите фази. Актуализираме ги така, че потребителят не трябва да прави нищо ръчно с тях.

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

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

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

SAFE Network новини - 28.5.2020

Накратко

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

  • В момента разглеждаме премахването (или поне значително намаляване) на използването на Parsec в библиотеката за маршрутизиране.
  • Почти сме свършили с мигрирането на SAFE Клиентските библиотеки, за да преминем към функции на асинхронизация и да изложим неговото API също асинхронно.
  • Въведохме подход за поддръжка на символни връзки, което е почти същото като това, което прави git. Също адаптираме кода в safe-api, което извиква основното API на SAFE Клиентските библиотеки. След това трябва да можем да пуснем нова версия на SAFE CLI-то
  • Очакваният окончателен BLS-DKG PR вече е завършен и се преглежда, като контейнера се счита за готов за използване в мрежата, след като това бъде одобрено и добавено.

Проблеми с форума

Може би сте забелязали, че SAFE Network форума беше недостъпен вторник и началото на сряда тази седмица. Това се случи, защото регистрацията на името на домейна изтече и неговата регистрация беше в забранен акаунт на MaidSafe Фондацията, и съответно не бяхме директно сигнализирани, че се трябва да се поднови. В сряда сутринта (Обединеното кралство) домейнът беше прехвърлен в MaidSafe акаунт и подновен (с активирано автоматично обновяване).

Може да отнеме време тези промени да се разпространят, но вече всички трябва да имат достъп до форума.

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

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

Тази седмица приключихме с прилагането на потоците за обработка на данни, когато възрастен напусне мрежата. Възрастните имат отговорността да държат неизменни парчета данни, така че след напускането им трябва да заменим изгубените копия на парчетата, за да поддържаме необходимия брой копия на данните и да гарантираме запазването на данните. Първоначалното внедряване работи според очакванията и резултатите от теста изглеждат добри. Настоящата имплементация има малко мрежови разходи, за които сме наясно. Благодарение на функции в Маршрутизирането, които оптимизират комуникациите в рамките на дадена Секция, можем да преодолеем това с няколко корекции, които са в ход. С помощта на тази оптимизация ще бъдем в състояние да пуснем тестова мрежа, която включва Възрастни от вкъщи с отговорността за съхраняване на данни. Следващите стъпки са справянето с напускане на мрежата от Старейшините, разделяне секция и така нататък, неща върху които ще работим в следващите дни.

SAFE API

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

Поддръжката за символни връзки идва

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

Този първоначален подход трябва да:

  • позволи относителни връзки вътре в дървото на директории, при качването им
  • конвертирате абсолютни връзки в относителни връзки вътре в дървото за качване.
  • конвертирате връзки извън дървото за качване в реални файлове.

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

Така след известно обмисляне прилагаме най-простата схема, която всъщност е почти същата като тази на git. В тази схема всички символни връзки се качват точно такива, каквито са, дори абсолютни пътища до други места във файловата система на потребителя и прекъснати връзки. Ако потребителят качва тези данни за архивни / резервни копия, тогава може да бъде много полезно тези символни връзки да бъдат възстановени правилно при изтегляне. В противен случай, ако потребителят качва файловете за уебсайт или друго обществено използване, тогава потребителят трябва да провери за прекъснати връзки.

За момента качването и извличането на символни връзки работи върху Unix платформи. Windows се държи малко по-различно, така че ще ни отнеме малко допълнителна работа през следващата седмица.

Под капака

Работихме и върху адаптирането на кода, който включва основното API на SAFE Клиентските библиотеки, тъй като той е мигриран, за да излага асинхронизиращи API-та. Стремим се да приключим тази седмица и да бъдем готови да пуснем нова версия на SAFE CLI-то, което носи няколко подобрения и нови функции, които да изпробвате.

Поправки

  • PR 562: коригира NRS способността на вложени подимена.
  • PR 558: files ls сега откриват NRS URL адреси правилно.

CRDT

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

За щастие приключваме с преструктурирането днес или утре и след това ще можем да започнем да добавяме логиката от страна на клиента за CRDT, т.е. да започнем кеширането на реплика на данните, така че да може да бъде променяно локално от клиента и да излъчва операция до секцията за данни на старейшините за съхранение в мрежата. Това ще ни даде първата PoC и E2E реализация на CRDT последователност.

Трансфери

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

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

Разширение на този проблем беше проверката на резултатите от отдалечена група копия (в по-горните слоеве, известни като отдалечена секция). Оказва се, че е и въпрос за членство, макар и не членство в копия / секции, а системно членство. Следователно това е и функционалност, осигурена от горния слой.

Успоредно с това продължава да се извършва цялостно изчистване на имена и код, а също работим и по тестове и интеграционно тестване на компонентите, с допълнителна работа за намиране на проблемни точки за тестируемост/модулност. Основните тестове за интеграция преминават и сега настройваме тестване въз основа на собственост.

Функции в Rust

През последната седмица се наблюдаваше бурна дейност със събирането на нещата в асинхронизацията. Цялата SCL се компилира добре и вече CI тестовете преминават успешно.

Завършихме актуализациите на самокодирането, обединени в главната и нова версия на кода (от който зависят SAFE Клиентските библиотеки).

safe-api е актуализиран за новата версия на SCL. Това извади наяве някои други проблеми в кода, включително някои блокиращи поведения в await кода за съобщенията, но вече го коригирахме и преминаваме през някои заключителни тестове с API-тата, преди да включим всичко това в кода.

Това беше много работа, така че е чудесно да видим как завършва (и да се сбогуваме с около 2000 реда код!)

Маршрутизиране

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

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

В момента разглеждаме друга голяма промяна за Маршрутизирането - премахването на Parsec.

Това може да звучи странно, защото Parsec е алгоритъмът, който разработихме специално за нуждите на Маршрутизирането. Той работи много добре и премина много кръгове от много обширни тестове.

Тогава какъв е проблемът с него? Производителността. Може да отнеме от порядъка на десетки секунди, за да се постигне консенсус за едно единствено наблюдение, което е скорост, която просто не се мащабира спрямо нашите нужди. Ето защо решихме преди време да спрем да го използваме за заявки за данни (които прехвърлихме към CRDT), но това не е достатъчно. Също така искаме да премахнем (или поне значително да намалим) използването му в самата маршрутизация. Това всъщност е възможно, без да жертваме нито една от целите, които сме си поставили за Маршрутизирането, защото се оказва, че Парсек прави доста повече, отколкото ни е необходимо. Например, всъщност не се нуждаем от пълен ред на наблюденията. Всичко, от което се нуждаем, е, че действията са съгласувани от кворума на Старейшините на секциите и те да са последователни. Така че върху това ще работим през следващите няколко седмици.

BLS - Разпределено генериране на ключове

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

Тази седмица се съсредоточихме върху въвеждането на всички оптимизации, които направихме от наблюдаването на симулациите и тестовете в реална мрежа към главния клон с PR 14. Този PR добавя транспортния слой (quic-p2p) и така завършва контейнера. Като генерален контейнер, той е насочена към потребители от всякакъв тип (Трезори и Клиенти), поради което интегрираният транспортен слой улеснява потребителите, тъй като те не трябва да се притесняват за обмен на съобщения и завършване на BLS сесията - както беше обсъдено в последното седмична актуализация, контейнера поема отговорността за това с помощта на таймери. Този PR в момента преминава през процеса на преглед и е близо до готовност за сливане, и следващата стъпка ще бъде да започнем интеграцията на BLS-DKG с другите части на SAFE Network, още една стъпка по-близо до нашата крайна цел!

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

SAFE Network новини - 4.6.2020

Накратко

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

  • Пуснахме нови версии на API-то (v0.13.0), CLI-то (v0.13.0) и safe-authd (v0.9.0), които носят няколко подобрения и корекции, напр. командата за качване на файлове сега поддържа качване на празни директории и скрити файлове.
  • SAFE Клиентските библиотеки вече са напълно настроени за Rust асинхроност/изчакване.
  • Събрахме и отговорихме на няколко от най-често срещаните въпроси, възникнали от новината за премахването (или значително намаление) на Parsec.
  • Вече се работи за премахването на Parsec, като първата стъпка е да се прикачи BLS подпис към цялата споделена информация за състоянието.
  • Самият Parsec контейнер не е напълно изоставен! Току-що пуснахме нова версия с поправки, която актуализира зависимостите.
  • Сега контейнера BLS-DKG се счита за завършен и се работи за интегрирането му в маршрутизацията.

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

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

През изминалата седмица внедрихме редица подобрения в начина, по който Възрастните и Старейшините общуват помежду си в рамките на Секция за обработка на заявки за неизменни данни. Това включва обменяните съобщения за поддържане на необходимия брой копия за всяко парче информация. Няколко вътрешни тест мрежи ни помогнаха да идентифицираме някои грешки в реализацията и PR-а вече е одобрен. Сега изпълняваме това, което се надяваме да бъде окончателна версия на вътрешната тест мрежа, за да сме сигурни, че всичко работи, преди да го пуснем публично. Ако приемем, че вътрешното тестване преминава без големи трудности, скоро ще имате нова играчка, с която да играете!

Имаме предвид няколко идеи за следващите стъпки напред, например, разпределяне на отговорностите за управление на данни към нови Старейшини, когато дадена Секция се раздели и справяне със случай, при който Старейшина напусне мрежата. Ще започнем прилагането в идните дни.

SAFE API

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

Тази седмица пуснахме нови версии на CLI-то (v0.13.0) и safe-authd (v0.9.0), които носят няколко подобрения и корекции, заедно с някои нови функции за файловите команди. Например командата за качване на файлове сега поддържа качване на празни директории и скрити файлове. Както обикновено, можете да използвате CLI-то, за да актуализирате както CLI-то (с $ safe update ), така и safe-authd (с $ safe auth update ) или да следвате инструкциите в Ръководството за потребителя на CLI при инсталирането им за първи път и / или всякакви други инструкции.

Нова версия на safe-api-то (v0.13.0) също е готово тази седмица. То вече използва най-новата версия на Safe-client-libs, която излага API-то си като async. С това завършихме миграцията на всички наши контейнери в хранилищата на safe-api и safe-client-libs, за да използваме Rust синтаксиса async/wait, което ще ни позволи да направим още много подобрения и опростявания на safe-client-libs кодовата база в бъдеще.

Междувременно работата по поддръжката на символни връзки продължава. В най-новия код за разработка (все още няма заявка за изтегляне) е възможно да се получат както относителни, така и абсолютни символни връзки за PUT и GET, а също така да се показват правилно във файлово дърво и файловите списъци. Символните връзки могат да бъдат деактивирани, като се използва нов --follow-link флаг към поставените файлове, което води до старото поведение.

Едно подобрение на скоростта: в Windows писането на символни връзки на хард диска изисква определени разрешения (зависи от точната версия на ОС), така че получените файлове могат да пропуснат символната връзка и да покажат предупреждение в случая. Git също има този проблем и обикновено създава малък текстов файл, съдържащ връзката-цел. И ние можем да използваме този подход. Като потребител на Windows, поддръжката на символната връзка е активирана, като изберете стартиране като администратор при стартирането на команден терминал, или можете да активирате режима за разработчици в Windows 10+.

Следващата ни работа ще бъде разрешаването на относителни символни връзки, когато се използват в пътя на Safe-URL-то.

CRDT

След публикуването на новата версия на Safe-client-libs в началото на тази седмица, възобновихме работата по реализацията на Последователно CRDT. Постигнахме това чрез адаптиране на клиента, така че той да поддържа локална реплика на CRDT съдържанието (включително информацията за причинно-следствената връзка), за да може да прилага всички промени локално.

Това означава, че клиентът ще прави мутациите в собствената си локална реплика на CRDT съдържанието и след като успее, той просто ще излъчи операцията в съответната Секция в мрежата за постигане на постоянство.

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

Като част от това усилие адаптирахме заявките за „прикачване“ на последователността, за да съдържат информация за причинно-следствената връзка, необходима за сливане на операциите в репликите на мрежата. Сега разглеждаме начини да гарантираме, че всеки път, когато четем съдържанието, получаваме достатъчно копия от мрежата, за да можем да получим най-новата му версия.

Трансфери

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

Сега, когато async/await са обединени в lib-safe-client, актуализираме нашата SCL AT2 реализация за тази настройка и я актуализираме, за да отговорим на последните промени в самите safe-transfers. В момента това включва създаването на местен Актьор за управление/сливане на доказателствата за валидиране от старейшините и ефективно обвиване на всички наши заявки за пари в мрежата. Това, да се надяваме, трябва да капсулира добре тази логическа страна на клиента и да направи някои от нашите клиентски API-та, малко по-ясни.

Що се отнася до инициирането на Актьора, репликите трябва да разкрият API, което позволява на клиентска заявка от доказателства за валидиране на акаунт, от който може да бъде стартиран Актьор. Като допълнение, това поддържа текуща синхронизация от Репликите. Понастоящем работим по въвеждането му.

В другия край на спектъра, започнахме да надграждаме Трезора, за да приспособим рамката за AT2 трансфери, която ще управлява потока на парите в SAFE Network - чрез CRDT. Репликата/ите, както казва името, са реплики на сметката на клиента и техните парични салда в мрежата. Отговорността за управлението на Реплики е само в ръцете на Старейшините, тъй като те са най-надеждните в мрежата. Поради динамичността на мрежата, когато старейшините се присъединят и напуснат, от решаващо значение е да поддържаме Репликите, като ги генерираме и актуализираме съответно. Започнахме да работим по тези механизми и ще напредваме в прилагането на целия поток от край до край през следващите седмици. Следете!

Функции в Rust

Споменахме ли, че SAFE Клиентските Библиотеки вече са напълно настроени за Rust асинхроност/изчакване! Последната седмица беше прекарана в тестване със safe-api-то, CLI-то и трезорите, проучване на някои проблеми и актуализиране на safe-api-то да поддържа собствени времена на работа за консумацията на тези нови API-та за асинхроност. След като всички тестове преминаха успешно, с радост направихме ново издание за API / CLI срещу актуализираните клиентски библиотеки. Все още наблюдаваме някои проблеми с FFI библиотеките, които може да се нуждаят от допълнителна работа за новата настройка на асинхроност/изчакване.

И накрая, видяхме някои проблеми в SCL тестовете, когато работим с локална мрежа, въпреки че CLI тестовете преминават с клона на SAFE Клиентските Библиотеки. Сега се стремим да гарантираме, че SCL тестовете се изпълняват в локалната мрежа като част от CI-то и ще прегледаме защо са неуспешни.

Маршрутизиране

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

Миналата седмица обявихме премахването на Parsec, което предизвика интересна дискусия и също породи някои въпроси сред общността. Нека обобщим основните повдигнати въпроси и се надяваме това да ги изясни изцяло:

  1. Връщаме ли се към търсенето на ново решение?
    Въобще не. Премахването на Parsec не означава, че сега търсим друг алгоритъм за консенсус. Разбрахме, че Parsec просто прави твърде много и това, от което се нуждаем, е много по-просто. От известно време анализираме решение, използвайки CRDT, AT2 и BLS, когато е подходящо, за да постигнем само това, от което се нуждаем. През последните няколко седмици и месеца публикувахме ежеседмично изследванията и работата ни по прилагането им и вярваме, че те са повече от адекватни, за да продължим напред без Парсек.
  2. Това ще забави ли Алфата/Флеминг/Бейби Флеминг/…?
    Не. Работата по премахването на Parsec продължава паралелно с всяка друга работа, която е необходима за пускането на мрежата. Заявките от екипа на трезорите вече са с най-висок приоритет и бързо се адресират. Освен това маршрутизирането, както е в момента, прави почти всичко, което трябва, просто не е възможно по най-ефективния начин. Така че в най-лошия случай винаги можем да пуснем алфа с него такъв, какъвто е, и да го заменим с версиябез Parsec по-късно.
  3. Напълно ли ще премахнем Parsec?
    Най-вероятно да. Но дори и нещата да се объркат ужасно и да се окаже много по-трудно, отколкото сме мислили, винаги можем да отстъпим, за да задържим Парсек наоколо по някакъв намален начин. Но не смятаме, че ще се стигне до това.
  4. Parsec загуби ли време и ресурси?
    Абсолютно не. Parsec все още е фантастично постижение в ABFT, само по себе си иновация. Оправдан беше пътят, който избрахме да изминем през 2018 г. и несъмнено ни помогна да стигнем до мястото, където сме днес. Понякога единственият начин да разберете дали нещо е подходящо за вашите развиващи се нужди е да го изпробвате. С времето ни стана по-ясно, какви са недостатъците и ограниченията му за нашите конкретни нужди, докато алтернативите станаха по-ясни и по-зрели. Винаги ще правим това, което е правилно за мрежата и ако това означава да намалим използването на Parsec, това е курсът на действие, който следваме, за да постигнем крайните си цели.

Надяваме се това да помогне да се обобщят отговорите, които най-вече предоставихме в новините миналата седмица, разбира се ако имате нужда от допълнителни пояснения, ние сме тук, за да помогнем!

Ето напредъка ни и тази седмица в маршрутизирането:

Работим върху първата стъпка от премахването на Parsec. Понастоящем Трезорите в дадена Секция съхраняват цялата информация за своята и другите Секции в структура от данни, наречена SharedState. Всяка промяна на тази структура трябва да бъде одобрена от кворум от Старейшините, което в момента означава, че тя трябва да премине през Parsec. Трезорите, които активно участват в Parsec, могат да се доверят на тази информация, защото тя е вследствие от консенсуса на Parsec за нея.

Но какво да кажем за новите трезори? Споделеното състояние не може да се провери от само себе си, така че ако нов трезор стане Възрастен, всички съществуващи Старейшини трябва да гласуват за текущото споделено състояние, така че новият Трезор да види консенсус за него. Това е доста скъпо. За да подобрим това, ще го направим така, че всяка част от информацията, съхранявана в споделеното състояние, да има свои прикрепен BLS подпис. По този начин споделеното състояние или която и да е част от него става самопроверима. Механизмът за това вече е налице, просто досега не го използвахме толкова, колкото трябва. Очаквайте PR скоро.

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

BLS - Разпределено генериране на ключове

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

Тази седмица завършихме процеса на преглед на PR 14 и го обединихме в основния клон! :tada:

Това, разбира се, добави транспортния слой (quic-p2p) в контейнера, като гарантира, че потребителите не трябва да се притесняват от обмена на съобщения и завършването на BLS сесията. С обединяването на този окончателен PR, контейнера е завършен и BLS-DKG вече е готов за използване в мрежата. Първата цел е да накарате маршрутизацията да използва директно BLS-DKG контейнера вместо сегашния DKG генератор от Parsec. Работата по интегриране на BLS-DKG с маршрутизацията е в ход.

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

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

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

Обещахме ви нова играчка и днес е при вас :tada:

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

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

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

Още един важен момент e достигнат :rocket:

SAFE API

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

Работата по символните връзки продължава. Последната стъпка е да се даде възможност за разрешаване на символни връзки в SafeUrl пътя. Повечето езици за програмиране имат функция realpath () (или еквивалентна), която премахва . / И заменя ../ и всяка символна връзка в пътя, както е подходящо, за да генерира окончателен истински път. Тази седмица написахме функция realpath (), която разбира метаданните в „FileContainer“ и се извиква в „Safe::fetch ()“ API-то, така че ще работи за всички заявки към SafeUrl за поддробности. Остават някои подобрения и тестове, но се надяваме, че PR-а може да бъде готов в началото на следващата седмица с пълна поддръжка на символните връзки.

CRDT

През изминалата седмица се съсредоточихме върху клиентската страна на CRDT Последователността, като започнахме със създаването на някои първоначални E2E тестове на safe-api хранилището и ги пуснахме срещу тестовата Секция на Бейби Флеминг. Успешно осъществихме множество основни сценарии, работещи за създаване на съдържание от Последователността, добавяне и извличане на данни от нея. Също така мигрирахме FilesContainers и NRS контейнерите, да използват CRDT Последователността (вместо AppendOnlyData типа) и всички тестове на E2E също преминават в Бейби Флеминг секцията.

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

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

Трансфери

SAFE Трансфери План на проекта
SAFE Клиентски библиотеки План на проекта
SAFE Трезор План на проекта

Интеграцията на SAFE Клиентските Библиотеки напредна добре през последната седмица. Актуализирахме основната библиотека за новите транзакции в стил AT2 и започнахме с основната интеграция на TransferActor . Това ще бъде обвивна структура, която ще премахне голяма част от логиката на заявката и управлението, които преди това се обработваха в API-тата на клиентския слой, което ни дава малко повече модулност. Започнахме да тестваме това и напредваме с актуализирането на тестовете в основната библиотека като цяло.

Беше седмица с химикалки и хартия за AT2 safe-vault и safe-transfers . Сега проектираме и създаваме механизъм ( SectionActor ), който поема отговорността за Парите , които се плащат от клиентите за данните, които качват. Секциите в SAFE мрежата ще имат свои акаунти, които се поддържат от този разпределен „SectionActor“, разположен при старейшините на конкретната секция. Когато клиент плати за качване на данни, парите се кредитират в акаунта на секцията за съхранение на данни, а „SectionActor“ ще е отговорен за разпределението на наградите към трезорите, които са свършили работата (за съхранението). Тази работа е свързана с фермерството, където в момента тестваме разделени на части награди с пакетни изплащания. Подобряваме и усъвършенстваме този поток, докато продължаваме напред с прилагането му едновременно навсякъде.

Маршрутизиране

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

Работата по премахване на Parsec върви напред с пълна скорост. Миналата седмица споменахме, че ще направим всички данни в споделено състояние, да се подписват с подписите на BLS, за да ги направим самовалидни. Тази работа донесе някои неочаквани усложнения по-рано тази седмица и така ни отне повече време, отколкото очаквахме. Но изглежда, че най-трудните въпроси вече са решени, а това, което остава, е сравнително ясно. Очаквайте скоро PR.

Също така сме почти готови да заменим DKG модула (разпределеното генериране на ключове) с BLS-DKG контейнера. Първоначално DKG не беше предвиден да е част от Parsec (не го споменаваме в бялата му книга), но беше включен в него, тъй като това беше най-простият начин за прилагането му по това време. Въпреки това има някои сериозни ограничения, така че тази подмяна определено е голямо подобрение, независимо от премахването на Parsec. PR в момента е в процес на преразглеждане и все още има някои дребни грешки, които трябва да се отстранят, но очакваме скоро да бъде обединен.

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