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

SAFE Network новини – 14.11.2019

Накратко

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

  • Пуснахме версия v0.0.4 от приложението/програма SAFE Network. Основната промяна е добавянето на актуализации на приложенията, което означава, че можем да актуализираме приложения като SAFE браузъра чрез самото приложение на SAFE Network.
  • Пуснахме и малка актуализация на браузъра, която коригира още няколко проблема с разделителната способност на pWeb, някои промени във взаимодействието на SAFE Network App и позволяват да се задействат фонови актуализации от самото приложение на SAFE Network.
  • Първата RC версия на пакета MaidSafe.SafeApp NuGet вече е налична :tada:

Екип

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

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

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

Продължаваме да постигаме добър напредък с тестването на множество трезори. Тази седмица проектирахме и внедряваме нов RPC (Remote Procedure Call) механизъм в Трезорите, за да поддържаме заявки за информация за връзките. Това е една от важните стъпки, за да се позволи на клиентите да се свързват с мрежата без предварително познаване на IP адресите и публичните ключове на всички компютри в тяхната секция. Идеята е да е достатъчно да имате информация за връзка с поне един компютър в мрежата, който може да се използва за откриване на други компютри, управляващи определен клиент. Въвеждането на този механизъм би било и много полезно за свързване към многосекционната мрежа (Фаза 2б). Добавихме необходимото за това API към маршрутизацията.

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

SAFE API

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

Предвид новата версия на Rust (1.39) от миналата седмица, вече започнахме да мигрираме safe-api , за да може тези API-та, които са асинхронни (например тези, които трябва да комуникират с мрежата), да бъдат изложени като функции на асинхронизация async . Вече успяхме да направим това в API-тата и също така да направим корекции на safe-cli , за да чака ( await) при извикване на тези функции за асинхронизация. Все още трябва да направим съответните корекции в safe-ffi слоя, както и в реализацията на safe-api , където извикваме API-тата на safe_client_libs . Виждаме някои малки предизвикателства там, но като цяло досега този процес върви гладко. След като приключим с това, ще се стремим съответните Node.js свързаности на API-тата да върнат Promises .

Няколко допълнителни функции бяха добавени към safe-cli командите за удостоверяване. Когато използвате CLI или да създадете акаунт, или да влезете с помощта на съществуващ такъв, идентификационните данни на акаунта се подават към потребителя, като по този начин добавихме същата функционалност, която използва и safe_auth CLI-то , което дава възможност за осигуряването на създаване на акаунт / данни за вход чрез променливи на средата ( SAFE_AUTH_PASSPHRASE и SAFE_AUTH_PASSWORD ) или чрез конфигурационен файл с аргумент --config <filepath> . Това все още е в ход, тъй като се опитваме да адаптираме нашите тестове за интеграция на safe-cli в CI, за да работи заедно със safe-authd в един и същ PR.

В допълнение към това, подкомандата за вход auth login вече приема флаг --self-auth , който позволява на потребителя автоматично да удостовери CLI приложението в акаунта, в който е влязъл. Вярвахме, че това е необходимо в конкретния случай, сега, когато имаме SAFE Удостоверител процес, ако потребителят използва само CLI и никакъв друг потребителски интерфейс за удостоверяването, потребителят ще трябва да отвори втора конзола, за да упълномощи CLI от нея, което го прави не само объркващо, но и непрактично.

Накрая започнахме да добавяме повече документация към хранилището на safe-api , опитвайки се да обясним основната цел на всеки от контейнерите, които съдържа. Започнахме вече със създаването на документ (README) от най-високо ниво, който осигурява общо представяне и действа като показател за останалите контейнери. Това все още е в ход, но вече можете да разгледате напредъка, който постигнахме с най-високото ниво на документа README. Добавихме няколко диаграми, които се надяваме да са полезни, за да разберете как всички тези компоненти се вписват един с друг.

SAFE Клиентски библиотеки

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

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

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

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

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

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

Това е малка функция, но изискваше много тестове и настройки, за да работи на всички платформи. Последното парче от пъзела, което чакахме за да пуснем обновлението (още нотариално заверяване), е готово и натискаме големия бутон „ПУСКАНЕ“ на бюрото на @StephenC. Може да свалите версията от тук или от приложението SAFE Network след като ви предложи известие за актуализация, ако вече го имате инсталирано.

След като направите това, надяваме се че ще видите и налична актуализация за SAFE браузъра (ако имате инсталирана версия v0.15.2 през приложението SAFE Network), тъй като възнамеряваме да пуснем едновременно актуализирана версия и за него (вижте SAFE Раздела на браузъра по-долу!).

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

Имайте пред очи, че ако използвате версия v0.15.2 на SAFE браузъра, НЯМА да можете да актуализирате чрез приложението SAFE Network. Ще трябва или да деинсталирате / инсталирате чрез приложението SAFE Network, или да използвате отделната версия на SAFE браузъра. Опитът за актуализация чрез приложението на SAFE Network ще се провали, тъй като версия v0.15.2 не е в състояние да се актуализира на заден план.

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

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

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

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

Имайте пред очи, че ако използвате версия v0.15.2 на SAFE браузъра, НЯМА да можете да актуализирате чрез приложението SAFE Network. Ще трябва или да деинсталирате / инсталирате чрез приложението SAFE Network, или да използвате отделната версия на SAFE браузъра. Опитът за актуализация чрез приложението на SAFE Network ще се провали, тъй като версия v0.15.2 не е в състояние да се актуализира на заден план.

SAFE App C#

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

Наистина сме развълнувани да съобщим, че първата RC версия на MaidSafe.SafeApp NuGet пакета вече е налична. Пакетът разкрива всички нови API-та, налични в safe-api, и можете да го използвате, за да извършвате всякакви операции в SAFE мрежата, които са възможни с помощта на safe-cli .

Ще бъде прекрасно да видим какво ще разработите, използвайки този актуализиран пакет. Ако откриете някакъв проблем, моля, повдигнете проблем в GitHub и ако имате нужда от помощ с API-тата / разработката на приложения използвайки C #, моля, започнете тема във форума за разработчици и включете @ravinderjangra.

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

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

Стареене на възел (Node Ageing)

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

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

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

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

За да се улесни интегрирането с safe_vault , API-то е разширено, за да даде достъп до старейшините на секции.

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

Полезни линкове

Подробна информация може да намерите както винаги във форума на международната общност: SAFE Network Forum

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

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

1 Like

SAFE Network новини – 21.11.2019

Накратко

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

  • Пуснахме нова алфа версия на приложението SAFE Network.
  • @JimCollinson публикува някои идеи за това как може да бъде пуснат достъп до разрешенията за приложения и данни на крайните потребители (вижте секцията SAFE Network App UX по-долу).
  • Премахнахме емулацията на BLS и сега използваме истински BLS само в рамките на маршрутизирането.
  • Благодарение на члена на общността @danda е добавена нова функция в SAFE CLI, която позволява на потребителите да извличат съдържанието на всеки файл под формата на хекс файл (dump) :tada:

Срещи на общността

Днес се провеждат две срещи на общността.

Първата среща е в Малмьо, Швеция, и би трябвало да се провежда в момента! Срещата беше организирана от @oetyng.

Втората среща е в Брайтън, Англия и @dirvine ще присъства онлайн, за да даде на участниците информация за най-новите новини в MaidSafe и да отговори на въпроси.

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

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

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

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

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

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

SAFE CLI

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

Тъй като се приближаваме много близо до нови версии на safe-api и safe-cli , инвестирахме малко усилия в изготвянето на ръководство в основното safe-api хранилище, преместихме ръководството за потребителя на CLI в папката на safe-cli , както и добавихме ръководство за safe-authd . Включихме и няколко диаграми, които, надяваме се, ще ви дадат по-добра представа как всички тези компоненти се вписват заедно в екосистемата на SAFE приложенията от гледна точка на използващите мрежата.

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

Също така бяхме много доволни, че видяхме нова функция, внедрена от потребител в GitHub @dan-da (благодарим много @danda !!!), която позволява на потребителите да извличат съдържанието на всеки файл под формата на хекс файл използвайки команда cat --hexdump . Съответните инструкции също бяха добавени към ръководство за потребителя, където може да разберете повече за тази нова функция.

И накрая, също така започнахме да внедряваме JSON-RPC за комуникационния протокол на safe-authd . Трябваше ни прост формат, за да можем да изпращаме някои структури през QUIC, напр. цялата информация за заявките за удостоверяване или списъка с разрешенията, предоставени на всяко позволено приложение, и JSON-RPC позволява наистина лесно да сериализираме тези видове структури от данни с минимални разходи. Стремим се да поддържаме спецификацията JSON-RPC v2.0. Напреднахме доста с това през последните няколко дни, така че ще можем да го включим към първото издание на safe-authd .

SAFE Клиентски библиотеки

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

Тази седмица SAFE Клиентските библиотеки получиха своя дял работа. Преценихме, че създаването и поддържането на множество CI / CD платформи е голямо затруднение за екипа, тъй като те са склонни да се развалят от време на време. Затова решихме да опитаме новата вътрешна CI платформа на GitHub Actions, която се оказа доста ползотворна. Тя е по-тясно интегрирана с GitHub, по-гъвкава е и е доста бърза, въпреки че все още не сме настроили кеширането. Голямо благодаря към @chriso, @marcin и @StephenC за работа по стартирането на GH Action за SCL, safe-nd и safe-api.

Също така сме в процес на завършване на голямо преструктуриране на клиентски ключове. Тази работа ще приключи следните проблеми: #1060, #1053 - моля, вижте ги за повече информация. Това преструктуриране актуализира и версията на rand , която използвахме, като премахва много остарялата функционалност. Необходимият PR в safe-nd вече е прегледан и обединен, а PR в SCL е одобрен и чака CI.

Имаме доста работа, която ни чака по премахването на контейнера на Rust Sodium. За да дадем малко предистория тук, Rust Sodium е контейнер за крипто услуги, поддържащ повечето от алгоритмите ни за криптиране, които използваме в SAFE клиентските библиотеки и Само-криптирането. Причината за това оттегляне е, че Rust Sodium използва C зависимости, което е малко проблематично при настройването на CI / CD за контейнерите, които използват Rust Sodium. Затова планирахме да мигрираме далеч от този контейнер в нашите хранилища и да запълним празнината с подходящи контейнери. Задачите бяха зададени и работата по отделянето на Rust Sodium започна.

С успешното сливане на PR#1069 премахването на MaidSafe Utilities вече завърши. Незначителна промяна по конфигурационния файл работещ с API-тата трябваше да се направи като страничен ефект от това. Новите предоставени API-та са set_config_dir_path и config_dir . Те са основно функции за получаване и задаване за пътя, където се очаква да бъдат конфигурираните файлове (safe_core.config, vault_connection_info.config, log.toml и т.н.).

Незначителна поправка ще влезе в safe_authenticator с PR#1076. Това позволява на приложенията, които са повторно удостоверени да изискат нови разрешения за контейнери и да ги актуализират съответно в контейнера за достъп на потребителя.

SAFE Network програма UX

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

Степени на намеса

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

Без намеса

Разрешението е предоставено без уведомяване на потребителя.

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

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

Пасивна намеса

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

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

Например запазването на „UnpublishedData“ е с нисък риск за сигурността на потребителя, но има разходи за Safecoin.

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

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

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

55

И тук можем да видим някои от опциите за тези пасивни известия.

56

Ясно обособени, навременни намеси

Използването на приложение е блокирано, докато потребителят не предприеме действия.

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

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

Ето някои екрани, които да ви дадат представа как това може да работи:
0131b5e46d0ae6341fbd3d6825112e6b4b5f9065_2_690x395

Предварителни разрешения

Позволява на потребителя да избере предварително, какви разрешения ще има дадено приложение.

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

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

58

Активиране на полезни настройки по подразбиране

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

Ето пример за това как можем да предложим някои полезни предварителни настройки по време на създаването на акаунта:

59

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

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

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

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

Относно каналите за пускане на нови версии:

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

Ще има нормални версии. Те ще бъдат най-стабилни, а също и най-редки. Ако не сте готови да изпробвате нови промени / подобрения или да се включите чрез съобщаване на проблеми в GitHub, това ще бъде каналът на вашите версии!

Бета версиите ще бъдат малко по-чести. Ще бъдат нещо като предварителни версии, където може да има проблеми, но да се надяваме, че няма да има. Ако искате да проверите какво е новото и нямате нищо против случайните технически проблеми, това е за вас.

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

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

В момента за SAFE Network приложението все още е активиран канала за пускане за управлявани актуализации на приложенията. Но скоро ще го добавим (така че SAFE Network App Alpha ще инсталира само SAFE Browser Alpha).

Ако искате да пробвате новата алфа версия на най-новото приложение на SAFE Network, v0.0.5-alpha.2, можете директно да го изтеглите от GitHub тук. Моля опишете всички проблеми, които срещнете, в GitHub тук, за да ги проследим.

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

Новата настройка на канала за пускане, обсъдена по-горе, бе въведена с помощта на SAFE браузъра тази седмица. Тествахме вътрешно пускането на множество Alpha и Beta версии и с няколко редакции успяхме да потвърдим, че поведението на актуализацията между различните Alpha версии и между Alpha и Beta версиите е според очакванията. Сега когато сме готови с това ще пуснем нова алфа версия през следващите дни с актуализирани зависимости, включително незначителна electron поправка и обновление на safe-nodejs до версия v0.5.1.

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

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

Започнахме да надграждаме мобилния браузър, за да поддържаме новите версии на ОС Android и iOS. Това включва много трудна работа, като актуализиране на библиотеките, премахване на остарял код за използване на API и актуализиране на логиката на потребителския интерфейс, за да работи на всички устройства.

Миналата седмица пуснахме първата версия на пакета MaidSafe.SafeApp NuGet, а тази седмица започнахме да актуализираме браузъра, за да използваме новите API-та за Fetch и Inspect . С тези промени можем да разглеждаме уебсайтове от локални / споделени трезори.

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

Ранен преглед на функциите в процес на разработка:

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

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

Измина доста време откакто пуснахме нова версия на мобилното приложение за удостоверяване. С всички промени в API–тата на safe_client_libs и как да използваме локални / споделени трезори за тестване на приложения и уебсайтове, смятаме, че е време да обновим и Удостоверителя, за да осигурим поддръжка на всички нови подобрения.

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

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

SAFE App C#

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

Тази седмица направихме някои промени преструктурирайки API-то за извличане и проверка. Преди това тези API-та връщаха FilesMap (списък на файлове в FilesContainer ) като низ JSON и така разработчиците не бяха в състояние да използват езикови функции като запитване на данните, без да ги десериализират в C # типове.

След преструктурирането, сега разработчиците получават тип C # и могат директно да извършват всяка операция върху данните, без да извършват десериализация. Актуализирахме и тестове ни, за да гарантираме, че тези промени са стабилни.

Стареене на възел (Node Ageing)

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

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

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

BLS

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

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

Полезни линкове

Подробна информация може да намерите както винаги във форума на международната общност: SAFE Network Forum

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

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

SAFE Network новини – 28.11.2019

Накратко

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

  • @jimcollinson направи видео въведение към работата, която вършим по потребителското изживяване на Трезорите.
  • Финализирахме внедряването на JSON-RPC в протокола за комуникация authd .
  • Членът на общността @danda представи още една функция за внедряване в SAFE CLI, този път в подкрепа на два допълнителни формата за изхода на CLI (YAML и ясно изобразен JSON) :tada:

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

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

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

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

SAFE API

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

Тази минала седмица успяхме да финализираме внедряването на JSON-RPC в authd протокола за комуникация. Създадохме ново подхранилище за jsonrpc-quic контейнера в рамките на safe-api хранилището, което разкрива минимизиран набор от функции, които се използват от други контейнери за прилагане на процеса на Удостоверяващия протокол за комуникация. От една страна, safe-api го използва, за да може да изпраща JSON-RPC съобщения до authd чрез QUIC, а от друга страна authd го използва за приемане на тези заявки от клиенти, генериране на JSON-RPC отговор и изпращането му обратно чрез QUIC. Моля, погледнете safe-authd ръководството, за да видите някои примери за тези видове заявки / отговори.

Още една функционална реализация беше изпратена от @danda към safe-cli , този път за поддържане на два допълнителни формата за изхода на CLI. В допълнение към вече поддържания формат JSON (сега преименуван на jsoncompact ), CLI вече може да генерира своята продукция във формат YAML ( yaml ) или в ясно изобразен JSON формат ( json ). Тези нови формати могат да бъдат активирани с помощта на --output флаг във всяка CLI команда, например:

$ safe dog --output json safe://hbhyrydt5b95dmumcm8yig4u1keuuh8hgsr5yx39xn4mqikp91sbdhbpwp
[
  "safe://hbhyrydt5b95dmumcm8yig4u1keuuh8hgsr5yx39xn4mqikp91sbdhbpwp",
  {
    "data_type": "PublishedImmutableData",
    "media_type": "text/x-markdown",
    "xorname": "c761fec6b9ad8b382a6d4e4a44e7c3f0d626c0fcfde2d2dd5537f2b047c0b68d"
  }
]

Друг аспект, който беше в нашия списък със задачи от дълго време, и който най-накрая успяхме да създадем, е да имаме e2e тестов пакет, който може да се стартира като част от нашия процес на CI. Под e2e имаме предвид провеждането на тестовете ни срещу истински Трезор. Успяхме да настроим това при новата ни настройка за действия в GitHub, като автоматично изпълнихме всичките ни наши тестове за safe-api и safe-cli на CI. Това със сигурност ще ни даде спокойствие, когато обновяваме SAFE библиотеките в Safe-api, както и когато пускаме нови версии на трезори, ще проверяваме, че многото случаи на използване все още работят добре във всички слоеве на пирамидата, т.е. от safe-cli, през safe-api, safe-client-libs, маршрутизация и накрая трезорите. Нещо повече, вече открихме проблем при пускането на всички тези тестове за първи път на CI и вече го разследваме.

Новата версия на safe-api и safe-cli с новия safe-authd вече е неизбежна и точно финализираме необходимите промени в нашите CI скриптове, за да генерираме автоматично пакетите и да ги публикуваме както обикновено, така че се стремим да завършим това ново издание през следващите няколко дни.

Сега, когато първата версия на safe-authd е почти готова, ще можем да се съсредоточим повече върху дизайна и внедряването на API-тата на новите типове данни, както и върху някои нови идеи около посочените контейнери (известни като контейнери по подразбиране в Alpha 2) и как ще се поберат в новите API-та. Планираме да включим всички ви в дискусията както обикновено, така че бъдете готови за интересни технически дискусии (… знаем, че винаги сте :slight_smile:).

SAFE Клиентски библиотеки

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

През последната седмица екипът работи по премахването на зависимостта от rust_sodium , която причиняваше някои проблеми по отношение на поддръжката от доста време. Подхода ни към тази задача е на разделяне и завладяване и това ни помогна да постигнем добър напредък засега. Зависимостта ще бъде премахната от self_encryption в този PR. В SAFE Клиентските библиотеки мигрирахме подписване, симетрично криптиране и извличане на ключове в PR-ри #1093 и #1096. Остава да мигрираме и асиметричното криптиране и криптирането на публичния ключ, като и двете вече са в процес на работа. Уверени сме, че скоро ще приключим с това и ще продължим да подкрепяме развитието на следващата фаза на трезорите.

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

SAFE Network програма UX — Трезори

@jimcollinson направи видео представяне на работата, която вършим по потребителското изживяване на трезорите.

Check it out for a rundown on how you’ll be able to use one to create an account, or offer up your spare resources to earn Safecoin:

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

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

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

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

С тази актуализация ще преминем към бета версия на функционалността на удостоверителя. Единствената пречка, която имаме тук, която беше основен фокус през последната седмица, е подготовката на authd приложенията и CI представянето. Успешно настроихме процеса на изграждане на authd с помощта на действията на GitHub и трябва само да получим подписването на кода и нотариалното заверяване, настроени там, преди да можем да преминем към по-редовни актуализации както на authd , така и на safe-cli (което ще ни позволи да пускаме и нови версии на SAFE Network App също така!)

SAFE Network програма (мобилни устройства)

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

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

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

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

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

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

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

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

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

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

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

SAFE App C#

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

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

Стареене на възел (Node Ageing)

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

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

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

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

BLS

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

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

Полезни линкове

Подробна информация може да намерите както винаги във форума на международната общност: SAFE Network Forum

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

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

SAFE Network новини – 5.12.2019

Накратко

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

MaidSafe информация за заема

MaidSafe поиска заем от 10 милиона MAID от общността и в рамките на 24 часа получи предложения за повече от 24 милиона!

Предложението бе удвоено до 20 милиона предвид това и заявената сума беше разпределена между всичките 41 кандидат заемодатели.

Можем да потвърдим, че 39 трансфера са приключили; 1 кандидат вече не е в състояние да продължи, а на 1 беше дадено допълнително време поради лични обстоятелства.

Което означава, че получихме до момента около 19,8 милиона MAID от нашата общност. Нивото на подкрепа от вас е наистина смиряващо, благодарим!

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

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

И @qi_ma, и @jonhaggblad започнаха да работят върху Трезорите и вече направиха някои важни промени, служещи също като добро въведение в кода.

Ци промени Маршрутизирането, за да изложи неговата тестова quic-p2p функционалност. Тази промяна позволи да се премахне излишният тестови код в Трезорите.

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

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

Не на последно място пуснахме SAFE Vault v0.20.1. Той включва някои от последните промени и можете да го използвате, за да стартирате локален Трезор на вашата машина. Пълен списък с промени можете да намерите в списъка с промени.

SAFE API

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

С удоволствие днес споделяме новата версия на SAFE API-тата и CLI (v0.6.0)! Това издание е интересен крайъгълен камък, тъй като това е първото издание на Удостоверителя като системен процес (safe-authd), което означава, че премахваме CLI safe_auth и всички операции могат да се извършват от един интерфейс: SAFE CLI.

Можете да надстроите до новата версия, като използвате командата $ safe update , ако имате предишна версия в системата си, ако ли не просто я изтеглете от страницата на версията, от линка по-горе.

Ръководството за потребителя за CLI беше актуализирано с подробни инструкции за използването на safe-authd с CLI-то. Обърнете внимание, че тази версия на CLI-то и authd изисква най-новата версия (v0.20.1) на SAFE трезора, затова се уверете, че имате тази нова версия, ако искате да стартирате локален трезор.

През последните няколко дни успяхме да включим в това издание нова функция, която позволява превключване на мрежи / трезори с помощта на CLI. Това е много полезно за потребители, които управляват локален трезор, а също така използват споделения трезор, хостван от MaidSafe, позволявайки им да превключват напред и назад между тях. Обновеното Ръководство за потребители включва също конкретни подробности за това как работи тази команда, така че, моля, вижте раздела Мрежи в Ръководството за потребителя, за да научите повече за нея.

Публикувана е и нова версия на пакета safe-nodejs (v0.6.0), която подобрява зависимостта си със safe-api . Тази нова версия позволява на приложенията SAFE Node.js да изпращат заявки за упълномощаване до процеса на Удостоверителя, използвайки своя нов комуникационен протокол (JSON-RPC чрез QUIC), вместо системния URI механизъм, който използвахме досега. Въпреки че всичко това е прозрачно за приложението, тъй като за всичко се грижи едно и също API на auth_app .

Дефиниране на минималното устойчиво изживяване

Често използваме термина „Минимален жизнеспособен продукт“ (MVP), когато се опитваме да опишем върху какво работим и какво остава да се направи преди раждането на жива дишаща автономна мрежа. Този вълшебен ден.

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

Така че нека го изложим тук.

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

Когато имаме MVP, можем да имаме мрежа.

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

Трябва да направим повече от това, ако искаме мрежата да бъде достатъчно жизнена за успешно стартиране. Заради това смятаме да създадем Минимално устойчиво изживяване (Minimum Viable Experience - MVE).

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

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

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

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

Плоски данни и етикети

Сред всичките ни разработки и UX проучвания няколко пъти възниква въпросът за структурите на данните и възможността да имаме по-плоска структура на данните. Проучваме тази идея в темата за Етикетите на данни предварително-RFC.

Идеята е подобна на това както си представяхме „контейнерите“ за приложения преди, но увеличава гъвкавостта, като все пак дава на разработчиците на приложения лесни начини да открият / управляват данните на приложенията. Ако работи както си го представяме това също така ще послужи за предотвратяване на затварянето на потребителските данни в контейнери за приложения (представете си, че две различни приложения за снимки не знаят за снимките в другото приложение), като същевременно ще постигне някои други изключително необходими функции на MVE (общо индексиране на потребителските данни) ).

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

SAFE Клиентски библиотеки

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

Считано от PR # 1102, rust_sodium вече е напълно премахнат и SAFE Клиентските библиотеки вече са освободени от директни зависимости от C :tada:. Различните криптографски механизми, използвани по-рано от rust_sodium, вече са пренесени в чисти Rust контейнери, като prag_crypto и miscreant. Това дава на използващите SAFE Клиентските библиотеки безпроблемно изживяване без да трябва да се занимават със зависимостите от C.

Това също отваря вратите за използване на нови платформи като MUSL и wasm, които преди това бяха блокирани поради тази болезнена (но доста полезна) зависимост. С приключването на тази голяма част от работата, екипът ни вече може да се съсредоточи върху техническите аспекти на предложението за етикети на данните и Фаза 2 на Трезорите. Успоредно с това екипът подготви и пусна нова версия на Клиентските библиотеки. Имайте пред очи, че това издание няма последните промени от основния код. Изданието беше направено от по-стара версия, която е съвместима със SAFE CLI. Затова следете за ново издание, такова без rust_sodium :wink:.

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

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

Щастливи сме да споделим първата версия на програмата в бета канала! Като бета версия, тя е по-стабилна от алфа изданията ни (от които ако сте забелязали имаме много…) и поправя няколко проблема, докладвани от общността под Windows, както и някои други нередности, които открихме в процесът на пускане / актуализация както за SAFE Network App, така и за браузъра.

Така ако искате да останете в бета канала (и да виждате само по-стабилните бета версии), трябва да го изтеглите от страницата на изданието в GitHub. В противен случай, ако искате да използвате най-новите алфа версии, може да свалите алфа.20. Ще се наложи да я изтеглите отново. Поради гореспоменатите проблеми с автоматичното актуализиране.

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

Единствените други забележителни неща от тази версия са, че SAFE Network програмата вече ще има канал с изпълнително име (например SAFE Network App Alpha ) и че версията на канала ще работи със същия канал от програми. Така SAFE Network App Alpha ще изтегли / управлява SAFE Browser Alpha. Това е логически издържано и помага да се премахнат някои неясноти, когато се работи с каналите за пускане на нови версии.

Трябва да отбележим за потребителите на Ubuntu, че видяхме проблеми около свързването на libsodium с най-новата актуализация 19.10. Няма да има поправка от наша страна, тъй като libsodium ще се премахва скоро така или иначе! Което означава, надяваме се, това да е последното издание, което ще има тези проблеми (подобно на нещата отбелязани по-рано за macOS Catalina). Междувременно трябва просто да се уверите, че имате налична версия на libsodium, ако се натъкнете на този проблем.

SAFE Network програма (мобилни устройства)

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

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

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

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

Актуализирахме браузъра с новия пакет safe-nodejs . SAFE Browser v0.15.4-beta.1 може да бъде изтеглен от тук. Наред с актуализациите на API-то, това издание има същите подобрения на работния процес като SAFE Network програмата по отношение на GitHub Actions, както и някои актуализации на малки зависимости и други промени в CI.

Има и алфа версия, достъпна за сваляне от тук.

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

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

Актуализирахме мобилния браузър, за да поддържаме Android 10 и преструктурирахме част от основния Android код, за да използваме новите API-та на платформата. Следващата седмица ще актуализираме и поддръжката за iOS до последната версия на iOS. Актуализирахме и множество остарели зависимости за по-добра производителност и по-малко грешки. След като всички промени са направени, ще тестваме цялостно приложението, за да гарантираме правилното функциониране.

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

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

Актуализирахме приложението за удостоверяване, за да използваме най-новите основни библиотеки на safe_authenticator от SAFE Клиентските библиотеки. Премахнахме и кода за свързване на всички остарели API-та.

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

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

Стареене на възел (Node Ageing)

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

Работата по повишенията (възрастни към старейшини) и пониженията (старейшини към възрастни) (PR 1929) непрекъснато напредва. Идентифицирахме и отстранихме редица проблеми благодарение на богатия ни набор от тестове. Изглежда ни остават само два основни нерешени проблема, преди тази работа да може да бъде обединена в Алфа 3 клона.

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

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

BLS

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

Aside from some progress on signature combination being correctly handled, we’ve paused work on these issues and PRs to focus on Node Ageing and Vault until (PR 1929 ) can be merged.

Освен напредъкът в комбинацията с подписи, които се обработват успешно, поставихме на пауза работата по тези проблеми и PR-и, за да се съсредоточим върху стареенето на възлите и Трезорите, докато (PR 1929) не бъде обединен.

Полезни линкове

Подробна информация може да намерите както винаги във форума на международната общност: SAFE Network Forum

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

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

SAFE Network новини – 12.12.2019

Накратко

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

  • Споделеният Трезор е актуализиран до последната версия и съответно изисква нов конфигурационен файл.
  • Разглеждаме по-подробно как можем технически да приложим Данни с етикети.
  • В CLI бяха внедрени някои незначителни подобрения, като например възможността да се използва CLI в режим само за четене при заявяване на публични данни.
  • Членът на общността @danda представи друга функция за изпълнение, за да позволи на командата files add да чете съдържанието на файла, който се добавя от stdin (вместо от локален път).

Обновяване за Споделения трезор

Днес актуализирахме Споделения трезор от версия 0.19.2 до версия 0.20.1. Както винаги, всяко рестартиране на трезора означава нов конфигурационен файл за него, така че качихме последния конфигурационен файл в S3 тук. Ако искате да използвате Споделения трезор, моля, изтеглете този файл и го запишете на подходящото място на компютъра ви. Обърнете внимание, че решихме да извадим конфигурационния файл на трезора от GitHub и да го хостваме в S3, така че той не се отнася до нито една конкретна версия на GitHub.

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

Важна забележка - в SAFE трезора версия 0.20.x форматът на данните е несъвместим с формата на данните от версия 0.19.x, следователно новият Споделен трезор, който стартирахме, е изчистен, без данни в него. Ако имате локален трезор, работещ с версия 0.19.x и надграждате до 0.20.x, ще откриете, че данните от този трезор не се показват както се очаква. Препоръчваме да качите отново всички данни / сайтове и т.н. в новия трезор, локален или споделен.

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

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

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

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

SAFE API

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

След пускането на версията от миналата седмица, през последните няколко дни се фокусирахме върху технически задачи, който ни бяха останали за довършване в хранилището на safe-api. Например актуализирахме скриптовете за публикуване, за да пускаме само файлове за свързване към истински трезор, тъй като вече няма да публикуваме файлове за използване на тестовата мрежа в Safe-api версиите ни. Използването на тестовата мрежа все още е възможно, но разработчиците, желаещи да направят това, ще трябва сами да изградят артефактите, следвайки инструкциите от съответните README файлове.

Успяхме да надстроим до последния версия в хранилището safe_client_libs, което ни позволява да активираме отново тестове от край до край (e2e) в CI процеса. Автоматичните тестове за safe-cli вече ще се изпълняват в GitHub Actions (GHA) за всеки PR, както беше преди в Jenkins. Тази първа група от e2e тестове все още използва тестовата мрежа, но вече имаме всичко готово да ги стартираме и с локален трезор в GHA, веднага щом открит проблем (очевидно в трезора) е решен.

Някои незначителни подобрения също бяха внедрени в CLI, като например CLI да може да се използва в режим само за четене, когато се работи с обществени данни. Например използването на командата cat или dog на публичен уебсайт няма да изисква CLI-то да бъде упълномощено. Това е хубава стъпка по отношение на UX, тъй като потребителят може да иска да работи с публични данни от мрежата с помощта на CLI и няма да е необходимо да се логва в системата и / или да упълномощава CLI за това, което го прави толкова лесно, колкото разглеждането на обществени данни от SAFE браузъра.

Друга реализация на функция, представена от @danda през последните няколко дни, беше да се даде възможност на командата files add да чете съдържанието на файла, който се добавя от stdin (вместо от местен път). Това отваря възможността за използване на командата files add във верига от команди, което е нещо, което @danda също проучва, за да определи подходяща стратегия за всички команди в CLI.

И накрая, започнахме да разглеждаме добавяне на функция, предложена от общността, чиято цел е да можем да получаваме XOR-адреси на файлове, без да ги качваме в мрежата, т.е. да разширим --dry-run опцията да работи с файлове, а не само с контейнерите им когато се изпълняват командите files put или files sync . Работим върху добавянето на такава възможност първо в SAFE Клиентските библиотеки, така че след това да можем правилно да дадем достъп до нея от safe-api и CLI, заедно с нова safe xorurl команда от най-високо ниво, която да може да предоставя такава информация директно за локални файлове / папки.

SAFE Клиентски библиотеки

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

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

Междувременно помагаме и на останалата част от екипа с Етикетите на данни RFC. Все още сме в началните фази на дискусията и вече има много коментари. Присъединете се към нас в конкретната тема, ако още не сте го направили.

На CI / CD фронта напълно пренесохме нашата работа в GitHub Actions и пуснахме най-новите версии на библиотеките ни. Обърнете внимание, че новите версии на контейнерите все още не са публикувани. Публикуването на нови версии и на трите контейнера (SAFE Core, Authenticator и App) е доста просто. Търсим подход, при който бихме могли селективно да надстройваме конкретни контейнери. Това е последната стъпка към първоначалната миграция към GitHub Actions. Ще търсим начини да подобрим скоростта на изграждане, като използваме кеширане и т.н.

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

Етикети за данните и споделяне

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

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

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

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

SAFE Network програма (мобилни устройства)

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

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

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

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

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

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

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

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

Стареене на възел (Node Ageing)

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

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

Полезни линкове

Подробна информация може да намерите както винаги във форума на международната общност: SAFE Network Forum

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

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

SAFE Network новини – 19.12.2019

Накратко

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

  • Пуснахме нов предварителен преглед на NuGet пакет за MaidSafe.SafeApp :tada:
  • Направихме нова бета версия на SAFE браузъра.
  • Приспособихме се към BLS-базиран подход за пренасяне на маркери за Етикетите на данните RFC.
  • Обмисляме да променим начина, по който аргументите на източника и местоназначението се третират от командите files put / files sync . Моля, присъединете се към нас в дискусиите по този въпрос в GitHub или в тази тема във форума.

Честито ново деситилетие!

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

Връщането към един екип и дори повече от това, фокусиран, всеотдаен екип има много, много хубави ползи. Ние сме по-фокусирани върху цялата мрежа, можем да говорим по-равно и открито и най-вече можем да се забавляваме малко повече на събиранията ни. По-малко бюрокрация и липсата на “политически” игри означава, че можем просто да се съсредоточим 100% върху това, което е важно, SAFE мрежата. Като цел, това е доста голямо усилие и само това е единствената ни цел сега. Не как да я промотираме на пазара, не как да управляваме отдели или да провеждаме междуведомствени срещи и така нататък, а как да дадем на света SAFE мрежата.

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

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

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

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

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

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

В същото време @lionel.faber и @yogesh документираха предварителните проекти за Фаза 2Б (проектът с множеството секции), като започнаха с писането на документацията за съществуващите потоци от заявки. С това трябва да подобрим нашето разбиране за обхвата на работата, необходима да се извърши при Трезорите, за да поддържаме мрежовата комуникация между множество секции.

Също така започнахме да проучваме надстройката на quic-p2p до най-новата версия на Quinn, основна библиотека на QUIC протоколa, която използваме за нашия мрежов слой. Това надграждане трябва да подобри стабилността, съответствието с най-новите тестови версии на QUIC протокол стандарта и по-важното е, че ще внесе код за асинхронизация / изчакване в quic-p2p. Асинхронизация / изчакване е нова синтактична функция, която наскоро беше стабилизирана в Rust 1.39. Тя ни позволява да пишем бърз и ефикасен код по рационализиран начин. Въпреки че все още не правим пълен преход към новия стил на асинхронизация / изчакване, видяхме някои значителни подобрения в яснотата на кода в quic-p2p. Тази промяна трябва да доведе до намаляване на когнитивната сложност, което ще улесни допринасянето ви с код в нашите проекти. В крайна сметка тази промяна в quic-p2p също ще ни позволи да започнем да разпространяваме този кодов стил и в SAFE Клиентските библиотеки и така нататък.

SAFE API

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

През миналата седмица обединихме няколко PR-а, за да подобрим и опростим нашия CI процес за safe-api хранилището. След преминаването ни към GitHub Actions, и пълното премахване на Jenkins и Travis, трябваше да финализираме и изчистим някои от CI скриптовете. Най-важният аспект на тези задачи беше свързан с гарантирането, че все още можем да генерираме safe-ffi библиотеки с обединяването на всеки PR, тъй като активно се използват от нас за разработване на езиковите връзки и мобилни приложения.

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

Успяхме да финализираме реализацията за генериране на XOR-URL адреси за файлове, без да ги качваме в мрежата, както за реализацията в safe_client_libs , така и в тази, която да изложи такава функция от safe-api и safe-cli . Към CLI ще добавим и нова команда $ safe xorurl , като просто ни остава да пишем няколко допълнителни теста и да актуализираме Ръководството за CLI, преди да обединим съответните PR-и, които ще позволят тази функция.

Що се отнася до следващите стъпки в safe-api хранилището в следващите дни, всичко което правим ще е свързано с възможността да направим safe-authd обновяващ се от CLI-то, тъй като знаете, че с $ safe update можем да обновим safe-cli до последната версия, така че ще работим върху създаването на команда, която да ни позволи също така да обновим safe-authd по аналогичен начин.

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

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

RFC

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

Същността на идеята е, че ви се предоставя подписан жетон, който може да съдържа различни ограничения за използването му (за определени етикети, през определено време, само за тези URL адреси … това ни дава голяма гъвкавост) и може да бъде валидиран както в ClientHandlers срещу заявката, която програмата прави, така и при обработващите данни, срещу разрешенията на самите данни (включително етикетите).

Работейки с BLS по този начин, ние все още можем да активираме споделени данни и се опитваме да разширим подхода, базиран на маркери, за да можем сами да предаваме маркери за споделяне на данни (и така да ни даде възможност да кажем например: „можете да получите достъп до тези данни, но само за следващите 2 дни“).

За тези, които се интересуват от техническите характеристики на това, моля, преминете към RFC, прочетете, коментирайте и задайте въпроси! Всичко помага :bow:!

SAFE Клиентски библиотеки

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

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

От страна на инфраструктурата, изгладихме грешките в публикуването на автоматизираните ни версии и внедрявания, които наскоро добавихме към GitHub Actions, за да ускорим процеса на пускане. Освен това добавихме кеширане към GHA, което в някои случаи води до 50% намаление на времето за изграждане. Също така сме в последните етапи за пълно премахване на Docker от SAFE CLI. Следващите ни цели в GHA са да намалим многословието (вероятно чрез прилагането на собствената ни библиотека с персонализирани действия) и след това да разгърнем промените във всички наши хранилища, замествайки Travis и Appveyor навсякъде.

SAFE Network програма (мобилни устройства)

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

Тази седмица покрихме още малко от основата на стилистичния и тематичния фронт и подобрихме потребителския интерфейс за двете платформи (Android и iOS). Съсредоточихме се върху привеждане на повече стилове от дизайна към програмата и потребителският интерфейс се оформя прекрасно. Можете бързо да погледнете тези два PR-а (#29, #28) за да добиете представа.

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

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

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

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

Започнахме и ъпгрейда до Electron 7, който включваше актуализиране на нашата TestCafe версия (и еднократно PR до тяхното хранилище, така че да сме в крак с последните им промени). За съжаление попаднахме на греда в Electron, където бъг грешно хвърля грешка при получаване на отговори с код различен от 200 (което означава, че нашите полезни страници за грешки никога не се показват). Изглежда, че има решение за това, което вече се подготвя, просто не е добавено в новото издание на Electron 7.x, така че веднага щом го имаме, можем да обновим браузъра до най-новата версия.

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

През последните няколко седмици се сблъскваме със сривове при iOS устройства, докато версията за Android работеше отлично. Този проблем със забиването на приложението беше решен тази седмица чрез актуализиране до най-новия пакет за преглед. Актуализирахме приложението, за да използваме някои нови API-та и съответно променихме кода. С разрешаването и на проблема за срив при отстраняване на грешки в приложението (повече подробности в секцията SAFE App C # по-долу), вече можем да продължим и да напреднем със задачите за предоставяне на първоначалните функции на pWeb и при мобилните устройства.

SAFE App C#

Днес пуснахме нов предварителен преглед на NuGet пакета за MaidSafe.SafeApp :tada: . Този пакет включва множество корекции, нови API-та и някои преструктуриращи промени.

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

Също така добавихме и тествахме ново AuthAppAsync API за да подобрим процеса на разработка. Програмистите могат да използват това API в своите C# десктоп приложения и потребителите ще могат да удостоверяват приложенията с safe-cli и процеса на удостоверяването. В следващите седмици ще подобрим това API, за да предоставим същата функция и за мобилни устройства.

Стареене на възел (Node Ageing)

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

Тази седмица приключихме с големия PR, над който работихме от известно време. С добавянето на първоначалната работа по повишаване / понижаване, вече имаме основните компоненти на Стареенето на възлите: Фиксиран брой на Старейшините в секцията и останалите възли като Възрастни.

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

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

Полезни линкове

Подробна информация може да намерите както винаги във форума на международната общност: SAFE Network Forum

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

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

SAFE Network новини – 9.1.2020

Накратко

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

  • Честита Нова година и нека всички имаме успешна 2020 година!
  • @danda се присъедини към екипа ни :tada:
  • @oetyng сподели подготвително RFC за Прецизиране на типовете данни (Data Type Refinement). Моля, прочетете го и споделете какво мислите!
  • Командата safe files add вече приема съдържание на файл от stdin, което позволява да се изпращат последователно други команди и да се качват нови файлове в мрежата.
    Ръководството на потребителя за CLI бе актуализирано с нов раздел за safe xorurl командата.
  • Започнахме работа по ранната концепция и дизайн за добив и дистрибуция на Safecoin.

Подбор на персонал

С радост приветстваме @danda в екипа ни! Най-вероятно ще разпознаете неговото име, тъй като той е активен сътрудник в хранилището на safe-api вече почти два месеца! Първоначално той ще работи с @oetyng върху концепцията за добив на Safecoin - вижте първия му принос по долу в новия раздел от новините за Safecoin фермерството.

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

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

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

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

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

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

SAFE API

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

През последните няколко дни се фокусирахме върху финализирането на няколко PR-а, които започнахме преди почивката в края на годината. PR, подготвен от @danda миналата година, беше обединен, което позволява на командата safe files add да приемат съдържанието на файл от stdin, което позволява да се добавят последователно други команди и да се качват нови файлове в мрежата.

Друга функция, която започнахме преди няколко седмици (предложена от общността в този форум) и вече обединена, беше включването на нова подкоманда safe xorurl за CLI-то, което е полезно, когато желаем да изчислим XOR-URL адресите за локални файлове , без да е необходимо да ги качваме в мрежата. Ръководството за потребителя за CLI беше актуализирано с нов раздел за тази нова команда. Имайте пред очи, че засега тази команда изисква CLI-то да бъде упълномощено, като планираме да я подобрим в бъдеще, за да премахнем това ограничение.

safe-authd беше основният фокус през последните няколко дни, тъй като командата й за актуализация не работи и следователно не е възможно да се актуализира по същия начин като CLI. Започнахме да поправяме това, като добавихме поддръжка за AWS S3, когато решаваме откъде да извлечем новите версии, тъй като там публикуваме качваме новите инсталационни версии на safe-authd . Планираме също така да започнем да използваме S3 и за инсталационните файлове на CLI-то, тъй като за потребителите ще е по-бързо изтеглянето им, отколкото от страницата ни в GitHub.

След като оправим safe-authd да може да бъде актуализирано, ще добавим няколко нови подкоманди към CLI-то, за да можем да инсталираме и актуализираме процеса на Удостоверителя, като автоматично издърпаме съответния инсталационен файл от S3. Това ще подобри и опрости UX за потребителите на CLI и authd.

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

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

@joshuef увеличава работата си в SAFE Клиентските библиотеки, научава кодовата база и прави началото на основната реализация на оторизирането на маркери и тяхното интегриране в кодовата база.

Засега имаме проста настройка на жетони / маркери на макаруните. Интегрира ме го в SAFE Клиентските библиотеки по-солидно, използвайки съществуващата ни настройка за AppKeys за подписване на маркера и валидиране, което би трябвало да опрости нещата в бъдеще.

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

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

RFC

@oetyng написа нов RFC за консолидиране на различните типове данни и промените, които са претърпели по време на разработката. Освен това RFC-то въвежда и по-прости имена за типовете данни. Дискусиите вече започнаха във форума, така че вижте темата и кажете какво мислите.

SAFE Клиентски библиотеки

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

Завършихме 2019 г. с невероятен принос от общността към кодовата база на Клиентските библиотеки, който ни помогна да наваксаме с изоставането си. Добавихме и някои малки, но полезни функции, които биха били от голяма полза в слоевете на програмите в CLI, настолните и мобилните платформи. Някои от тях са: поддържане на тестов цикъл при съхранение на неизменни данни, повече информация при извличане на списъка с приложения от удостоверителя и поддръжка на константата GET_NEXT_VERSION за операции с променими данни.

През последните си няколко седмици в MaidSafe - @marcin се съсредоточи основно върху завършването на останали задачи, преглед на PR-и и приключването на останалите си ангажименти. Това включва някои инфраструктурни работи, като поправки за CI и GitHub Actions. Той добави и нова документация в уикито на SCL.

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

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

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

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

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

SAFE Network програма (мобилни устройства)

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

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

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

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

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

Актуализирахме минимално поддържаните версии на платформата за Android и iOS. Сега минималната поддържана версия за Android е 5.0+, а за iOS е 11.0+. С тези промени приключихме разработката на всички желани за момента функции / промени от текущия план на проекта и целта ни е да пуснем приложението през следващите седмици :smile:.

SAFE App C#

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

Библиотеката safe_app_csharp беше актуализирана до най-новите промени в основния клон на safe-api и C # публикуваните неизменни данни, поставени от API-то, сега поддържа флаг с изпълнение на “сухо”. В момента се сблъскваме с проблем при връзките, когато се опитваме да декодираме съобщението в отговор на заявката за удостоверяване. След като бъде отстранена тази грешка, ще пуснем нов основен пакет.

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

Safecoin фермерство

RFC

Започнахме работа по началната концепция и дизайн на фермерския добив на Safecoin, както е описано в RFC-0057.

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

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

Стареене на възел (Node Ageing)

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

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

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

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

Полезни линкове

Подробна информация може да намерите както винаги във форума на международната общност: SAFE Network Forum

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

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

SAFE Network новини – 16.1.2020

Накратко

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

  • Със следващата версия на safe-cli ще можете да инсталирате authd , като просто въведете командата $ safe auth install , а за да актуализирате с командата $ safe auth update .
  • През изминалата седмица различни предложения от общността бяха включени в най-новата версия на RFC за уточняване на типове данни.
  • Приключихме с BLS проекта, както и със Сигурната доставка на съобщения, за която липсваше само зависимостта от BLS, и актуализирахме картата на проекта :tada:

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

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

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

Въпреки това имаше и някои проблеми. Някои от тестовете не успяха и върнаха грешка RequestTimeout , тъй като секцията не успя да отговори на някои от заявките. Проучваме това и с някои проверки вече имаме повече информация. Трезорите се работят от виртуални машини в DigitalOcean и докато обработват редица едновременни заявки, процеса на Трезора понякога се спира от OOM Killer поради необичайно използване на паметта.

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

SAFE API

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

Завършихме с добавяне на поддръжка за изтегляне на нови версии от Amazon S3, което беше необходимо safe-authd файловете. Safe-authd вече може да се самоактуализира, като проверява текущата си версия спрямо най-новата версия, налична в S3. Това е готово за добавяне и публикуване, просто чакаме новата версия на зависимостта, която използваме (self_update) за такива актуализации, която трябва да бъде налична скоро.

Възможността за изтегляне на safe-authd версиите от S3 ни позволи да добавим няколко команди към safe-cli за инсталиране и актуализиране на safe-authd , което много опростява процеса за потребителите. Със следващата версия на safe-cli ще можете да инсталирате authd , като просто въведете командата $ safe auth install , като ще можете лесно да актуализирате authd с $ safe auth update .

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

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

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

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

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

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

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

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

Различни предложения от общността през изминалата седмица бяха включени в най-новата версия на RFC-а. Благодарим на @david-beinn, @tfa, @JPL, @dask и @jlpell за приноса им, както и на многото други за участието им в дискусиите.

SAFE Network програма

Тази седмица SAFE Network App функцията за проследяване пулсираше усилено, докато работихме върху UX дизайна на индивидуалните разрешения за данни на файловете и приложенията.

Това е една от онези области, които започват като изглеждат доста прости - „ Да, ще се справим с това за ден или два “ - и тогава сложността бързо се разгръща - „ О, не:open_mouth:, и след като се мине през итерациите се стига до простото - „ Отне ви колко време?:sweat_smile:.

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

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

SAFE App C#

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

Тази седмица направихме някои подобрения в нашата настройка за CI-то. Тези промени позволяват на CI автоматично да създаде черновата версия в GitHub от пътя за пускане на нови версии, когато се повдигне PR за промяна на версия. Използвайки същата настройка, пуснахме нов RC (Кандидат за пускане - Release Candidate) на пакета MaidSafe.SafeApp NuGet.

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

Имахме различни инструменти и проверки, за да наложим стандартите за кодиране в кода safe_app_csharp , което изглеждаше излишно и правеше кода по-сложен при писане и разбиране. Така че реконструирахме кода и го направихме по-прост и чист.

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

Safecoin фермерство

RFC

Тази седмица @danda написа малка симулация на потока за възнаграждение на фермерството в тестова мултисекционна мрежа с много трезори, започваща с PUT заявка (заявка за качване) на един клиент. Симулацията е написана на интерпретиран език като бърз / груб инструмент за бързо прототипиране и обучение без планове за публично пускане. Наблюденията и информацията, извлечени от това, влизат в бележките / дискусиите ни и в крайна сметка ще влязат в документацията за изработка. Той също започна диаграмиране на потока за фермерство и започва нов RFC документ, специфичен за възнагражденията при фермерството, който има за цел да осигури повече специфики и яснота.

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

Стареене на възел (Node Ageing)

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

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

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

BLS

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

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

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

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

Полезни линкове

Подробна информация може да намерите както винаги във форума на международната общност: SAFE Network Forum

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

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

SAFE-Fleming: Следващата голяма стъпка

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

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

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

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

Защо SAFE-Fleming е толкова важен?

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

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

Докато напредваме през следващата поредица от версии на мрежата, ще стане очевидно колко мощна е технологията. Ще видите компютри в SAFE мрежата, които комуникират чрез Crust, пробивайки през защитните стени и рутерите, които спират други технологии. Ще направим по-лесно за хората да разберат нашия разтърсващ механизъм за консенсус по ABFT - PARSEC, докато завършваме внедряването му в SAFE мрежата.

SAFE мрежата е без централен контрол. Никой не може да бъде възпрепятстван да се присъедини. Вижте как мрежата реагира на злонамерени възли, които искат да я подронят. Погледнете също и за Стареенето на възлите ( Node Ageing) , начина, по който мрежата автономно дава приоритет на възлите, доказали се като надеждни във времето, създавайки жизненоважна защита срещу Sybil атаките и други опити за измама на системата.

И ако това не е достатъчно, ще покажем и значителен напредък в сферата на децентрализация, което представлява трудност на множество други проекти. С динамичното членство ( Dynamic Membership) ще видите, че мрежовите възли на мрежата се присъединяват и напускат свободно, докато се запазва консенсус. А с Disjoint Sections, ние не само ще покажем как Sharding е възможен, но ще го покажем и на практика работещ, много по-напред от другите блокчейн проекти борещи се за въвеждането му.

Също така ще видите, че мрежата решава проблема със защитените комуникации между различните части (shards). Ние наричаме това Сигурно предаване на съобщения ( Secure Message Relay) и това е друг проблем, който все още не е решен от най-големите децентрализирани крипто проекти в света.

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

Можете да разберете защо сме развълнувани …

Стартирането на SAFE-Fleming

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

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

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

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

Затова моля, присъединете се към нас в това все по-вълнуващо пътешествие с всяка нова версия! Разбира се, междувременно можете да проверите ежеседмичните актуализации на Thursday Dev в SAFE Network Forum (Updates - Safe Network Forum).

И както винаги, благодарим Ви за подкрепата.

Следва: SAFE-Fleming (част 2): Динамично членство

Пазим 2018 SAFE и SOLID

Може да сте забелязали повтаряща се тема тази година около екосистемата на SAFE мрежата. Разговорите около притежаването на информацията набират скорост. Може би сте били на (или гледали) SAFE DevCon 2018. Или може би сте се натъкнали на подкаст дискутиращ думи като RDF и Социално Свързана Информация (Socially Linked Data).

Думата ‘Solid’ се появява все по често в разговорите — но защо? И как това се отнася към SAFE Network?

SAFE мрежата разбира се се отнася до 3 неща:

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

SOLID (съкратено от ‘Социално Свързана Информация’), от друга страна е проект започнат от сър Тим Бърнърс-Лий, който определя комплект от стандарти за репрезентиране на информацията ви, които гарантират, че собствеността върху нея ще остане ваша.

Както виждате, когато става дума за визията има повече от няколко допирни точки между 5 годишния проект SOLID и 12 годишния SAFE.

Лятото екипът беше в Сан Франциско на изложението Decentralized Web Summit 2018 и представи свършената до момента работа в комбинация с принципите на SAFE и комбинирането им със SOLID пред такива интернет светила като сър Тим Бърнърс-Лий и Брустър Кале. И сега си заслужава да погледнем към прогреса ни към днешна дата.

SOLID се движи от желанието да върне на всички контрола върху собствената им информация от централизираните платформи. Така SOLID уеб апликация просто се превръща в начин за изобразяване на информация от множество източници, които вие избирате — без да губите собствеността върху информацията си. С други думи SOLID иска да изберете точно къде да съхранявате информацията, която създавате и след това да използва URL’s (Uniform Resource Locators) за достъп до тази информация, по такъв начин, че да имате контрол върху нея.

Концепцията е брилянтна. Но този смел нов свят от визията на Solid общността все още не се занимава с един от критичните проблеми — как да обезопаси самата информация (без значение къде сте избрали да я съхранявате).

И точно тук се явява ролята на SAFE мрежата.

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

С други думи, това е бъдеще, което изпълнява целите и на двата проекта. Но как ще работи?

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

С тази цел приехме RDF (Resource Description Framework) стандарта използван от Solid. Използването на стандартен начин за съхраняване на информация в SAFE мрежата е от критично значение за разрастването на проекта. Това също така ни позволи да създадем някои услуги за програмисти, които да им помогнат в бъдеще.

За пример представихме WebID. Това е прост начин да имате множество идентичности/профили в мрежата, които да споделяте с другите чрез URL линк. Информацията, която се създава се съхранява в SAFE мрежата в RDF формат. Може да видите това в WebID Профил мениджъра, който създадохме (с който може да си направите собствен профил, с четим от хора URL линк) също така и в WebID Превключвателя (което ви позволява да изберете, който и да е от WebID профилите ви за достъп, до която и да е програма в мрежата). И ако искате да изпробвате това днес може да го направите — просто вижте Patter , нашето Twitter копие, доказващо концепцията.

Още повече с публикуването на WebID в SAFE Network се решава добре известния проблем, срещан от всеки имал нещастието да е жертва на атака експлоатираща слабостите в настоящата DNS система. Например, всичко което е необходимо днес е ISP (интернет доставчик) или DNS сървър да бъде атакуван за да бъдете пренасочени към злонамерен сървър. Още повече, никой няма пълна собственост върху домейн името си в настоящия интернет — просто имате регистрирано право за използването му, което може да ви бъде отнето по всяко време. Използването на SAFE мрежата премахва тези уязвимости.

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

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

Ако сте нов в света на SAFE мрежата, може да получите покана като се регистрирате и прекарате час в четене на теми във форума на общността [https://forum.autonomi.community/]. Ако смятате, че това е свят, в който си заслужава да живеете моля присъединете се към нас. Поемете контрол върху информацията си — и я подсигурете с SAFE Network.

SAFE-Fleming (част 2): Динамично членство

С напредъка към излизането на SAFE-Fleming (Алфа 3) започваме да представяме отделните части от пъзела за създаването на децентрализирана peer-to-peer рутинг мрежа — мозъкът на новия децентрализиран интернет . И с включването на стотици хора от цял свят формиращи peer-to-peer връзки в скорошния Crust тест дойде времето да преминем към следващата фаза.

Какво е Динамично членство? И какво общо има с PARSEC?

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

От тогава вграждаме PARSEC в мозъка на SAFE мрежата. Известен още като Рутинг нивото в него се вземат всички решения. И голяма част от работата е насочена към решаването на един въпрос: да включим PARSEC да работи в динамична мрежа, за разлика от статична такава.

Статична срещу Динамична мрежа. С позволение или без позволение.

Нека разгледаме това за момент. Каква е разликата между статична и динамична мрежа? Статична мрежа просто значи, че е изградена от компютри, които не се променят. Може би те са членове на една и съща организация. Или различни компании, които работят заедно за да споделят ползите от това. Без значение от причината, обикновено се взима решение да се ограничи свободния достъп на членовете и системата е създадена и оптимизирана само за тези, компютри, на които е позволено да участват в нея.

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

Без посредници.

Но в една децентрализирана мрежа това поставя редица препятствия. Какво спира злонамерена атака от хиляди компютри срещу мрежата (известна като Sybil атака)? Какво ако компютри с ниски характеристики, които не покриват минималните изисквания се присъединят към мрежата и увредят функционалността й? Тези неща, заедно с други концепции (като Disjoint Sections, криптиране, churn и Сугурен Предавател на Съобщения) са обсъждани преди и ние също ще им ибърнем внимание в бъдещи публикации.

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

Слушайте внимателно — До тези, които могат да докажат, че казват истината

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

Вижте следното видео за да разберете повече за това как PARSEC работи с Динамичното Членство — с други думи влизането и излизането на компютри в мрежата по желание. Показан е пример, който може да тествате сами (отидете на https://github.com/maidsafe/parsec) за да видите графики, които илюстрират процеса за вас. Примерът показва какво точно се случва при всеки рунд на клюки и как различните компютри взимат тази информация за да достигнат до същата поредност от стабилни блокове — въпреки факта, че компютри влизат и излизат от мрежата постоянно.

Накратко: няма значение, че участниците в мрежата постоянно се променят.

SAFE мрежата въпреки всичко ще постигне консенсус.

Какво се случва, когато компютър има слаба интернет връзка или другите компютри открият, че е злонамерен и иска да атакува мрежата? Всички компютри гладуват използвайки PARSEC. И ако се достигне до консенсус тв премахват компютъра от списъка си с контакти, принуждавайки го да напусне. Става прокуден. Никой честен компютър няма да приеме съобщения от него. Няма друг избор освен да се изключи от мрежата.

PARSEC и присъединяване към мрежата

PARSEC се използва също така от всеки компютър, който иска да се присъедини към мрежата. Компютър, които следва PARSEC съобщава на другите, че е нов компютър, който иска да се присъедини. Отново е време за гласуване — и когато съществуващите компютри достигнат до консенсус, новият компютър се присъединява.

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

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

И сега графиката е обновена — за да покаже, че нов компютър се е присъединил и е валиден член на мрежата.

Заключение

Ако създавате мрежа достъпна за всеки (permissionless) това е добре известен проблем. Когато не може да използвате нещо като блокчейн с доказателство за работа (proof-of-work) (защото ограниченията в капацитета и криптирането в блокчейн технологията не са достатъчно добри за проект като нашия), отговора не е ясен на пръв поглед. Но сега да се надяваме може да видите как SAFE Network предлага решение.

Разбира се това е част от голямата картина — не е цялото решение. Но с всеки изминал ден се приближаваме до следващата голяма стъпка SAFE-Fleming. В следващите статии ще ви запознаем подробно с Засичането на Злонамерени агенти (Malice Detection) и Сигурното предаване на съобщения (Secure Message Relay), заедно с други концепции — но нека оставим това за друг ден…

Какво постигнахме през 2018 година

Началото на 2019 година е и спомените от посрещането на още една Нова Година бавно си отиват. Пред нас се простира цяла нова година и нямаме търпение да се захванем с работа!

Вече представихме първия си значителен напредък за годината поддръжка за разработка на чисти Андроид SAFE приложения. Но преди да се впуснем към всички изключително вълнуващи неща, които 2019 г. обещава, е добре да погледнем още веднъж какво постигнахме през изминалата година за SAFE Network. И докато екипът на MaidSafe продължава да расте и новия програмен код продължава да се трупа в GitHub, е лесно да се загуби поглед върху това, колко много напредък беше постигнат както от MaidSafe, така и от цялата общност.

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

SAFE Network Фундаментите

През годината работехме върху изясняването на множество основни истини за SAFE мрежата, които събрахме в списък от 21 Фундаменти. Може да ги видите тук на сайта ни, но ако търсите повече контекст, защо всеки от тях е направлявал дизайна на мрежата през последните 12 години си струва да погледнете темата във Форума, която обяснява контекста.

PARSEC

Една от най-големите новини през годината беше представянето на Протокола за Асинхронен Устойчив Сигурен и Ефикасен Консенсус (PARSEC). През май 2018, MaidSafe представи PARSEC, нов напълно децентрализиран, с отворен код, изключително асинхронен устойчив на Византийската атака (Byzantine Fault Tolerant) консенсус механизъм. С други думи метод, чрез който една глобална мрежа може да постигне съгласие върху събитията, които се случват и поредността им без да разчита на централна власт.

По-голямата част от времето до края на годината за Рутинг екипа беше прекарано в интегрирането на PARSEC в SAFE Network и надеждата ни е, че още много проекти ще се възползват от технологичния ни пробив и ще го използват за своите нужди. Може да научите повече в Бялата книга, в публикация представяща самият програмен код, в няколко подкаста, технични и не технични видео клипове, в статия в TechCrunch и на още много места!

CRUST

Имаше доста вълнение в общността, когато представихме няколко теста за да видим как нашата peer-to-peer мрежова библиотека Crust ( Връзки в Rust ) ще се държи пусната на свобода. Между първия Crust тест и втория видяхме някои невероятни резултати. Участие взеха хора от 37 държави и общо направиха над 20 000 опита за свързване, заедно с доста силни връзки от и към Китай (88% успешни като цяло), и щастливи може да обявим, че хората могат да се свързват един с друг директно чрез Crust библиотеката! Станахме свидетели и на някои проблеми, които доказват фундаменталната нужда всичката информация да бъде криптирана в новия децентрализиран интернет.

SAFE и SOLID

Постигнахме голям прогрес през 2018 между проекта SOLID на Сър Тим Бърнърс-Лии и SAFE мрежата. Като изградихме рамка, която гарантира запазването на информацията в SAFE мрежата по начин съвместим със семантичния уеб подход на Solid можем да гарантираме, че си подхождаме чудесно в общата ни визия за пълен контрол на потребителя върху информацията и изключването на трети страни, които в момента трупат чуждата информация и я използват по начини, които не харесваме.

Публикувахме Доказателство на концепцията – наречено Patter, за да покажем това през юли 2018 година. То наподобява Twitter, като може да се запознаете с подробностите тук (Тази блог публикация от Джош и този подкаст). Още по вълнуващо е, че новият SAFE Browser поддържа RDF дата структури!

ВИДЕО СЪДЪРЖАНИЕ

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

ОБЩНОСТ

Общността се задвижи през годината с редовни срещи в Лондон, Чикаго и Брайтън. Члена на общността @fergish продължи да работи върху своя подкаст SAFE Крастопътища. И беше фантастично да видим създаването на SAFE Network Primer през януари от общността, документ представящ проекта ни на новодошлите.

Световната общност спонсорира и информационна кампания в България с постери:

Екипът участва и в различни конференции като FOSDEM, MozFest, RustFest Paris, RustFest Rome и RustRush ако трябва да изброим няколко. Осъществихме и първия SAFE DevCon през Април 2018. Беше уникален ден, в който целия екип на MaidSafe присъства заедно с голям брой добре познати членове на общността срещащи се за първи път лице в лице. Може да видите видео от този ден тук — а скоро ще обявим и кога ще е SAFE DevCon 2019…

НОВИ УЕБСАЙТОВЕ

Вече има 3 ключови сайта: представихме safenetwork.tech (насочен към новодошлите, защитниците на личния живот, журналистите), SAFE DevHub (за програмисти и по технически личности) и редуцирахме фокуса върху maidsafe.net за да отразим важността на мрежата и общността пред MaidSafe като организация. Това ни приближи към същността на проекта, където общността ръководи форума и част от социалните канали, като Telegram и Reddit.

ПУБЛИЧНОСТ И НОВИ ИСТОРИИ

Беше вълнуваща година изпълнена с новини. Първо имахме възможността да поговорим за включването на Дейвид, Вив и Ник като съветници в изключително популярния сериал на HBO “Silicon Valley”. И Холивуд продължи да ни изненадва с интереса си към нас с неочакваното включване на SAFE мрежата в “Wreck-It Ralph 2: Ralph Breaks The Internet’.

Всичко това идва в момент, когато света усилино се заглежда в децентрализацията на интернет за да реши, някои от настоящите проблеми. В година изпълнена с трудности за Facebook, Google и други, MaidSafe и SAFE Network бяха представени на места като вестника The Guardian, заедно със спонсорството ни за Decentralized Web Summit в Сан Франциско (донякъде иронично…) през 2018. Също така представихме повече начини да следите проекта — включително новия Email лист с новини и включването на MAID към множество крипто приложения (Blockfolio, BitUniverse, Delta Direct, CoinGecko).

ЕКИПЪТ НА MaidSafe РАСТЕ

Екипът на MaidSafe продължи да расте през последните 12 месеца и дори отворихме нов офис в Ченай, Индия. Към нас се присъединиха 12 нови служителя през изминалата година, което е растеж с 26% към целия екип. Повечето от тях се представиха тук в случаи, че искате да знаете малко повече за тях (може да ги намерите в публикациите на safenetwork в Медиум).

ПРОГРАМИ ОТ ОБЩНОСТТА

Станахме свидетели на силен растеж на разработването на програми от общността през 2018 — от музикалния проект JAMS!, до SAFE Drive, Project Decorum, SAFE-CMS, SAFE-Search and SAFE CLI Boilerplate заедно с още много други. Като се има пред очи представянето на инструментите за Android тази година очакваме с нетърпение разработките в тази сфера в бъдеще.

КАКВО СЛЕДВА?

2018 показа огромно развитие на SAFE Браузъра (включително най-новото v0.11.0 обновление), Web Hosting Manager, възобновяването на RFC процеса (например предложенията за XOR URL адреси в мрежата) и още твърде много направления за да ги изброим всичките.

И 2019 се очертава да се покаже като още по-вълнуваща.

Приближаваме се към пускането на SAFE Fleming: това значи, че PARSEC ще е напълно интегриран в Рутинг нивото, с Динамично Членство, засичане на злонамерени атаки, нашето шардинг решение (Секциите) и Безопасното Предаване на Съобщения (Secure Message Relay) всичките тези неща работещи за да позволят пускането на децентрализирани рутинг компютри от вкъщи. Работата по вграждането на RDF поддръжка в SAFE ще продължи и фокуса ще се насочи към донасянето на UX принципите в по основното ниво на софтуера — заедно с цял куп нови и вълнуващи подобрения!

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

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

Нека 2019 година ни е добре дошла!

SAFE Мрежата идва за Андроид!

Имаме добри новини за началото на 2019 година! С удоволствие ви представяме поддръжка за разработката на програми за SAFE Network върху Android!

Накратко

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

Какво точно представяме ?

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

До днес на потребителите на настоящата Алфа 2 версия на SAFE Network им се налагаше да използват SAFE браузъра за достъп до мрежата от стационарния им компютър. Това е така, защото достъпа минава през SAFE Удостоверителя (който в момента е вграден в SAFE браузъра).

Но от днес потребителите могат да достъпват мрежата и от Android (7.0 Нуга, API 24). Първоначално ви представяме доказателство за концепцията, което може да намерите в GitHub. Но съвсем скоро ще може да свалите Удостоверителя за Android от Google Play Store на смартфона ви.

И също толкова вълнуваща е новината, че пускаме и нов Java API. Защо е това вълнение? Защото за първи път програмистите могат да създават нативни Android приложения за SAFE Network. Или за да е по ясно, програмиста не е ограничен до мисълта “Искам да създам децентрализирана [изберете си каквато и да е п рограма ] за SAFE Network”. Защото от днес вече съществуват инструментите за това.

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

Запознайте се с подробностите

Искате повече подробности? Най-доброто място за това е SAFE Network DevHub, където може да намерите цялата документация, от която ще имате нужда, включително Java API документацията. И ако почувствате, че е време да се включите? Заповядайте във форума на общността, където ще получите помощ или от екипа на MaidSafe или от членовете на общността.

1 Like

Какво е SAFE-Fleming?

Мрежа, която уважава използващите я

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

Мрежата има множество компоненти. На най-ниското абстрактно ниво лежи Кръст (Crust), комуникационен слой, който позволява на всеки два компютъра да се свържат един с друг през домашните си рутери с криптиране от край до край. На много по високо ниво Удостоверителя е програма, чрез която потребителя се свързва към децентрализираната, без нужда от позволение мрежа и без паролата и частния ключ на потребителя да напускат собствената му машина (компютър/смартфон). Между тези две абстрактни нива има множество други компоненти, които изграждат пълния дизайн на SAFE мрежата.

Изграждаме всяко от тези нива (вижте Github страницата ни за пълен списък) и всеки компонент приближава различно ниво на завършеност. Интегрирани за първи път заедно преди година те създадоха работеща мрежа представена под името Версията на Удостоверителя (наричана още Алфа 2) на SAFE Network.

Рутинг нивото

Ако погледнем в задния слой мрежата има две основни функционалности:

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

За да се използват функционалностите се използва софтуер – например SAFE Уеб Браузерът – който комуникира със SAFE Мрежата чрез различни API-та (Приложно-програмен интерфейс).

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

Следващата голяма стъпка: децентрализирана без нужда от позволение мрежа

Алфа 2 мрежата се нарича алфа софтуер (обратното на стабилна версия), защото критичен елемент от дизайна все още липсва: работа без нужда от нечие позволение. Поради тази причина настоящата алфа версия на мрежата работи върху група компютри притежавани от MaidSafe, компанията която разработва SAFE Мрежата.

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

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

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

Част от отговора: консенсус

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

Без лукса на група доверени компютри или предположението за времето необходимо на съобщенията да бъдат предадени по мрежата, ефективното постигане на съгласие между компютрите е труден математически проблем. Името на тази категория проблеми е ABFT, или Асинхронна византийска толерантност (Asynchronous Byzantine Fault Tolerance).

През май 2018, рутинг екипът на Maidsafe представи нашето решение на ABFT проблемът: PARSEC (Протокол за Асинхронен, Надежден, Сигурен и Ефективен Консенсус).
От тогава усилено работим върху програмния код, който следва тази група от математически правила. Не само, че това покрива случаите на употреба описани в документацията (White Paper), но успяхме да разширим употребата на кода и в други области, които са критични в практиката (като идентифицирането и справянето със злонамерени компютри в мрежата).
Достигнали сме до момента, в който може да интегрираме PARSEC в останалия рутинг код, с няколко малко останали неща за до оправяне.

Стигнахме ли вече?

В началото на 2018 година консенсуса беше един от най-големите въпросителни в дизайна на SAFE Network. И сега когато този проблем е решен, въпросът е: “какво следва?” и колко време остава докато може да тествате следващата версия на SAFE Network?
Добре дошли в SAFE-Fleming.

Дизайна на Рутинг нивото в мрежата се подобрява постепенно от началото на идеята за SAFE Network преди 12 години. Множество елементи на дизайна бяха представени и обсъждани чрез нашия RFC (Заявка за Коментар) процес. Някои от тях вече са готови и включени в настоящата Алфа 2 версия.

Но със SAFE-Fleming идва времето за въвеждането на всички характеристики на една напълно функционална без нужда от позволение децентрализирана мрежа.

Не бързайте толкова!

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

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

Следва продължение…

1 Like

Излезе SAFE Browser версия 0.11.2

Представяме ви версия 0.11.2 на SAFE Браузъра.

Може да свалите версията за вашата операционна система и да видите промените в GitHub страницата ни.

Директни линкове за сваляне

Linux OSX Windows
За реалната Алфа 2 мрежа Linux Mac Windows
Изпитателната / За програмисти версия Linux (dev) Mac OSX (dev) Windows (dev)
Soure code (zip)
Soure code (tar.gz)
1 Like

Колко анонимна е всъщност SAFE Network?

Ако използвам дадена SAFE програма (например SAFE browser-а), как може да ми забраните да събера tcp информацията, която изпращам/получавам от другите участници в мрежата и по този начин да видя IP адресите на тези хора?

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

Броя на препращанията зависи от големината на мрежата.

И сега частта, която отговаря на въпроса.

Компютрите в мрежата не препращат вашия IP адрес, нито IP адресите на другите компютри. Единствения IP адрес, който се препраща е този на най-близкия компютър, с който се комуникира, защото това е част от tcp/ip протокола. Това е известно като IP прочистване.

Как обаче Секцията, която има информацията, която сте заявили я връща към вас? Това, което се препраща е вашия XOR адрес и той се използва за да стигне информацията до вас. По този начин никой освен първия компютър, с който сте се свързали не знае вашия IP адрес. Всъщност дори първия компютър не знае дали вие сте заявителя на исканата информация или заявката само е преминала през вашия компютър.

И така стигаме до проблема с асоциирането на XOR адресите с IP адресите. Това е проблем само ако някой има властта да следи всички доставчици на интернет (ISP)/рутери в света, като дори тогава ще може да асоциира адресите за кратък период от време, защото XOR адресите на компютрите в SAFE мрежата се сменят при всяко съединяване/разделяне на секциите. Така на теория е възможно да се разберат всички IP адреси на участващите в мрежата, но на практика заради законите защитаващи личността и липсата на споделяне на информация между интернет доставчиците това е невъзможно на този етап.

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

Предвид, че пакетите са криптирани, възможно ли е злонамерена личност да проследи трафика използвайки дълбок анализ на данните (deep packet analysis) и по този начин да разработи стратегии, с които да прекъсне връзката (DDoS атака) между компютрите в мрежата (т.е. дори и да не може да открадне криптираната информация, то поне да се опита да прекъсне обмяната й)

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

Пакетите в SAFE мрежата са неразличими от нормалните HTTPS пакети (т.е. всякакви размери/дестинации) какъвто и дълбок анализ на данните да се използва ще има огромни пречки да разграничи и успешно да изолира само SAFE пакетите от всички други. Да си представим 5% възможност за грешки и спирането на пакети към банката или фирмата, в която работите. Ще има бунтове. Проблема тогава е, че дори да могат да се идентифицират пакетите (но никога със 100% сигурност) ще бъде опасно за бизнесите да спират/забавят тези пакети.

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

Единствения модел, който остава е когато се обменя серия от цели файлове. Те могат да бъдат идентифицирани по размера им от приблизително 1MB от информация изпратени към един IP адрес. Но след като серията от файлове ще идва от различни места (различни IP адреси) дори това не е ясна идентификация за трафик от SAFE мрежата.

Да обобщим - клиентите (потребителите) не са изложени на риск, защото трафика им изглежда като нормално браузване в интернет. Някои клиенти могат да имат проблеми в различни части на света заради количеството трафик, но досегашните тестови мрежи показаха, че трафика е под 5Mb/s (дори по малко от 2Mb/s) средно, а това е като да гледате филм от интернет или да качвате филм в dropbox и т.н.

Кръст (Crust) библиотеката пази информация за топологията на мрежата за да може да препраща трафика ефективно; как може да попречите на хората да декриптират тази информация (или от постоянни данни, или от системната памет) и по този начин да придобият информация за другите компютри в мрежата?

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

Но дори и да имате ресурса за това има пречки, които ще намалят ефективността на атаката ви:

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

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

А щом мрежата достигне стотици хиляди компютри (да се надяваме през първата година от стартирането й) то очакваме анонимността да е на много високо ниво.

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

1 Like

Излезе: SAFE.NetworkDrive за Windows v.0.1.0-alpha.1

Интернет навърши 30 години (Web30) и е подходящо да го отпразнуваме с представянето на алфата на SAFE.NetworkDrive за Windows, разработена от член на SAFE Network общността – Oetyng!

SAFE.NetworkDrive

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

Линк в GitHub: oetyng/SAFE.NetworkDrive

Алфа версия с графична среда и конзолна версия:

Event sourced virtual drive, writing encrypted WAL to SQLite, synchronizing to MockNetwork and local materialization to in-memory virtual filesystem. Виртуален диск базиран на произхождащи събития (Event sourced), записващ криптиран WAL в SQLite, синхронизиращ се с имитираща мрежа (MockNetwork) и локална материализация с виртуалната файлова система в паметта.

  • Множество локални потребителски акаунти.
  • Множество локални конфигурации на устройството на локален потребителски акаунт.
  • Поддръжка на един SAFE Network акаунт за всеки виртуален диск
  • Шифровани локални данни.
  • Добавя локален потребител, ако не съществува.
  • Добавяне / премахване на устройства.
  • Монтиране / демонтиране.
  • Премахване на локален потребител.
  • Икона в лентата за съобщения
    72

    74
    75
    76
    77

Изисквания:

Dokan driver (Dokan_x64.msi at Release 1.2.2.1000 · dokan-dev/dokany · GitHub)

Dotnet core runtime 3.0 ( .NET Core Installer: x64 Download .NET Core 3.0 Runtime (v3.0.0-preview3) - Windows x64 Installer)

Как да го използвате:

  • Уверете се, че имате инсталирани Dokan и dotnetcore 3.0 runtime.
  • Компилирайте приложението от източника.
  • Стартирайте SAFE.NetworkDrive.UI.exe или SAFE.NetworkDrive.Console.exe.

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

  • Преименуването или преместването на първата папка в хард диска ще доведе до BSOD (син екран на смъртта) от неизправност на страницата в неподписана област.
    Това най-вероятно е проблем в dokan драйвера. Изпратена им е заявка за отстраняване на проблема.

Възможно е да има и други BSOD…

Следва:

Подробно обяснение за начина на работа на SAFE.NetworkDrive.

1 Like

Колко устойчива на атаки е SAFE мрежата?

С излизането на SAFE-Fleming обединяваме всички компоненти необходими за пълното функциониране на децентрализирана без нужда от позволение мрежа. Нивото за съхранение на информация ще дойде скоро след това. Но това е голяма новина само по себе си. В предишната ни публикация по темата “Големите въпроси: SAFE Fleming и отвъд” хвърлихме светлина върху някои от предизвикателства, пред които сме изправени.

Критичната част тук е съчетанието: ‘без нужда от позволение’. То лежи в сърцето на множество решения, върху които се базира дизайна на SAFE Network. Едно от тях е подредения консенсус - нещо, което разглеждаме подробно в темата обясняваща “Какво е SAFE-Fleming?”. Друго, което допълва консенсуса е устойчивостта на Сибил атаки (Sybil Resistance), върху които ще се спрем малко по подробно сега.

Нека започнем с обяснението на Сибил атаките от Уикипедия:

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

Може би познавате други мрежи по-добре. Нека вземем Биткойн за пример. При него механизмът за доказателство за работа (proof-of-work - PoW) е ефективно средство срещу Сибил атаки, защото независимо колко идентичности създаде нападателя, той все още трябва да контролира повече от 50% от изчислителната скорост в мрежата за да бъде ефективна атаката му.

Но както знаем PoW блокчейн не е подходящо решение за SAFE мрежата поради голям брой причини (включително невъзможността за разрастване на мащаба на мрежата и асинхроността). Затова се налага да постигнем сигурност чрез други методи.

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

Но, защо?

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

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

Как спираме Сибил атаките?

За да се предпазим от тях има няколко стъпки, които сме предприели. В основата си нещата опират до това да направим тази атака изключително скъпа за злонамерената личност, както измерено във време, така и в пари и ресурси. В Биткойн доказателството за работа прави Сибил атаките много скъпи, защото изисква, нападащия да има контрол над повече от 50% от изчислителната скорост в мрежата. По същия начин ние искаме да направим атаките срещу SAFE мрежата толкова скъпи, че да станат невъзможни.

По точно

Може да идентифицираме две свойства на мрежата, които ще вдигнат стойността на атаката драматично.

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

Може да постигнем това чрез комбинация от механизми:

  1. Не приемай сляпо всеки компютър, който желае да се включи в мрежата

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

  1. Балансирано преместване

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

  1. Възраст на възлите (node ageing)

Регулиране на влиянието на всеки компютър във взимането на решенията според количеството работа, което е свършил за определено време значи, че нападател не може да получи контрол без преди това да е предоставил на мрежата реални и големи количества ресурси. Количеството и силата на компютрите, които атакуващия има са без значение ако те са от скоро време в мрежата, защото заради младата си “възраст” имат много малко влияние върху взимането на решенията (всъщност започват от 0). Докато трупат време на работа, компютрите също така биват местени от една секция в друга, което пречи на концентрирането на злонамерени компютри. Информацията от други P2P мрежи показва, че най-дълго свързаните компютри в мрежата са най-стабилни, което значи, че те е малко вероятно да се изключат и затова предоставят стабилно ядро, което е трудно да бъде превзето от Сибил компютри.

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

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

Звучи чудесно като цяло, но може ли още подробности

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

1 Like

SAFE Удостоверител - Android/iOS - v0.1.3

SAFE Удостоверителя (Authenticator) действа като врата към SAFE мрежата и Ви позволява да контролирате достъпа и разрешенията на всички SAFE програми (Apps) до информацията Ви.

Можете да свалите последната версия на Удостоверителя от GitHub тук: https://github.com/maidsafe/safe-authenticator-mobile/releases/latest

Подробности

  • Платформи: Linux (x64), MacOS (x64), Windows (x64)
  • Документация: ReadMe
  • Soure code: GitHub repo
  • Настояща версия: 0.1.3
  • Последни промени: Change log
  • Обратна връзка/Проблеми: GitHub Issues

Минимални изисквания

  • Android 4.1+ (armeabi-v7a, x86_64)
  • iOS 8+ (ARM64, x64)

Инсталация на телефона Ви

  • Android : Свалете APK файла и го инсталирайте (трябва да разрешите инсталирането на приложения от неизвестни източници).
  • iOS : Трябва да създадете приложението от сорс кода.

Свързване със SAFE мрежата

Необходимо е да изпълните следните стъпки:

  • Регистрирайте се във Форума и стигнете до основното ниво на достъп .
  • Отидете на https://invite.maidsafe.net.
  • Кликнете на логото на SAFE Network.
  • Изберете ‘Alpha 2’.
  • Посочете (или обновете) IP адреса, с който сте в момента.
  • Копирайте и поставете генерираната покана в полето “Invitation” в Удостоверителя.
    (тази стъпка е еднократна, само при създаването на акаунт)
2 Likes

На фокус: Вечната мрежа

Моля имайте пред очи: тази статия е превод, с оригинала на английски може да се запознаете тук.

Както знаете имаме огромни амбиции за SAFE Network — сигурна, автономна мрежа, която поставя на първо място личната неприкосновеност на информацията на потребителите си. И ако следите седмичните новини във форума на международната общност знаете, че сме се запътили към бета с пълна скорост напред. Но как точно изграждаме този нов Интернет? Може да видите в плана на проекта за интерфейса 4 концепции или важни постижения, които сме си поставили: Вечната мрежа, Частни комуникации, Поеми контрол върху своята информация и Новата дигитална икономика.

Нека започнем с първата от тях:

Какво е Вечната мрежа?

Ако сте се запознали с Фундаментите на SAFE мрежата, тази концепция може да ви е позната (фундамент номер 8):

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

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

Защо вечното съхранение на информация е толкова важно?

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

Случи се с Myspace. Ще се случи отново.

Инициативи като Интернет Архива храбро се опитват да защитят информацията ни. Но те са изправени пред предизвикателство от огромен мащаб. Всеки ден милиони снимки, клипове и истории се качват в интернет. Всъщност повече от милиони. Според статистика от 2018 г. 2.5 квинтилион байта се качват всеки ден без изключение. Как изобщо може да се надяваме да съхраним такова количество информация в толкова динамична среда?

Тук идваме ние. SAFE Network съхранява публичната информация вечно — което значи, че никога повече няма да ви се налага да пазите копие от дадена страница. Резултатът? Съхранявате спомените си вечно. И това идва заедно с всички останали блюсове на SAFE мрежата: зад нея не стои една организация, достъпна е навсякъде по света, децентрализирана е и не може да бъде цензурирана… списъка няма край.

Как Вечната Мрежа ще помогне на всички ни

Освен за идните поколения, защо Вечната Мрежа е толкова важна?

Публичната информация, която е постоянно на достъпна и непроменима помага да се справим с цензурата. Ако искаме да избегнем едностранно виждане за света имаме нужда от достъп до всички истории, които са написани. Досега беше вярна максимата че, “Историята се пише от победителите”. За пръв път в историята имаме потенциала да гарантираме, че правителствата и институциите няма да могат избирателно да решават каква информация да е достъпна за масите. Вечната Мрежа гарантира, че историята не може да бъде пренаписана, което има катастрофални ефекти, както може да се убедим от случващото се с човешките права, в някои от настоящите държави. Искаме мрежа гарантираща автентичността. Такава, която е честна и не се крие от истината.

Вярваме, че и вие искате същото…

Широко разпространеното сътрудничество носи награди

Софтуерът с отворен код е в нашето ДНК. И този начин за работа, без централен контрол, отива отвъд разработката на софтуер. Отворената наука е движение опитващо се да превърне научните изследвания (като публикациите, информацията, физическите проби и софтуера) достъпни за всички нива от любознателното общество. Приобщаващо без значение дали си любопитен аматьор или професионален изследовател.

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

Обещанието на Вечната Мрежа

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

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

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

Подробна информация може да намерите както винаги във форума на международната общност: SAFE Network Forum

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

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

2 Likes