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

SAFE Network новини – 12.12.2019

Накратко

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

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

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

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

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

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

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

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

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

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

SAFE API

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

SAFE Network новини – 19.12.2019

Накратко

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

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

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

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

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

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

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

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

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

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

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

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

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

SAFE API

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

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

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

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

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

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

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

RFC

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

SAFE App C#

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

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

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

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

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

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

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

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

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

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

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

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

SAFE Network новини – 9.1.2020

Накратко

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

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

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

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

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

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

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

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

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

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

SAFE API

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

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

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

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

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

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

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

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

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

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

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

RFC

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

SAFE App C#

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

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

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

Safecoin фермерство

RFC

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

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

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

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

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

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

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

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

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

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

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

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

SAFE Network новини – 16.1.2020

Накратко

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

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

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

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

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

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

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

SAFE API

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

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

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

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

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

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

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

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

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

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

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

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

SAFE Network програма

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

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

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

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

SAFE App C#

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

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

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

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

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

Safecoin фермерство

RFC

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

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

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

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

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

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

BLS

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пазим 2018 SAFE и SOLID

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

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

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

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

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

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

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

PARSEC

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

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

CRUST

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

SAFE и SOLID

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

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

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

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

ОБЩНОСТ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Накратко

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

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

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

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

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

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

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

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

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

1 Like

Какво е SAFE-Fleming?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1 Like

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1 Like

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

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

SAFE.NetworkDrive

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

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

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

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

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

    74
    75
    76
    77

Изисквания:

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

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

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

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

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

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

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

Следва:

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

1 Like

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

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

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

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

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

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

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

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

Но, защо?

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

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

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

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

По точно

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

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

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

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

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

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

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

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

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

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

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

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

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

1 Like

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

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

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

Подробности

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2 Likes

Solid върху SAFE - новини от Марк Хюз

Какво е Solid върху SAFE?

Solid върху SAFE (може да следите и в twitter :grinning:) е проект целящ да позволи Solid приложения да работят върху SAFE Network, с възможно най-малко промени. Solid е проект на сър Тим Бърнърс-Лий (създателя на интернет) целящ да децентрализира интернет и да върне контрола на потребителите върху собствената им информация. Поддръжката на Solid върху SAFE е важна поради множество причини и важността й веднага е разпозната при първата среща между сър Тим Бърнърс-Лий и екипа на MaidSafe през 2018 година.

image

Solid е в подобен етап на разработка като SAFE: след дълъг период на проектиране сега фокуса е върху създаване на инфраструктурата и инструментите за програмиране.

Maidsafe и семантичните данни

Maidsafe приема фундаментите на Solid включително представянето на семантичните данни (Linked Data / RDF), заявките (SPARQL) и ги включва в ядрото на софтуера си за да позволи създаването на мощни програми със семантични данни, разбира се не само Solid програми, но очевидно голяма помощ в тази насока.

Solid върху SAFE

Марк Хюз работи върху свързването на двата проекта и създава API съвместимо със Solid, за да е възможно най-лесно да се използва съществуваща Solid програма, заедно със SAFE съвместими версии на Solid библиотеките и да се използва в SAFE мрежата.

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

Прогрес

Съвместимите със Solid върху SAFE библиотеки са в процес на разработка, но вече показно бяха използвани за да демонстрират работата им върху Алфа 2 мрежата, както и в тестови локални мрежи. Може да видите и видео представяне от миналогодишния SAFE DevCon 2018 (Да заредим на максимум SAFE мрежата с Проект Solid).

Това демо показва възможността от въвеждането на уеб протокол използван от Solid (LDP) чрез прихващането на браузър fetch() и/или популярна Solid библиотека (rdflib.js ).

В последствие Хюз разработва версия на друга основна Solid библиотека solid-auth-client, която дава възможност за влизане и идентификация на потребител в програмите. Това вече използва експерименталното API за SAFE WebID-та, което Maidsafe представи на DWeb Summit през 2018 година. Това работи на SAFE ‘тестова’ (за локална разработка) мрежа чрез solid-filemanager като демо, но все още не е пуснато публично.

Наскоро Хюз разработи и форк на SAFE WebID мениджъра (представен от Maidsafe на DWeb Summit), който създава контейнер за съхранение за всеки нов WebID и включва местоположението му в WebID профил документ, за да може да бъде намиран от Solid приложенията. За да се различава се нарича Solid WebID мениджър за момента (въпреки, че разликите му със SAFE WebID мениджъра са минимални). Това ще е част от следващото демо на Solid върху SAFE, което е в процес на разработка.

Настоящи задачи

Хюз работи по демо на настоящи Solid приложения, включващи както удостоверяване, така и достъп до информация, включително използването на SAFE WebID-та за идентичност (чрез избиране от менюто на SAFE браузъра). Тези приложения ще бъдат стандартни Solid програми с малко или никакви изменения, освен замяната със SAFE съвместима solid-auth-client библиотека.

В момента работи по списък от съществуващи Solid програми за да тества работата си и да публикува подходящи демо версии за Алфа 2. Някои програми използват други библиотеки като solid-file-client, които на свой ред използват rdflib.js и/или solid-auth-client, така че има множество възможности да се намерят бъгове!

Голяма част от Solid IDE работи, който в същността си е сорс код браузър, едитор и UI тест на живо:

Solid-ide SAFE mock 2019-07-18.png

Solid-ide SAFE mock 2019-07-18

Бъдеще

В бъдеще ще се търси възможност за създаване на SAFE съвместими версии на други библиотеки като Comunica / LDflex / LDfragments (или чрез използването на SPARQL в клиентът, или чрез новите SAFE RDF библиотеки, когато станат достъпни). И с разширяването на SAFE API-тата към нови видове типове данни, RDF и SPARQL ще има някои наистина яки неща за обновяване и добавяне към всичко това.

Изпълнение и какво остава да се свърши

Всичката настояща работа е насочена към NodeJs програми, браузъра и командната конзола, и започва с SafenetworkJS, библиотека, която опростява използването на Алфа 2 API-тата. Тази библиотека е все още в разработка, но е основата на Solid демотата и Solid върху SAFE библиотеките споменати по-горе, както и SAFE Drive (FUSE монтиран диск на вашето SAFE място за съхранение). Така че е в напреднал стадии и е добре тествана. Въпреки това, ще е необходимо обновяването й, когато SAFE API-тата добавят поддръжка на новите типове данни (AppendableData и т.н.) и още веднъж, когато се добави/приключи поддръжката за RDF и SPARQL.

Нужна е Вашата помощ

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

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

1 Like

Премахваме посредниците: обещанието на мрежата без нужда от позволение

Погледнете думата “позволение” в речника и ще видите, че произлиза от латинската дума ‘ permissio ’. Означава да дадеш свободата на някой да направи нещо. С други думи, някой се е съгласил, че ти може да направиш това, което желаеш. Този някой може да е шев, лидер, владетел – който и да е. Но как “позволението” е свързано с Интернет?

Интернет днес е много различен

Първите дни на интернет бяха без нужда от позволение (permission less). Когато Тим Бърнърс-Лий започва да създава Световната мрежа (World Wide Web) той не е искал позволение от никой. И вратите на интернет оставаха широко отворени – освен ако съзнателно не сте избирали да използвате порталите на AOL или Compuserve. Чрез писането на програмния код, които да осъществи идеите ви, иновацията нямаше лимит. Всеки, навсякъде по света, можеше да изгради сайт базиран просто на идея си.

Но днес това не е толкова лесно. С изминаването на годините много хора избегнаха трудната работа да се научат да пишат код и просто се записват за “безплатни” услуги създадени от други. Например Gmail беше пуснат преди 15 години. Но променя ли се сега светът?

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

Писането на код е супер сила… и отговорност

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

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

Обществото напредва чрез експериментиране

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

Но къде сме днес?

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

Ние не вярваме, че това може да е пътя напред.

Иновацията и разработката на софтуер позволяващ работата без нужда от позволение е от критична нужда

Ние (MaidSafe) изграждаме мрежа без нужда от позволение. Какво точно значи това?

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

Вярваме че най-големият напредък идва от това да допуснем всеки да създава.

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

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

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

Отворете вратите и ще се изненадате от къде идват отговорите.

1 Like

SAFE Network - резюме за юли

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

Нови версии на софтуера

Голямата новина през юли е представянето на първата версия на SAFE мобилния браузър ! Усилената работа на програмистите ни в Ченай и разбира се усилията на екипа тестващ софтуера, поправката на бъгове и QA – дадоха своя плод. За да се убедите, в качеството на работата ни е достатъчно да свалите браузъра и да го тествате, независимо дали сте с Android или iOS устройство, също може да прочетете за бъдещите версии тук.

Пуснахме и нова версия на Десктоп Браузъра , за да отстраним някои малки бъгове. Може да свалите последната версия v0.14.1 от тук.

Завършени задачи

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

Завършихме и задачата по поддръжката на файловите контейнери в CLI-то . Това значи, че вече може да създавате (публикувате) ФайловиКонтейнери като качвате файлове или цели папки със safe командата за качване. Може също така да извличате и показвате съдържанието на ФайловитеКонтейнери и файлове (публикуваната НепроменимаИнформация) чрез XOR-URL адреси чрез safe CAT командата. Може и да обновявате вече създаден ФайловКонтейнер чрез синхронизация с локални промени направени по файлове и папки чрез командата за синхронизиране на safe файлове. Може да видите колко лесно е да качвате информация в SAFE мрежата от команден ред като посетите GitHub страницата ни.

В прогрес

Трезорите идват, като много от задачите по първоначалното въвеждане са завършени или близо до завършване. Има някои висящи малки задачи които, макар и малки, ще поставят основите на следващите фази. Следващата стъпка е да тестваме SAFE Клиентските Библиотеки с новите Трезори. Очакваме да има някои проблеми, но тези тестове ще ни позволят да разберем къде точно са за да ги отстраним.

Въвеждането на новите типове данни в SAFE Клиентските Библиотеки се приближава към завършване. Работата този месец беше насочена към подмяната им с новите типове данни в SAFE Удостоверителя (включително новия пакет за влизане и промяната на потока на акаунта).

Стартирахме нов проект за SAFE CLI по въвеждането на Система за разрешаване на имена (Name Resolution System – NRS), това е системата, която позволява използването на четими от хора URL адреси. Също като URL адресите в стария интернет днес, те са (в повечето случаи) ясни и лесни за разбиране, и най-вече за запомняне, и затова искаме да ги въведем в SAFE мрежата.

Този месец се съсредоточихме и върху Предния край ( Front End) . Всяка задача: Вечната Мрежа, Поеми контрол върху информацията си, Частни комуникации и Новата Дигитална Икономика получи своя публикация в Медиум, където разгледахме защо всяко от тези четири неща е толкова важно и защо ги въвеждаме в SAFE Network. Паралелно напредна и работата по дизайна на Вечната Мрежа. Може да видите повече тук.

Събития

Имахме среща на общността в Глазгоу, на която инженера от МейдСейф – Жан говори за Трезорите и как SAFE ще промени взаимоотношенията ни с нашата информация. Предстои да обявим датата за следващата среща.

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

Това е всичко основно от юли, като подробна информация може да намерите както винаги във форума на международната общност: SAFE Network Forum

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

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

1 Like

Нова версия на SAFE браузъра отваря пътя към Вечната мрежа

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

Какво е това?

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

Така, какво точно може да правите с него?

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

На първо място може да отваряте сайтове или чрез техните NRS-URL адреси или чрез XOR-URL адресите им (това са двата типа интернет адреси в мрежата) и да разглеждате различните исторически версии на сайтовете. Това ви позволява да видите разликите и промените във всяка версия. Пълна прозрачност за всяка промяна плюс кога е била направена.

В тази версия добавяме и изключително полезната функция за създаване/запазването на NRS име (Система за разрешаване на имена/Name Resolution System), ако все още не е било регистрирано от някой друг. Ако въведете име на сайт с NRS адрес, който не съществува ще получите възможност да регистрирате това NRS име (и съответно ще го притежавате завинаги без месечни/годишни такси в акаунта си).

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

Като алтернативен метод сайтове могат да се качват и публикуват под NRS име чрез SAFE CLI, така след публикуване могат да се свалят или с CLI-то или чрез SAFE Browser. Важно е да отбележим: все още не е възможно да редактирате сайт ако е качен чрез CLI-то — или обратното. Това е временно ограничение, което ще бъде премахнато щом активираме поддръжката на споделяне на разрешения между програмите. Така ще имате допълнителна функционалност, когато решавате как да качвате файлове в мрежата.

Това звучи отлично — от къде да сваля браузъра?

Просто отидете в GitHub и го свалете. Важно е да отбележим: ще имате нужда и от следните няколко неща:

  • Трябва да имате стартиран SAFE_удостоверител
  • Трябва да се свържете със споделен или локален Трезор( т.е. тази версия на браузъра не работи с Алфа 2 ). В това Ръководство може да намерите информация как да стартирате Трезор ако все още не сте го правили.

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

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

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

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

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

1 Like