Накратко
- Днес е Денят за поверителност на данните (известен също като Денят за защита на данните в някои части на света). Ние насърчаваме всички в общността ни, както и всички, свързани с други проекти с подобни цели, да се стремят по-силно от всякога да постигнат това. Всеки ден всички се приближаваме с една крачка по-близо. :raise_hands:
- PR за наградите сега преминава през допълнителна проверка и тестване - добива на нови монети е много близо!
- Най-накрая открихме и поправихме проблема с увисващите връзки, който ни се опъваше от няколко седмици.
- Търсенето на проблема с висящите връзки подчерта някои възможни области за подобрение и опростявабе на процеса, ако нещо подобно се покачи отново и затова работим по актуализиране на qp2p и опростяване на неговото API.
- С този PR вече обединен, CLI-тп вече е в състояние да проверява баланса на собствения си SafeKey.
- Публикувахме нови версии на sn_authd (v0.0.15), CLI (v0.17.2) и sn_node (v0.25.39), като CLI и authd вече са изградени с помощта на MUSL за Linux.
Без публичен тест за момента…
Днес бяхме на ръба, докато сериозно обмисляхме дали да продължим да поправяме съобщенията, наградите и някои подобрения в qp2p (всички описани по-подробно по-долу) или да публикуваме публична тестова мрежа с всичко, което имаме досега. Решихме, че правилното решение е да продължим с поправянето и подобренията, при които така или иначе сме по средата, и затова задържаме публичната тестова мрежа за както смятаме още само няколко дни. Преценихме, че ще има твърде много отвличане на вниманието на екипа при настройването и поддържането на тестовата мрежа, плюс кода „може“ да е по-малко стабилен и по-труден при отстраняването на грешки, отколкото бихме искали, ако липсват корекциите и подобренията за съобщенията и qp2p. Забавяне също ни дава шанс да завършим и да включим подробно описания по-долу добив на нови монети монети 
във всяка публична тестова мрежа.
Работим за поправяне/подобряване на всичко и това работи добре за целеустремеността на екипа, така че забавянето на публичния тест засега с още няколко дни за подреждане на някои части ни изглежда правилно. Има някои страхотни подобрения на кода с участие на общността и всичко помага, чувства се определено движение в правилната посока.
Някои допълнителни общи новини тази седмица - ангажирахме стажант от Индийския Технологичен Институт, който ще се фокусира върху криптографията. Намерението е той да започне при нас през следващата седмица и незабавно да започне одит, тестване и като цяло проверка на сигурността във възможно най-голяма част от кода ни. Ще увеличим тези усилия значително в най-скоро време, докато навлизаме в режим на стартиране.
Safe клиент, възли и qp2p
Safe Network трансфери план на проекта
Safe клиент план на проекта
Safe Network възли план на проекта
Награди
Работата с награди продължи с опростяване на стартирането на секцията в sn_node, което сега изисква минималният брой Старейшини да съществува в секцията, преди да създаде разпределения актьор - известен още като актьор на секцията - отговорен за паричните средства на секцията.
С това на място вече стигнахме до въвеждането на изплащанията на наградите. PR черновата е преобразувана в завършен PR и се тества от P.O.V. клиент преди да обединим тази работа в главния клон след като тестовете преминат.
След това ще продължим с завършването на изплащането на наградите, като в този момент функцията за фермерство е горе-долу готова за включване в тестовата мрежа.
PR-и от общността
Тази седмица обединихме няколко PR-а, @mav изпрати един PR, който добавя някои липсващи функционалности към клиента, и още едно подобряване на ефективността на извикване на sequence.in_range.
Увисване на връзката
Продължихме да отстраняваме грешки във връзките и през изминалата седмица и най-накрая намерихме основната причина за проблема. Qp2p погрешно изпускаше връзки, които връщаха грешка. В този случай грешката беше валидна и не изискваше прекъсване на връзката. С обединяването на тази корекция вече не виждаме дълги изчаквания поради изгубени връзки, което е страхотно усещане 
. Носи се слух, че @joshuef е имал коса преди да възникне тази грешка!
Главният възел / клиент е много по-стабилен сега. Търсим някои появяващи се от време на време грешки, възникващи като част от съхраняването на пакети, където изглежда не успяваме да съхраним пакет и / или метаданни, свързани с него.
Опростено qp2p API
Неотдавнашният проблем с увисването на връзката в qp2p ни разкри, че API потребителят е поел много отговорности, като например поддържането на връзките и задържането на слушатели и потоци, в които съобщенията са входящи. Това го прави относително сложно за отстраняване на грешки, тъй като обработката на връзките е част от маршрутизацията и клиентските контейнери, които са пакетирани по свой собствен начин. Чрез преместване на поддръжката на мрежовите компоненти в qp2p контейнера можем да изолираме и тестваме множество сценарии и да гарантираме, че всички връзки и обработката на съобщенията се извършват правилно. Това в крайна сметка опростява и qp2p API-то, така че е печеливша стратегия. Стартирахме това преструктуриране в qp2p като доказателство за концепцията, за да предоставим опростено API за асинхронизация, което маршрутизацията и клиентите могат да използват за p2p комуникации.
API и CLI
Sn_api хранилището е видя много активност от членовете на общността тази седмица, което е отлична новина, особено защото тези приложения се използват от всички потребители и следователно колкото повече принос получаваме от реални крайни потребители, толкова повече можем да ги подобрим, дори по-добре, ако подобренията са действителен код!
@Latch работи по нова функция за въвеждане на команда reset в CLI, която може да ни позволи да изчистим всички данни и конфигурационни файлове, които приложенията CLI, sn_authd и sn_node съхраняват локално, запазвайки действителните програмни файлове недокоснати. Всеки, който се интересува от това да ни помогне, моля да се присъедини към дискусиите и прегледа на кода тук: WIP: feat(cli): implements 'safe reset' subcommand - #6 by bochaco - Core Libraries - Safe Dev Forum.
Някои подобрения, подадени от @mav в нашето API също са обединени, имаше някои грешки в съобщенията за грешки, които са коригирани, като е добавена и проверка при NRS имената за отхвърляне на наклонени знаци.
Някои примерни qjsonrpc приложения се разработват от @scorch (https://github.com/maidsafe/sn_api/pull/690), което ще помогне на потребителите да разберат как може да се използва qjsonrpc API-то и как приложения, нуждаещи се от JSON-RPC над QUIC протокола могат да бъде създадени. Информация за контекста на това е много добре описана в тази публикация за всеки, който се интересува да разбере повече за това.
С този PR, вече обединен, CLI-то е в състояние да проверява и баланса на собствения си SafeKey, т.е. с authd, което CLI използва за плащане на разходите за цялата операция, извършена от / с него. По този начин, чрез извикване на “$ safe ключове баланс”, без да предоставя своя таен ключ, сега по подразбиране проверява текущия баланс на CLI ключа / SafeKey.
Публикувани са нови версии на sn_authd (v0.0.15), CLI (v0.17.2) и sn_node (v0.25.39) за тези, които ги използват локално. Тъй като CLI и authd инсталационните файлове вече са изградени с помощта на MUSL за Linux платформи, ако сте на Linux моля, уверете се, че сте ги инсталирали, вместо да се опитвате да ги актуализирате с помощта на CLI, можете да намерите пълни инструкции за инсталирането им в CLI ръководството за потребителя.
BRB: Византийско надеждно излъчване
Тази седмица поправихме няколко грешки при валидиране, върнати от BRB DataTypes, и също така добавихме задълбочени коментари към документацията на всички BRB контейнери. Тези промени трябва да улеснят всеки, който желае да използва библиотеките.
Имаше доста дискусии за дизайна около интегрирането на BLS Distributed Key Generation (DKG) в BRB. Надеждата беше, че DKG ще може да се върне обратно към динамичните операции за членство (присъединяване / напускане) на BRB. В крайна сметка обаче установихме, че това не работи, тъй като DKG изисква 100% участие и трябва да се проведе като отделен процес след създаването на групата за гласуване на BRB.
Маршрутизиране
Тази седмица беше предимно тиха по отношение на реалните промени в кода на маршрутизацията, тъй като едната част от екипа беше заета да обсъжда алгоритмите BRB / DKG, а другата помагаше да се проследят проблемите с прекъсванията на връзката на клиента. Също така поставихме на задържане работата по подобряване на обработката на грешки, тъй като решихме, че първо трябва да се справим с по-належащи проблеми.
Въпреки това обединихме малък PR, който подобрява обработката на събитията. Имахме отделни събития за това кога се променят Старейшините на секциите и кога текущият възел се повишава или понижава. Оказва се, че тези неща се случват по едно и също време и обработката на събитията поотделно причинявс известно объркване в горните слоеве за това в какъв ред трябва да се обработват. Решихме го, като обединихме тези събития в едно събитие, като по този начин премахнахме объркването.
Също така започнахме работа за унифициране на обработката на първоначалното стартиране при възлите и при клиентите. Оказва се, че логиката за тяхното зареждане е абсолютно еднаква, но е внедрена по два малко различни начина на две различни места. Тази работа ще премахне дублирането, което ще доведе до по-опростен код. Очакваме да го завършим в началото на следващата седмица.
Преводи:
Английски; 
Russian ; 
German ; 
Spanish ; 
French
- Официален сайт на Safe Network
- Обобщено представяне на Safe Network
- Safe Network Фундаменти
- Карта на проекта
- Подробна информация може да намерите както винаги във форума на международната общност: Safe Network Forum
- Ако имате въпроси може да ги зададете във Facebook групата на българската Safe общност: Redirecting...
- Ако искате да следите последните новини заповядайте във Facebook страницата на Safe Network България: Safe Network България