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

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

02. Начало

Какво ми е необходимо за да браузвам SAFE мрежата?

В SAFE Network може свободно да разглеждате SAFE уебсайтове напълно анонимно, от където и да е по земята. За да подсигурим сигурност и анонимност не можехме да разчитаме на ничия съществуваща браузър технология използвана в стария интернет (Chrome/FireFox/IE/Safari) затова създадохме своя.

Всичко, от което имате нужда е нашия нов SAFE Browser , който може да свалите от линка по долу, моля имайте пред очи, че настоящата Алфа 2 версия на мрежата изисква да имате покана, която може да получите по начина описан тук: SAFE Network Alpha 2

Свалете SAFE Browser

Имам ли нужда от акаунт за достъп до мрежата?

Разглеждане на SAFE Network уебсайтове:

В SAFE Network може да разглеждате и сваляте от SAFE сайтове напълно анонимно, от всякъде по света. Без да е необходим акаунт.

(За да браузвате/тествате Alpha 2 е необходимо да имате акаунт: SAFE Netowrk Alpha 2)

За да започнете свалете SAFE Browser и въведете SAFE сайт в адрес бара. Няколко прости SAFE сайта:

  1. safe://www.sharedmap/
  2. safe://jams.demo2/
  3. safe://listy/

Съхранение в мрежата:

Имате нужда от акаунт за да извършвате действия, които изискват да качите някаква информация или да модифицирате съществуваща такава в SAFE мрежата. Дейности, които изискват акаунт включват:

  • качване на сайтове
  • съхранение на информация
  • email апликации
  • чат приложения
  • и т.н.

Как да си създам акаунт?

Какво е необходимо:

  1. Свалете и инсталирайте SAFE Browser.
  2. Регистрирайте си акаунт във форума на общността, отнема по-малко от минута.
  3. Стигнете до базово ниво — това отнема час четене и разглеждане, като целта е да ограничи достъпа на спамери до тестовата мрежа по време на разработката на проекта.
  4. Стартирайте SAFE браузъра.
  5. Кликнете на Създай акаунт (Create Account) в долната част на прозореца.
  6. В следващия прозорец кликнете на Заяви покана (Claim An Invitation).
  7. Влезте в акаунта си в SAFE Browser, процесът по получаване на покана ще ви подкани за това, ако не сте влезли вече.
  8. Изберете Alpha 2 Network.
  9. Инсталатора ще ви покаже кода ви за покана. Важно е настоящия ви IP адрес и регистрирания да съответстват един на друг, ако не съответстват кликнете на обнови.
  10. Копирайте кода за покана в долния край на екрана и го поставете обратно в прозореца, който иска ‘Invitation Token’ в SAFE Browser.
  11. Ще бъдете подканени да създадете Тайна на Акаунта (Account Secret) и парола. Моля запишете си ги, защото само вие имате достъп до тях и няма как да бъдат възстановени. Никъде няма запис на тях в системата и без тях ще загубите достъп до информацията си.
  12. Поздравления! Вече може не само да разглеждате SAFE сайтове в SAFE мрежата, но и да качвате собствена информация, да създавате сайтове и да използвате някои демо програми, създадени от общността.

Как да се включа в общността на SAFE network?

Общността е най-активна в SAFE Network Форума и ви препоръчваме да започнете от секцията за начинаещи (на английски).

Посетете форума

Как да получа помощ?

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

Посетете форума

Ако имате въпроси може да ги зададете и във Facebook групата на българската SAFE общност: Redirecting...

Ако искате да следите последните новини заповядайте във Facebook страницата на SAFE Network България: Safe Network България

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

03. Как работи

Какво е Трезор?

SAFE Network е съставена от компютрите на потребителите върху, които работят програми наречени Трезори (Vaults). Трезора е програма, която свързва компютъра към мрежата. Взети заедно Трезорите управляват съхранението на цялата информация в мрежата и ръководят движението на частите криптирана информация на потребителите, когато се съхраняват в мрежата. Никой Фермер (потребител) не може да декриптира частите от информация, която неговия Трезор получава за съхранение и получава награда за предоставения капацитет за съхранение под формата на Safecoin.

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

Тези групи от компютри се формират, съединяват и разделят без човешка намеса, като SAFE мрежата изцяло контролира процеса автономно. По съшия начин криптираните части от информация се движат в мрежата напълно автономно. Мрежата работи без централни сървъри или агенти (като BitTorrent тракерите). Няма централни фигури, които да ръководят процесите.

Също както на децата не е позволено да гласуват на изборите, така и Трезор не може да гласува за събитията в мрежата (събития като присъединяването на нов член или съхранението на част от информация) преди да е доказал надеждността си. Първоначално Трезора трябва да изпълни успешно Доказателство за Ресурс за да се присъедини към мрежата, доказвайки че има свободни определено количество от интернет скорост и CPU капацитет. След това бива присъединен към Секция и получава нисък ранг (low Node Age). Когато ранга на Трезора достигне определена стойност той може да стане активен член във взимането на решения в секцията. Трезорите с най-висок ранг в секцията се наричат Старейшини (Elder). В резултат на това, понеже новите Трезори трябва да доказват своето качество в различни случайно избрани Секции преди да могат да гласуват, атаката срещу конкретна Секция в SAFE Network от злонамерена личност/група е близко до невъзможното.

Трезорите също така криптографски потвърждават съобщенията и имат по определени роли, наречени персонажи. Всеки Трезор има Клиентски Мениджър (Client Manager) персона. Това съхранява запис за детайлите на акаунта на всеки Клиент (потребител) в неговата Секция. Например това ще потвърди колко информация е качена в мрежата, колко от нея е съхранена и баланса в Safecoin оставащ за покупка на бъдещо място. Въпреки че Клиентския Мениджър ще знае баланса на акаунта той няма как да го свърже с идентичността на потребителя (IP адрес, потребителско име или публичната идентичност).

Всеки трезор има и Дата Мениджър (Data Manager) персона. Той управлява къде криптираните части от информация на други потребители се съхранява и отговаря за частите в неговата си Секция.

Защо имаме нужда от Автономна мрежа?

Автономна мрежа е такава, която управлява всичката ни информация и комуникации без човешка намеса и без посредници. Тя е мрежа, която се самоконфигурира. Ресурси не се добавят от централизиран IT администратор – премахвайки възможността за злонамерени или небрежни действия. Мрежата съществува без нужда от разрешение (permissionless) – участието е достъпно за всеки, който желае, премахвайки възможността за монопол от единични корпорации, чиито контрол може да расте необуздано.

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

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

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

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

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

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

Какво е Доказателство за ресурс?

Доказателство за ресурс (Proof of Resource) е процес, който измерва способността на Трезора да съхранява и предоставя части от информация. Компютъра на потребителя получава класиране според скоростта на процесора, скоростта на интернета, мястото на хард диска и времето онлайн.

Доказателство за ресурс в SAFE Network използва механизъм подобен на Нулево доказателство за знания (Zero Knowledge Proof). На механизма за проверка не му е необходимо знание за каква информация се проверява – достатъчно му е да знае, че правилната информация се съхранява коректно.

Какво е само-криптиране?

Само-криптирането (Self-encryption) е метод, при който файл с информация се разделя на части и всяка част се криптира чрез другите части от същия файл. Това е критичен процес в SAFE Network и той гарантира, че информацията е неразпознаваема и устойчива на декриптиране – дори и в случай, че алгоритъма за криптиране бъде разбит.

Цялата информация е само-криптирана преди да достигне SAFE мрежата. Процеса е автоматичен и се случва в реално време.

Когато информацията се съхранява във виртуалния хард диск на потребителя, като се разделя на минимум от 3 части, хашва се и след това се криптира. За да се подсигури допълнително информацията, всяка част преминава през XOR функция използвайки хашовете на другите части. Всяка част след това се разделя и ключови двойки се съхраняват в таблица в потребителския профил наречена дата карта (data map). Дата картата съхранява местоположението на всяка част, която изгражда файла. Дата картата, която се хешира преди и след криптирането се използва за да извлече и разкриптира информацията на потребителя, защото самият процес на криптиране е необратим (non-reversible).

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

Какво е PARSEC?

Протокол за Асинхронен, Надежден, Сигурен и Ефективен Консенсус ( P rotocol for A synchronous, R eliable, S ecure & E fficient C onsensus.)

PARSEC е консенсус алгоритъм, който позволява децентрализирани мрежи да достигат до съгласие за серия от събития, действия или дейности по сигурен и надежден начин, който е не само силно асинхронен, но и устойчив на Византийския проблем (Byzantine Fault Tolerant). С други думи математически е гарантирано да се постигне консенсус в мрежата (при условие, че не повече от 1/3 от компютрите в нея са злонамерени или проблемни по каквато и да е причина)

Прочетете документацията (whitepaper)

Вижте видео с техническо представяне

Оставете на Дъг от MaidSafe да ви обясни

Какво е дата дедубликация?

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

Какво е само-удостоверяване?

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

Какво е Консенсус на близка група?

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

Отговора се намира в близките групи. Използвайки Консенсус на близка група (Close Group Consensus) малки групи могат да правят заявления от името на цялата мрежа, което значи, че мрежата не е необходимо да комуникира със всеки един компютър в нея директно всеки път.

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

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

Close Group Consensus не се използва за всяка операция в мрежата, защото това ще създаде ненужно натоварване. Използва се само при съхраняването на информация в мрежата – криптографски подписи се използват за другите действия – например, при прости промени в информацията или при изпращане на Safecoin към друг потребител.

Какво е Дата чейн (Data Chain)?

По същия начин, както блокчейна на Биткойн не съхранява биткойни, Дата чейн (Data Chain) не съхранява информация. Това, което съхранява е информация, че определана информация съществува и къде точно в мрежата се намира. Още повече в SAFE Network определената информация е реално намираща се в мрежата (документи, видео и т.н.). Това значи, че може да използваме дата чейн да докажем, че самата информация е валидна информация от мрежата (т.е. била е приета преди в мрежата).

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

Има още доста подробности за архитектурата, но за да обобщим Data Chain ще се дели заедно с растежа на мрежата, а общия запис на информацията ще остава достъпен за всички трезори. Връзките доказват членството и консенсуса постигнати в миналото. Използвайки Дата чейн трезорите имат доказуема история в мрежата, което значи, че те могат да докажат членството си в секцията и да получат лесно ранг с цел защита. Някои трезори няма да има нужда да съхраняват реалната информация, а само идентификаторите на информацията, след като сигурността й е гарантирана. И от значителна важност е, че Дата чейн ще позволи сигурното възстановяване на информацията в случай на тотално временно разпадане на физическата свързаност между компютрите в мрежата (в следствие на световен/локален катаклизъм), както и валидация на съхраняването на информацията в мрежата.

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

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

04. Въпроси за SafeCoin

Какво е SafeCoin / MaidSafeCoin?

Safecoin дигитална валута, която се генерира автономно от SAFE Network и съществува единствено в SAFE Network. Мрежата автономно потвърждава баланса в портфейлите на потребителите и позволява да се осъществяват транзакции. Safecoin се харчи чрез полагане на дигитален подпис, от последния собственик на койните. Тази операция е “на мрежово ниво”, с други думи мрежата обновява цялата информация за транзакцията. Това е различен подход от този на блокчейн решенията като Биткойн.

За какво се използва SafeCoin в SAFE Network?

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

Без каквато и да е човешка намеса SAFE мрежата заплаща в Safecoin на Фермерите (потребители, които продават свободните ресурси на компютъра си на мрежата) и на Строителите (програмисти на програми, които получават заплащане в зависимост от това, колко често се използват програмите им).

В допълнение разработчиците на ядрото (Core Developers), които подобряват софтуерното ядро на SAFE Network могат също да получават Safecoin, като изпращат поправки на бъгове или добавят нови функционалности.

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

Как да купя SafeCoin?

Safecoin няма да е достъпен за продажба до излизането на финалната версия на мрежата и не може да бъде закупен в момента. Сега може да закупите само MaidSafeCoin, който ще бъде обменен 1 към 1 срещу Safecoin, когато стане достъпен.

MaidSafeCoin се намира върху блокчейна на биткойн и може да се закупи от редица борси, включително:

За повече вижте ‘Как да купя MaidSafeCoin?

Защо не използвате просто Bitcoin?

Bitcoin не е свързан по никакъв начин със SAFE мрежата и не може да бъде генериран и разпределян от SAFE мрежата. Safecoin се генерира в следствие на използването на мрежата (когато се извлича съхранената информация или когато се използват програмите в мрежата) и е дигиталната валута на SAFE мрежата.

Как се оценява стойността на SafeCoin?

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

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

Как е разпределен SafeCoin?

Броя Safecoin, които могат да съществуват в SAFE Network е 2^32, или малко под 4.3 милярда. 5% от тях са заделени за компенсация на ранните инвеститори, които подкрепиха мрежата в ранните й дни. Допълнителни 10% бяха продадени на публична разпродажба в началото на 2014 година. За тях беше създаден MaidSafeCoin (базиран на блокчен токен, който ще бъде обменен срещу Safecoin едно към едно, когато мрежата стартира). На този етап притежателите на Safecoin ще могат да го използват, както желаят.

В последствие Safecoin ще влиза и излиза от циркулация в следствие на следните принципи:

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

Safecoin се разпределя като продукт на успешен “опит за фермерство.” Последователността, която води до успешен опит за фермерство започва, когато Трезор на фермер достави успешно предварително запазена информация, при поискването й. Шанса за получаване на успешен опит за фермерство се регулира от скоростта на фермерския добив (Farming Rate) в мрежата в момента, и чрез нея се регулира трудността за получаване на опит за фермерство, в зависимост от състоянието на мрежата (количеството на достъпни ресурси за съхранение).

  • Фермерите (Farmer) се квалифицират за опит за фермерство при 100% от скоростта на фермерския добив (Farming Rate) (според ранга на Трезора)
  • Създателите на програми (App Builder) за SAFE мрежата се квалифицират за опит за фермерство при 10% от скоростта на фермерския добив
  • Общия запас (Core Dev pool), от който програмистите работещи върху ядрото на SAFE мрежата биват награждавани се квалифицира за опит за фермерство при 5% от скоростта на фермерския добив.

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

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

Какво е MaidSafeCoin?

MaidSafeCoin е прокси токен, който беше пуснат в обръщение по време на публичната разпродажба на MaidSafe през 2014 година и ще бъде обменен 1 към 1 за Safecoin, когато Safecoin бъде пуснат в обръщение.

MaidSafeCoin се намира върху блокчейна на биткойн и може да бъде закупен от редица борси включително Bittrex, HitBTC

Как да купя MaidSafeCoin?

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

  1. Създайте си OmniWallet.
  2. Купете биткойн чрез предпочитания си доставчик.
  3. Създайте си акаунт в борса, която поддържа MaidSafeCoin (например Bittrex).
  4. Изпратете биткойни към акаунта си в борсата.
  5. Обменете ги за MaidSafeCoin.
  6. Изтеглете / Изпратете ги към OmniWallet.
  7. MaidSafeCoin вече са съхранени в OmniWallet!

Къде мога да съхранявам MaidSafeCoin?

MaidSafeCoin е създаден с помощта на Omni протокола върху блокчейна на Биткойн и може да бъде съхраняван върху всеки биткойн портфейл, от който имате пряк достъп до частния ключ. MaidSafeCoin може да не са видими в софтуера на портфейла (поради липса на поддръжка на omni протокола), но ще бъдат в безопасност, докато компютъра и частния ключ за този адрес са в безопасност и ще може да ги видите чрез omniexplorer.info.

Ако искате да създаде нов Omniwallet или да отворите съществуващ такъв посетете omniwallet.org.

Как ще бъде обменен MaidSafeCoin за SafeCoin?

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

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

05. За Фермерството (копаене на криптовалутата)

Какво е Фермерството?

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

Процесът на предоставяне на ресурс и получаване на Safecoin в замяна се нарича “фермерство“.

Всяка част от криптираните мрежови данни се съхранява в „Трезора“ на фермера, място за съхранение и управление на данни на компютъра на фермера, което те не могат да преглеждат, защото е криптирано и съответно нямат достъп до него. SAFE мрежата е създадена да управлява самостоятелно (автономно) тези ресурси.

Как ще работи фермерството на практика?

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

Опит за фермерство означава: чрез предоставяне на парчета данни при поискване, Трезора понякога получава възможност да направи Опит за фермерство. Това се състои в изпращане на валидирана заявка до случаен Safecoin адрес. Ако вече съществува Safecoin със собственик на този адрес, опитът е неуспешен. Ако там няма Safecoin, той се създава и се награждава на искащия го Трезор (т.е. успешно е извършен Опит за фермерство).

Затова Фермерството, е когато Трезор доставя парчета данни, които се съхраняват в мрежата и печели Safecoin в замяна.

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

Какво спира хостинг провайдърите от фермерството?

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

Скоростта на печелене на Safecoin се определя от фермерския добив (баланса между търсенето и предлагането в мрежата) умножен по ранга на Трезора. Фермерския добив ще достига до 20% над средния за мрежата, като така обезкуражава поддържането на масивни Трезори, които биха довели до централизация на фермерския процес в мрежата.

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

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