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

SAFE Network новини – 17.10.2019

Накратко

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

  • @jimcollinson засне видео, в което той говори за мисловния процес, потребителските изследвания и тестовете, които са влезли в дизайна за мрежата за новорегистриращи се потребители.
  • Пуснахме нова версия на SAFE CLI (v0.5.0).
  • Започнахме публикуването на safe-api (SAFE Rust API-то) в crates.io

Маркетинг

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

Но преди да продължим, бихме искали да представим на вашето внимание невероятната работа на българския посланик на SAFE мрежата @dimitar. Българският сайт на общността (https://safenetwork.bg/) е номиниран за сайт на годината в категория Future / Innovative и можете да гласувате за него следвайки инструкциите тук. Неща като това са наистина смиряващи и е невероятно да се види колко ангажирана с успеха на проекта е общността ни ден след ден.

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

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

Тази седмица се съсредоточихме върху разработването на детайлите на интерфейса за маршрутизиране, който ще се използва от Трезорите.Това е лесно за случаите, когато Трезор праща заявка към библиотеката за маршрутизиране (напр. при искане за гласуване с консенсус), но трябва да сме по-предпазливи в случаите, когато маршрутизацията трябва да предаде събития и данни надолу към Трезора, защото не искаме да излагаме прекалено много вътрешната работа на маршрутизирането, за да сведем до минимум знанията, необходими за използването на библиотеката. В крайна сметка това е по-скоро предизвикателство за софтуерния дизайн: искаме да имаме минимално и разбираемо API, като същевременно запазваме възможността за тестване на Рутинга и мрежата с различни конфигурации (със или без реални мрежи, с тестов PARSEC и т.н.) ). Намерихме няколко добри решения на тези проблеми и се доближаваме до интегрирането на истинското маршрутизиране със Трезорите. Напредъкът може да се проследи в проблем #878.

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

SAFE CLI (Интерфейс на командния ред)

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

SAFE CLI v0.5.0 е пуснат и е достъпен за всички да ъпгрейднат до него с командата $ safe update или може да бъде изтеглен от GitHub страницата с актуализации, ако не сте имали предишната му версия.

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

Също така започнахме да публикуваме safe-api (SAFE Rust API-то) в crates.io. Вчера беше публикувано safe-api v0.5.0 , и въпреки че все още трябва да работим по документацията на safe-api , то вече е достъпно за Rust приложения да го използват като зависимост от там.

Това ни позволи да публикуваме нова версия (v0.3.1 ) на пакета safe-nodejs , която вече зависи от най-новата safe-api v0.5.0 от crates.io. Тази нова версия сега включва всички връзки към Node.js за API-тата на SafeKeys и Wallet , които липсваха в предишната версия и следователно вече са готови да се използват от Node.js приложения.

Нашите усилия за създаване на Удостоверяващ процес ( authd daemon) продължиха през изминалата седмица, с някои успешни първи тестове за стартиране / спиране на процеса и взаимодействие с изложените му услуги (чрез QUIC), като всички използват новите команди в SAFE CLI. Това върху което работим е ново API за authd клиента, за да позволи не само на SAFE CLI, но и на всички други приложения да могат да комуникират с процеса без нужда да разбират протокола за комуникация. Следователно вече започнахме да се опитваме да получим някои основни Node.js връзки за това ново API, като се опитваме да го тестваме от Electron приложенията, които ще бъдат необходими, за да може SAFE Network App да комуникира с authd .

SAFE Network приложение/програма (SNAPP)

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

Още един видеоклип за вас от @jimcollinson ви превежда през мисловния процес, потребителските изследвания и тестoвете, които са влезли в дизайна на мрежата за новорегистриращи се потребители.

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

Идентифицирахме многобройни подходи как това може да работи и как можете да се включите в мрежата:

  1. Чрез стартиране на трезор. Това е начин да предлагате ресурси в мрежата и да бъдете възнаградени с валута, която след това можете да използвате за създаване на акаунт.
  2. Плащайки за акаунта си с фиатна валута, през борса.
  3. Чрез създаване на офлайн акаунт, и ваш приятел, който вече е в мрежата, да го качи за своя сметка.
  4. Making an empty offline wallet, sending it to a friend for them to fill up with the required amount, in order for you to create an account from it. Направете празен офлайн портфейл, изпратете го на приятел, за да попълните необходимата сума, за да можете да създадете акаунт от it.
  5. Създаване на офлайн ‘неактивен акаунт’, който след това ще бъде активиран от потребител с плащане със Safecoin.
  6. Като друг потребител ви покани … чрез специална връзка, която той е закупил, съдържаща всичко, което ще ви е необходимо, за да продължите.
  7. И накрая, разбира се да не забравяме, има и такива от вас, които вече притежават MaidSafeCoins, и които ще могат да заменят част от тях, за да платят за SAFE Акаунт.

Във видеото по-горе Джим разказва как избрахме тези варианти и решенията, върху които ще работим първо.

Продължаваме и на два други фронта:

Обновления - План на проекта
Удостоверяване - План на проекта

От една страна с плана за актуализиране на проекта, както и с други подобрения (напр. Използване на S3 вместо GitHub за изтегляне на обновленията, тъй като GitHub се оказа много бавен) и някои други вътрешни настройки за това как успяваме да открием нови актуализации на приложенията.

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

SAFE Десктоп Браузър

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

Имаме нова версия поправка на браузъра, която трябва да бъде пусната скоро (в очакване на някои окончателни QA). Това коригира някои проблеми с разрешенията в pWeb 3, както и добавя друго pWeb (Perpetual Web - Вечната мрежа) изискване за блокиране на неверсифицирани ресурси, поискани от DOM от друг домейн . Това означава, че няма да можете да изтеглите CSS safe://някъде другаде и да избегнете създаването на нова версия на уебсайта, когато променяте показаното оформление / съдържание и т.н.

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

Също така сме включили някои актуализации за зависимостите и нова версия на safe-nodejs в браузъра. Ще изложим и функционалността на XorUrlEncoder от API-то, тъй като някои хора искат достъп и до това.

SAFE App C#

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

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

За да сме в крак с новите промени в API-тата и FFI, актуализирахме Cake скрипта за изграждане, за да използва най-новата библиотека, генерирана от safe-ffi CI. Скриптът може да се използва за автоматично изтегляне на библиотеките въз основа на издание или хеш на главния клон.

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

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

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

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

Както ще видите напреднахме значително с Node Age и ни остават 2 малки задачи. Това ни позволява да бъдем по-фокусирани върху интерфейса на трезора / маршрутизацията и @ustulation заедно с @nbaksalyar бяха заети паралелно (с помощ от @Jean-Philippe), завършвайки дизайна по внедряването там и всъщност прилагайки това, заедно с отстраняването на някои грешки от тестовете, и откриването на неотговарящи (забили) трезори.

С приклюването на проекта работещ по възрастта на възлите ще имаме устойчивост на Сибил (Sybil) атаки. Това позволява трезори от вкъщи (край на централизацията), но все пак ще продължим с фаза 2a / b, 3 и 4 от плана на проекта. Не искаме объркване с толкова много проекти, но искаме сериозно намаляване на времето, за да стартираме. Така че много неща се случват паралелно по работата върху трезорите, докато UX на трезорите напредва с помощта на @lionel.faber, @yogesh и @marcin за трезорите от фаза 2а.

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

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

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

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

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

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

SAFE Network новини – 24.10.2019

Маркетинг

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

Все още има време да гласувате за @dimitar и неговата номинация за сайт на годината. Знаем, че много от вас вече са гласували (включително самите ние!), но гледайте да не забравите - така че защо да не го направите сега? След като прочетете останалата част от новините ни, разбира се.

51

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

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

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

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

Тъй като втората фаза на Трезорите продължава да се разработва, не забравяме и за споделения трезор, който всички използват чрез SAFE браузъра (с функцията на Вечната мрежа - Perpetual Web) или чрез CLI приложението. От пускането на първата фаза добавихме някои функции към SAFE Клиентските библиотеки и Трезора, като например подробна разбивка на разрешенията на приложенията, възстановяване на пари при неуспешни операции и други. Тези актуализации понастоящем се адаптират за CLI-то и езиковите API-та, така че очаквайте актуализирани версии много скоро.

SAFE CLI (Интерфейс на командния ред)

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

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

Последното API, по който работим, цели да позволи на приложенията да се абонират ( subscribe) за получаване на известия от authd , когато заявление за разрешение е изпратено от кое да е SAFE приложение. Приложение, което се абонира за тези известия, може след това да подкани потребителя да разреши / откаже заявката за разрешение, преди да поиска от authd да даде идентификационните данни на приложението или не. Както знаете, това се изисква от всеки потребителски интерфейс на Удостоверителя, като SAFE Network приложението/програмата. Това беше последната функция, която искахме да имаме, преди да продължим напред със следващите стъпки в подготовката на authd .

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

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

SAFE Network приложение/програма (SNAPP)

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

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

SAFE Десктоп Браузър

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

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

Работим върху последните няколко грешки, но ще пуснем нова версия на браузъра в следващите дни. Бъдещата версия ще интегрира нови актуализации на safe-nodejs, излагайки XorUrlEncoder за приложения, които да се използват. Това също така ще актуализира част от логиката за взимане на решения на pWeb, като блокира ресурсите, поискани от страница от друго местоположение, ако тези ресурси сами по себе си не подлежат на добавяне на нови версии. Това също ни накара да направим малко рефактор по логиката за взимане на решения на страницата, за да можем да тестваме и да уловим проблеми тук по-лесно. Ще преминем скоро към тези тестове, заедно с някои други актуализации на зависимостите и необходимите актуализации за съвместимостта на SAFE Network App.

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

SAFE App C#

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

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

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

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

Сега тестовете на библиотеката C # работят успешно на Android и iOS с изключение на няколко API-та. Това означава, че не сме далеч от излизане на работеща версия, така че следете SAFE App C # хранилището за актуализации.

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

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

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

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

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

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

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

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

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

SAFE Network новини – 31.10.2019

Накратко

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

Маркетинг

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

Първо имаме нова версия на представянето на мрежата за начинаещи! Огромно благодаря на @JPL, който допълни представянето с ABFT консенсус алгоритъма PARSEC; начините, по които мрежата се защитава от често срещани форми на атака; новият тип данни на AppendOnly и въвеждането на библиотеката за маршрутизиране quic-p2p, която замества Кръст (Crust). Абсолютно фантастична работа от @JPL както винаги. Първоначалното представяне е основен маркетингов инструмент, който използваме, когато говорим с хората за мрежата или когато просто трябва да опресним спомените си за различни части на мрежата, то винаги е под ръка. Толкова е хубаво, че чак е страшно :skull:.

Почти сме готови да изпратим още един октомврийски бюлетин. Трябва да направим няколко минимални редакции (искаме да е 100% перфектно), така че вероятно ще изпратим писмото утре, точно навреме за часа на вещиците.

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

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

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

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

С наближаването на края по работата на фаза 2a на Трезорите и останалите задачи, екипът вече има време да добави няколко подобрения и по-новите API-та в SAFE Клиентските библиотеки и така временно превключваме към плана на новите проект, насочен към следващата версия на SCL. Този план ще се използва за проследяване на предстоящите и по-нови API-та на високо ниво, а също и за проследяване на проблеми от SCL, срещани от CLI екипа.

SAFE CLI (Интерфейс на командния ред)

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

Развитието на authd (Удостоверяващият процес - Authenticator daemon) продължи с добри темпове и сме фокусирани върху добавянето на поддръжка за Windows. Много сме щастливи, че вече може да работи и като Windows процес. Създаването на процес в Windows не беше толкова сложно, но имахме някои малки предизвикателства, напр. в Windows трябва първо да бъде инсталирана услугата, преди да бъде стартирана (за разлика от Linux / macOS, където тя може да бъде просто стартирана), така че трябваше да добавим няколко допълнителни команди (инсталиране / деинсталиране), за authd , които се поддържат само за Windows сега. Windows също изисква администраторски разрешения не само да инсталира процеса, но и да го стартира и спре, така че ще добавим някои специфични за Windows подробности в Ръководството за потребителя, за да покрием тези аспекти.

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

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

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

Освен това @marcin напоследък участва с частта за интерфейса с чужди функции (Foreign Function Interface) на този контейнер, прави преглед на кода и помага на екипа с въпроси, свързани с FFI. Тази седмица той направи малък рефактор, премествайки специфичния за FFI код към модула FFI. Той също така е повдигнал някои малки PR-та, за да коригира проблеми със стила, което прави кода Rust по лесен.

Също така провеждаме дизайнерски дискусии във връзка с това как да продължим да развиваме safe-api . Сега разглеждаме начини за разкриване на повече API-та, които ще позволят на потребителите да манипулират всички типове данни, поддържани от мрежата, т.е. освен API-тата на ImmutableData, които вече излагаме, бихме искали да започнем да излагаме API-тата за директно манипулиране на публикувани / непубликувани AppendOnlyData , и MutableData типове данни. Разбира се, опитваме се да се уверим, че те са максимално приятелски и лесни за използване, като първо осигуряват приятни абстракции за най-често срещаните случаи на употреба. Ще споделим повече подробности, след като имаме първоначална чернова на всичко това.

SAFE Network приложение/програма (десктоп)

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

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

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

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

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

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

  • Заделяне на място на твърдия диск и избиране на място за съхранение
  • Стартиране и спиране на трезора
  • Информация за състоянието на трезорите, дневник на събитията (log) и текущите приходи
  • Промяна на основни настройки, като например активиране на автоматично рестартиране
  • Избор за изпращане на печалба до конкретен портфейл или SafeID
  • Стартиране и управление на трезора, докато сте излезли, и след това „свързване“ към вашия акаунт по-късно, което позволява да бъде защитен, и прехвърляне на средства към портфейла на акаунта по подразбиране.
  • Как можем да позволим мониторинг и конфигуриране на Трезори, работещи от разстояние

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

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

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

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

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

Развълнувани сме :smile: да съобщим, че работата по разработването на SAFE Network приложението за мобилни устройства започна, тъй като API-тата на C # са налични и пакетът NuGet не е много далеч.

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

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

SAFE Десктоп Браузър

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

Тази седмица пуснахме нова версия на SAFE браузъра (v0.15.2), която актуализира логиката за Вечната мрежа и най-накрая разкрива XorUrlEncoder. Тази версия също така актуализира Electron до v6.1.0 и коригира няколко грешки. А на macOS ще забележите, че приложението вече е нотариално заверено - няма повече грешки при отваряне под macOS Каталина!

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

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

SAFE App C#

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

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

През последните няколко седмици имахме проблеми със работата по изграждане и тестване на iOS CI и не успявахме да изпробваме API-то на CI-то. Тази седмица, след като опитахме различни методи и инструменти, успяхме да отстраним проблема (# 159, # 162) и сега успешно провеждаме тестовете за новите C # API-та на всички поддържани настолни и мобилни платформи.

Изложихме и ново API за задаване на пътя на файла за конфигурация на трезора, който е необходим за мобилните платформи за да се свържат с локалния / споделения трезор (# 158).

Това не би било възможно без @lionel.faber и екипа на SCL, които помогнаха в създаването на функция за настройка на пътя на конфигурационния файл на трезора в SCL (# 1051). С помощта на това API най-накрая успяхме да свържем мобилно устройство към споделения трезор. Оставаме още малко работа за свързване с локалния трезор, която се надяваме много скоро да бъде завършена.

Разкрихме и ново добавените разрешения за приложения за достъп до баланса и извършване на мутации (# 156).

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

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

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

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

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

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

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

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

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

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

SAFE Network новини – 7.11.2019

Накратко

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

  • Ще изключим Alpha 2 мрежата следващия понеделник, 11 ноември.
  • Актуализирахме скрипта за изграждане на FFI, за да генерираме свързаности за С езика (в допълнение към свързаностите на C #).
  • Преминахме към самокодиране за всички файлове публикувани с помощта на safe-api и CLI-то. Това ще бъде част от следващото издание на SAFE CLI.
  • Започнахме внедряването на наименуваните контейнери в SAFE Клиентските библиотеки.

Преструктуриране

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

Дейвид Ървайн – изпълнителен директор
Стивън Койл – QA
Sharon Tannahill – Финанси и администратор
Спандан Шарма – програмиране
Джим Колинсън – дизайнер за потребителското изживяване
Никита Баксаляр – програмиране
Лионел Фабер – програмиране
Адам Циганец – програмиране
Джош Уилсън – програмиране
Едуард Холст – програмиране
Йогешвар Муруган – програмиране
Джон Хагглад – програмиране
Жан-Филип Дюфрайн – програмиране
Marcin Swieczkowski – програмиране
Габриел Виганоти – програмиране
Ravinder Jangra – програмиране
Francis Brunelle – връзка с общността

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

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

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

Алфа 2 мрежата ще бъде спряна

Благодарим на всички, които гласуваха в темата „Трябва ли да спрем Алфа 2 мрежата“ . Резултатът от гласуването беше единодушно решение да я спрем, затова ще изключим Alpha 2 мрежата на 11 ноември.

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

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

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

Маркетинг

Преустановяваме всички свои вътрешни маркетингови дейности, но това не означава, че спираме изцяло. Екипът помага на общността, като предоставя информация, предистория и съвети как да се движат нещата напред. Създава се епичен маркетингов екип на общността и нямаме търпение да видим до какво ще доведе това. Тъй като това ще бъде последната „официална“ маркетингова актуализация, искаме просто да ви благодарим много за непрекъснатата подкрепа, обратната връзка (както за лошото така и за доброто:wink: ) и за това, че продължавате усилията ни на нови нива. Ще се видим във форума :wave:

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

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

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

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

SAFE API

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

Заедно с някои незначителни поправки и подобрения в safe-ffi , също така актуализирахме скрипта на FFI, за да генерираме свързаности за C езика (в допълнение към C # свързаностите). По този начин всеки програмист вече може да започне да ги използва, ако желае, просто изпълнявайки cargo build --features bindings от папката safe-ffi . Генерираните файлове ще бъдат записани в папката safe-ffi/bindings/c/safe-api .

Както наскоро беше обявено във форума на програмистите от @mav, ние не използвахме алгоритъма / механизма за самокодиране за safe-api и SAFE CLI, което означаваше, че всички качени файлове се съхраняват като едно единствено неизменно петно на данни в трезора. Сега превключихме това, за да използваме винаги самокодиране за всички файлове, публикувани с помощта на safe-api и CLI. Това ще бъде част от следващата версия на SAFE CLI и следователно ще направи несъвместими всички предходни файлове, качени с CLI в трезора, като по този начин обмисляме да изтрием всички споделени данни на трезора за следващото издание, за да опростим нещата и да избегнем объркването на хората, които не разбират защо някои файлове не могат да бъдат извлечени с новата версия на SAFE CLI. Ще уведомим общността за това предварително, ако това се окаже окончателното решение за споделения трезор, това е просто уведомление за всички вас, които използвате CLI и споделения трезор.

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

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

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

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

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

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

От миналата седмица част от екипа отново работи по SAFE Клиентските библиотеки. И както винаги, бяха няколко вълнуващи дни. Отстраняваме някои изостанали проблеми, като например промени в обработката на конфигурационни файлове, премахване на някои неподдържани зависимости и т.н. Тези промени са вътрешни с цел поддръжка, само за да поддържат библиотеката във форма, но не спират дотук. Освен това добавяме поддръжка за клиентите да използват различни видове клавиши според предпочитанията на потребителя, а също така представяме и наименувани контейнери. В Alpha 2 всеки акаунт имаше редица контейнери по подразбиране (снимки, музика, видеоклипове и т.н.), които можеха да се използват за съхраняване на данните на потребителя и да се споделят между приложенията. След известно обсъждане решихме, че налагането на създаване на тези контейнери може да не е желателно. Например, потребителят може да поддържа акаунт само за да управлява сейфкойните си. За да се преодолее това, контейнерите по подразбиране се премахват и се заменят с контейнери, които могат да бъдат свързани с потребителски имена, определени от приложенията. Току-що стартирахме внедряването на това и вече получихме добра обратна информация. Всички ваши мисли и коментари са добре дошли, така че не се колебайте да се насочите към плана на проекта и да споделите идеите си.

SAFE Network приложение/програма

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

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

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

Очаквайте повече за това скоро, когато нещата започнат да се натрупват.

Десктоп разработка

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

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

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

Мобилна разработка

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

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

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

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

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

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

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

SAFE App C#

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

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

През последните две седмици се сблъскахме със странен проблем със стандартните библиотеки на Android, генерирани от safe-api/safe-ffi от CI, където стандартните библиотеки не отразяваха промените, направени в кода, докато библиотеките за всички останали платформите работеха отлично. Благодарение на @chriso първопричината за проблема се разбра и реши.

Също така направихме някои промени в нашата настройка на CI и сега имаме един мега тръбопровод за изграждане и тестване на API-тата на всички поддържани платформи. Освен по-добра настройка за тестване, вече позволихме на CI да пуска автоматично MaidSafe.SafeApp NuGet пакет при PR за промяна на версията. В допълнение към пускането на пакета към NuGet, когато се правят промени в основния клон, генерираме и качваме актуализиран пакет NuGet на нашия сървър за изграждане.

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

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

Освен обичайните по-малки PR обединявания, свързани с поправки на грешки и разчистване, основните елементи завършени тази седмица включват:

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

Гледайки напред, има доста PR очакващи работа за маршрутизиращият контейнер, включително, но не само, изчистване на Parsec, повишаване / понижаване на Старейшини, преместване, подобрения на производителността. А също и няколко PR, свързани с продължаващото опростяване на обработката на връзката. Обединяването на PR-ри в маршрутизирането изисква стриктна проверка чрез тестване за проблеми, което създава малко затруднения, но се надяваме скоро да успеем да ги завършим и обединим.

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

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

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

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

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