Благодарим на всички, които взеха участие в DiskNet тестовата мрежа тази седмица. Въпреки „бързото непланирано разпадане“ (© SpaceX), ние наистина научихме някои ценни уроци от него и за щастие поправките не би трябвало да са твърде трудни. Също така открихме грешка, свързана с регистрирането, която вече е отстранена, така че ще бъдем напълно готови за следващата итерация.
Благодарности към общността
Благодарим на marcelosousa за техния PR за премахване на някои прекомерни резюмета на панела за преглед 
.
Благодарим на @mav за работата му досега за подобряване на ux портфейла 
Общ напредък
Щастливи сме да кажем, че скоковете на паметта и процесора, които видяхме в предишната тестова мрежа при качване на данни, изглежда са нещо от миналото, благодарение на промяна в кода за повторно публикуване на данни. @joshuef провежда тестове за това и поведението не се е повторило, така че стискаме палци това да е края му.
@bzee и @aed900 напредват с AutoNAT - откриването на възли зад домашни рутери/защитни стени. Те разучават регистрационните файлове на тестовата мрежа, за да открият потенциални проблеми и да работят върху това как AutoNAT може да ги смекчи.
Другото останало парче от пъзела е как да съхраняваме регистри. Начинът на libp2p достатъчно добър ли е за сега или трябва да измислим персонализирано решение? Същото важи и за DBC, но тъй като в този случай няма CRDT логика, те трябва да са много по-лесни. Това е, което @anselme и @bochaco разглеждат в момента, проучвайки плюсовете и минусите.
@qi_ma оптимизира процеса на повторно публикуване на данни. Това, което наистина искаме, е всеки път, когато има събитие за преместване в близка група (осемте най-близки възли, от към XoR гледна точка), тогава данните се публикуват повторно на всички нови държатели на данни. Освен че осигурява излишък, целта на това е да се гарантира, че таблиците за маршрутизиране, съхранявани от възлите, са винаги актуални. Начинът на libp2p не е съвсем подходящ за нас, тъй като е периодичен, а не управляван от събития, и може да бъде доста тежък. Обмисляме използването на това като предпазна мярка, във връзка с повече репликация, управлявана от събития.
Qi и @bochaco също ровят в проблемите със свързаността, възникнали по време на тестовата мрежа, които изглежда са причинени от паника в кода на RecordStore модула.
Свързано с това е повторното публикуване на данни при разделяне, което е малко по-сложно с регистрите. @bochaco създаде нов тест от край до край за проверка на целостта на регистрационните данни по време на събития на преместване на възел.
И @roland работи върху подобряването на процеса на регистриране в подготовка за следващата тестова мрежа. Дръжте си шапките. 
Преводи:
English 
Russian; 
German; 
Spanish; 
French
- Официален сайт на Safe Network
- Обобщено представяне на Safe Network
- Safe Network Фундаменти
- Карта на проекта
- Подробна информация може да намерите както винаги във форума на международната общност: Safe Network Forum
- Ако имате въпроси може да ги зададете във Facebook групата на българската Safe общност: Redirecting...
- Ако искате да следите последните новини заповядайте във Facebook страницата на Safe Network България: Safe Network България