SAFE Network новини – 21.11.2019
Накратко
Ето някои от основните неща тази седмица:
- Пуснахме нова алфа версия на приложението SAFE Network.
- @JimCollinson публикува някои идеи за това как може да бъде пуснат достъп до разрешенията за приложения и данни на крайните потребители (вижте секцията SAFE Network App UX по-долу).
- Премахнахме емулацията на BLS и сега използваме истински BLS само в рамките на маршрутизирането.
- Благодарение на члена на общността @danda е добавена нова функция в SAFE CLI, която позволява на потребителите да извличат съдържанието на всеки файл под формата на хекс файл (dump)
Срещи на общността
Днес се провеждат две срещи на общността.
Първата среща е в Малмьо, Швеция, и би трябвало да се провежда в момента! Срещата беше организирана от @oetyng.
Втората среща е в Брайтън, Англия и @dirvine ще присъства онлайн, за да даде на участниците информация за най-новите новини в MaidSafe и да отговори на въпроси.
Ако се появи видео запис на която и да е среща, ще го споделим с вас.
Припомняме, за да следите графика на предстоящите срещи вижте страницата на събитията във форума за подробности около всичко свързано със SAFE Network.
Трезори – Фаза 2
Тази седмица продължаваме да проектираме и внедряваме процеса за стартиране и присъединяване на клиенти. С новия поток за присъединяване, клиентите ще се опитат да намерят секция, която да ги управлява като пратят запитване към трезорите. Ако избраният Трезор не е мениджъра на клиента, той ще върне информацията за връзка към секция, която е най-близка до секцията за управление на клиента, и клиентът ще повтори процеса на зареждане, докато не достигне търсената секция. Така работи и процесът на стартиране на възлите, така че ще използваме отново някои от функциите за вътрешно маршрутизиране, за да въведем този процес от страна на трезорите.
Както може би сте забелязали, това е първата важна стъпка към поддържането на множество секции, което ни приближава до реалните условия на мрежата. Решихме, че като цяло е по-добре да въведем функционалностите на мрежата с възможно най-малко предположения, тъй като някои проблеми може да не са очевидни в опростената среда (например в случай на мрежа с една секция). И макар че с този подход може да нямаме много вълнуващи демонстрации, докато напредваме заедно, в дългосрочен план това ще ни помогне да пуснем Флеминг (Алфа 3) по-скоро.
SAFE CLI
Тъй като се приближаваме много близо до нови версии на safe-api и safe-cli , инвестирахме малко усилия в изготвянето на ръководство в основното safe-api хранилище, преместихме ръководството за потребителя на CLI в папката на safe-cli , както и добавихме ръководство за safe-authd . Включихме и няколко диаграми, които, надяваме се, ще ви дадат по-добра представа как всички тези компоненти се вписват заедно в екосистемата на SAFE приложенията от гледна точка на използващите мрежата.
Работихме върху малко преструктуриране на интерактивната обвивка на CLI-то. С това преструктуриране вече можем да поддържаме всички команди, които обикновено се поддържат от командния ред, със същия синтаксис и опции, но от интерактивната обвивка. Това ще гарантира, че командите са последователни както в командния ред, така и в интерактивната обвивка, тъй като вътрешно операциите се извършват от един и същ код.
Също така бяхме много доволни, че видяхме нова функция, внедрена от потребител в GitHub @dan-da (благодарим много @danda !!!), която позволява на потребителите да извличат съдържанието на всеки файл под формата на хекс файл използвайки команда cat --hexdump . Съответните инструкции също бяха добавени към ръководство за потребителя, където може да разберете повече за тази нова функция.
И накрая, също така започнахме да внедряваме JSON-RPC за комуникационния протокол на safe-authd . Трябваше ни прост формат, за да можем да изпращаме някои структури през QUIC, напр. цялата информация за заявките за удостоверяване или списъка с разрешенията, предоставени на всяко позволено приложение, и JSON-RPC позволява наистина лесно да сериализираме тези видове структури от данни с минимални разходи. Стремим се да поддържаме спецификацията JSON-RPC v2.0. Напреднахме доста с това през последните няколко дни, така че ще можем да го включим към първото издание на safe-authd .
SAFE Клиентски библиотеки
Тази седмица SAFE Клиентските библиотеки получиха своя дял работа. Преценихме, че създаването и поддържането на множество CI / CD платформи е голямо затруднение за екипа, тъй като те са склонни да се развалят от време на време. Затова решихме да опитаме новата вътрешна CI платформа на GitHub Actions, която се оказа доста ползотворна. Тя е по-тясно интегрирана с GitHub, по-гъвкава е и е доста бърза, въпреки че все още не сме настроили кеширането. Голямо благодаря към @chriso, @marcin и @StephenC за работа по стартирането на GH Action за SCL, safe-nd и safe-api.
Също така сме в процес на завършване на голямо преструктуриране на клиентски ключове. Тази работа ще приключи следните проблеми: #1060, #1053 - моля, вижте ги за повече информация. Това преструктуриране актуализира и версията на rand , която използвахме, като премахва много остарялата функционалност. Необходимият PR в safe-nd вече е прегледан и обединен, а PR в SCL е одобрен и чака CI.
Имаме доста работа, която ни чака по премахването на контейнера на Rust Sodium. За да дадем малко предистория тук, Rust Sodium е контейнер за крипто услуги, поддържащ повечето от алгоритмите ни за криптиране, които използваме в SAFE клиентските библиотеки и Само-криптирането. Причината за това оттегляне е, че Rust Sodium използва C зависимости, което е малко проблематично при настройването на CI / CD за контейнерите, които използват Rust Sodium. Затова планирахме да мигрираме далеч от този контейнер в нашите хранилища и да запълним празнината с подходящи контейнери. Задачите бяха зададени и работата по отделянето на Rust Sodium започна.
С успешното сливане на PR#1069 премахването на MaidSafe Utilities вече завърши. Незначителна промяна по конфигурационния файл работещ с API-тата трябваше да се направи като страничен ефект от това. Новите предоставени API-та са set_config_dir_path и config_dir . Те са основно функции за получаване и задаване за пътя, където се очаква да бъдат конфигурираните файлове (safe_core.config, vault_connection_info.config, log.toml и т.н.).
Незначителна поправка ще влезе в safe_authenticator с PR#1076. Това позволява на приложенията, които са повторно удостоверени да изискат нови разрешения за контейнери и да ги актуализират съответно в контейнера за достъп на потребителя.
SAFE Network програма UX
Последните няколко спринта насочиха вниманието ни към разрешенията за приложения и данни: как потребителят ще упражнява контрол върху достъпа до личните си данни, поверителността и разходите си. Не става въпрос само за SAFE Network програмата - това ще включва проектиране на архитектурата на тези контроли на мрежово ниво - но и проучването как тези инструменти за контрол могат да станат достъпни за крайните потребители ни помогна да проучим проблема като цяло.
Степени на намеса
В интерес на това да осигурим гладко, разбираемо преживяване и да поставим контрола върху разрешенията на приложението, където е представен рискът, можем да помислим за различни степени на намеса в пътя на потребителя. И именно от тези интервенции можем да започнем да конструираме преживяването му.
Без намеса
Разрешението е предоставено без уведомяване на потребителя.
Това ще бъде използвано за действия, които носят нисък или никакъв риск за сигурността на потребителя или техните пари (Safecoin).
Например, приложение може да получи достъп за четене и писане на лични данни, които потребителят е създал чрез това приложение, без потребителят да бъде уведомен в реално време, нито да трябва да е предоставил предварително съгласие.
Пасивна намеса
Потребител е известен или уведомен по друг начин, че е дадено разрешение, но не е необходимо да предприема конкретни действия.
Пасивните интервенции могат да се използват при обстоятелства, при които рискът за сигурността на потребителите е нисък, но все още има възможност лоши или злонамерени приложения да причинят неудобство или умерени разходи.
Например запазването на „UnpublishedData“ е с нисък риск за сигурността на потребителя, но има разходи за Safecoin.
Ако например има ограничения на разходите на ниво приложение и глобално, потребителя може да получи лек, самоотхвърлящ се сигнал, когато ново приложение започне да прави разходи, и по този начин може да бъде информиран и може да се намеси пряко, без да е необходимо да се прекъсва потребителското му изживяване.
Може да очаквате пасивна намеса и да не бъдете алармирани и ако просто натиснете бутона за редактиране в ново приложение, но ако работите по нещо друго и изведнъж дузина нови известия на приложения мигат пред вас, значи имате възможен проблем.
Тук ви показваме как може да се проявят пасивните известия. Информативни, с възможност за пренебрегване, но позволяващи контролируемо действие, ако прецените да се намесите.
И тук можем да видим някои от опциите за тези пасивни известия.
Ясно обособени, навременни намеси
Използването на приложение е блокирано, докато потребителят не предприеме действия.
Това е за действията, при които рискът е голям, като например публикуване или споделяне на данни, или когато дадено действие може да доведе до значителни разходи.
Потребителят е прекъснат и е помолен да вземе решение, преди да може да продължи.
Ето някои екрани, които да ви дадат представа как това може да работи:
Предварителни разрешения
Позволява на потребителя да избере предварително, какви разрешения ще има дадено приложение.
Ако потребителят желае може да избере да бъде подканен да провери и потвърди разрешенията на приложение преди да го използва за първи път.
Този вид предварителна намеса е малко вероятно да представлява част от настройките по подразбиране, тъй като предварително да се дадат на потребителите много възможности за избор, за на пръв поглед по-голям контрол, в действителност може да го намали поради „изскачаща“ умора и парализа на избора. Трябва да се стремим към сигурно и лесно изживяване, което дава на потребителите смислен избор, така макар че предварителните разрешения ще са налични като избор, ще подходим към тяхното внедряване внимателно.
Активиране на полезни настройки по подразбиране
Тези настройки ще бъдат достъпни на ниво приложение и в крайна сметка до нивото на файлове и папки, което позволява на потребителите наистина да имат пълна власт над дигиталния си живот. Това е доста голяма хапка за начало, така че ще го правим стъпка по стъпка. Можем също да помогнем с подобряване на изживяването на потребителите и да им дадем възможност да балансират пълния контрол с ниска интервенция, като предлагаме полезни настройки по подразбиране на ниво акаунт.
Ето пример за това как можем да предложим някои полезни предварителни настройки по време на създаването на акаунта:
И така, общо взето доста неща се събират тук, обхващайки много повече от SAFE Network програмата, навлизайки по-дълбоко в изживяването на мрежата като цяло. През следващите няколко месеца ще има още много неща, така че ще се радваме да разберем вашето мнение. Оставете коментар във форума.
SAFE Network програма десктоп разработка
След като финализирахме и тествахме новата настройка на канала за пускане на нови версии, тествахме алфа издание на SAFE Network програмата. Това показа някои проблеми с оформления, заявки и Windows. Днес имаме някои подобрения, за да стартираме успешно програмата под Windows. Проблемът е, че Windows се нуждае от разрешение за стартиране на safe удостоверяващия процес. Така изглежда, че при стартиране / спиране на SAFE Network App ще има потвърждения за удостоверяване, когато приложението стартира / спира (и инсталира, ако е необходимо) фоновата услуга. Това е неизбежно на този етап, за съжаление, но най-малкото, което ни позволява е да имаме достъп до функцията за удостоверяване.
Относно каналите за пускане на нови версии:
В бъдеще се надяваме да пускаме по-чести актуализации на нашите настолни приложения и това означава, че ще имаме три вида издания.
Ще има нормални версии. Те ще бъдат най-стабилни, а също и най-редки. Ако не сте готови да изпробвате нови промени / подобрения или да се включите чрез съобщаване на проблеми в GitHub, това ще бъде каналът на вашите версии!
Бета версиите ще бъдат малко по-чести. Ще бъдат нещо като предварителни версии, където може да има проблеми, но да се надяваме, че няма да има. Ако искате да проверите какво е новото и нямате нищо против случайните технически проблеми, това е за вас.
Алфа изданията ще бъдат най-новите, но и най-нестабилните версии. Който го е страх от мечки… да не гледа тук. Но ако искате да ни помогнете да откриваме и отстраняваме грешки и нямате нищо против да си изцапате ръцете в GitHub, вашата помощ ще бъде високо оценена!
Всеки канал за пускане ще получава автоматично актуализации за този канал или и тези над него, т.е. SAFE браузър алфа ще се актуализира с всякакви нови алфа версии на браузъра, както и с бета и стабилните версии. Бета приложенията ще получават само бета и стабилните актуализации и т.н.
В момента за SAFE Network приложението все още е активиран канала за пускане за управлявани актуализации на приложенията. Но скоро ще го добавим (така че SAFE Network App Alpha ще инсталира само SAFE Browser Alpha).
Ако искате да пробвате новата алфа версия на най-новото приложение на SAFE Network, v0.0.5-alpha.2, можете директно да го изтеглите от GitHub тук. Моля опишете всички проблеми, които срещнете, в GitHub тук, за да ги проследим.
SAFE браузър (десктоп)
Новата настройка на канала за пускане, обсъдена по-горе, бе въведена с помощта на SAFE браузъра тази седмица. Тествахме вътрешно пускането на множество Alpha и Beta версии и с няколко редакции успяхме да потвърдим, че поведението на актуализацията между различните Alpha версии и между Alpha и Beta версиите е според очакванията. Сега когато сме готови с това ще пуснем нова алфа версия през следващите дни с актуализирани зависимости, включително незначителна electron поправка и обновление на safe-nodejs до версия v0.5.1.
SAFE браузър (мобилни устройства)
Започнахме да надграждаме мобилния браузър, за да поддържаме новите версии на ОС Android и iOS. Това включва много трудна работа, като актуализиране на библиотеките, премахване на остарял код за използване на API и актуализиране на логиката на потребителския интерфейс, за да работи на всички устройства.
Миналата седмица пуснахме първата версия на пакета MaidSafe.SafeApp NuGet, а тази седмица започнахме да актуализираме браузъра, за да използваме новите API-та за Fetch и Inspect . С тези промени можем да разглеждаме уебсайтове от локални / споделени трезори.
Следващата голяма крачка за мобилния браузър е да се даде възможност за pWeb изживяването (разглеждането на предходните версии на сайтовете в мрежата). Вече започнахме да прилагаме някои от функциите и резултатите са много вълнуващи.
Ранен преглед на функциите в процес на разработка:
SAFE удостоверител (мобилни устройства)
Измина доста време откакто пуснахме нова версия на мобилното приложение за удостоверяване. С всички промени в API–тата на safe_client_libs и как да използваме локални / споделени трезори за тестване на приложения и уебсайтове, смятаме, че е време да обновим и Удостоверителя, за да осигурим поддръжка на всички нови подобрения.
Досега актуализирахме използваните пакети, основните библиотеки, SCL връзките и API-тата на C # до най-новото главно хранилище. Все още остава да актуализираме потребителския интерфейс, за да отразява тези промени, към които сме насочени за следващата седмица.
Успоредно с това работим върху приятна функция в Удостоверителя - тази функция ще предостави на потребителите възможността да се свързват с различни локални / споделени трезори само като изберете файла vault_connection_info.config . Тази функция позволява на потребителите лесно да се свързват с различни работещи трезори за тестване и експериментални цели, без да се притесняват от техническите аспекти.
SAFE App C#
Тази седмица направихме някои промени преструктурирайки API-то за извличане и проверка. Преди това тези API-та връщаха FilesMap (списък на файлове в FilesContainer ) като низ JSON и така разработчиците не бяха в състояние да използват езикови функции като запитване на данните, без да ги десериализират в C # типове.
След преструктурирането, сега разработчиците получават тип C # и могат директно да извършват всяка операция върху данните, без да извършват десериализация. Актуализирахме и тестове ни, за да гарантираме, че тези промени са стабилни.
Стареене на възел (Node Ageing)
Работата по изчистването на PARSEC е завършена, което предотвратява възможните проблеми от твърде голямото нарастване по размер на информацията в парсек. Имаме и напредък в работата с разпадането на връзката между компютрите чрез проследяване на отпадането й. Имаме няколко варианта за разрешаване на проблема с масовото гласуване поради новия модел на тестване. Започнахме и работа по тестването и внедряването им, за да се сравни кое от тях би било най-подходящото решение.
Продължаваме да напредваме и с даването на правомощия / качването на рейтинга на Възрастните до Старейшини и свалянето им от позиция на Старейшини до Възрастни. Редица от тестовете са успешни, а по неуспешните вече работим за решение.
BLS
Успяхме да напреднем по няколко елемента от BLS проекта, по-специално с тази промяна, премахваме BLU емулацията и използваме истински BLS само в рамките на маршрутизирането. Все още има някои груби ръбове, които ще изгладим, докато напредваме по останалите задачи.
Полезни линкове
- Официален сайт на SAFE Network
- Обобщено представяне на SAFE Network
- SAFE Network Фундаменти
- Карта на проекта
Подробна информация може да намерите както винаги във форума на международната общност: SAFE Network Forum
Ако имате въпроси може да ги зададете във Facebook групата на българската SAFE общност: SAFEnetwork България | Facebook
Ако искате да следите последните новини заповядайте във Facebook страницата на SAFE Network България: Safe Network България