SAFE Network новини – 23.1.2020
Накратко
Ето някои от основните неща тази седмица:
Споделен Трезор
Моля, обърнете внимание, че днес рестартирахме и изчистихме всички данни от нашия хостван споделен Трезор. Това беше необходимо, тъй като започвахме да откриваме проблеми със съвместимостта с част от съхранената там информация и последните актуализации, които направихме. Запазването на информацията би затруднило да се каже дали намереният проблем е истински или поради несъвместимост. Това означава, че всички потребителски акаунти и сайтове на споделен Трезор са премахнати.
Извиняваме се за причиненото неудобство.
Очакваме с нетърпение отново да видим тестовите ви сайтове, но имайте предвид, че това е тестов трезор и няма съмнение че ще има моменти, в които трябва да го изтрием и рестартираме отново. Винаги правим всичко възможно, за да избегнем това, когато е възможно.
Можете да изтеглите новия конфигурационен файл vault_connection_info.config от тук.
Или ако използвате CLI, можете да използвате командите safe networks add и safe networks switch , например:
$ safe networks add shared https://safe-vault-config.s3.eu-west-2.amazonaws.com/shared-vault/vault_connection_info.config
Network 'shared' was added to the list. Connection information is located at 'https://safe-vault-config.s3.eu-west-2.amazonaws.com/shared-vault/vault_connection_info.config'
$ safe networks switch shared
Switching to 'shared' network...
Fetching 'shared' network connection information from 'https://safe-vault-config.s3.eu-west-2.amazonaws.com/shared-vault/vault_connection_info.config' ...
Successfully switched to 'shared' network in your system!
You'll need to login again, and re-authorise the CLI, if you need write access to the 'shared' network
Можете да намерите пълни инструкции за свързване към нашия споделен Трезор или как да пуснете свой, тук.
Трезори – Фаза 2
План на проекта
Отстранявахме грешки при проблема с изчакването на заявки. Като част от работата по разследването открихме и разрешихме проблем, който е само за Windows, за тестовете при една Секция. Проблемът беше в клиентския код, който използва фиксиран порт за quic-p2p, който противоречи на порта, използван от трезора.
След като този проблем бъде решен, проблемът с изчакване на заявката допълнително се стеснява до изтичане на времето за заявка за съхранение, което е в рамките на един тест, който изпраща няколко заявки едновременно. Трезорите в секцията започват да гласуват за транзакциите, свързани с тези заявки и потреблението на памет се качва, причинявайки срив на един или повече от трезорите. Сега разграждаме процесите на трезора, за да идентифицираме кои компоненти допринасят за този пик на паметта и потенциалните начини за оптимизирането им. Вече имаме няколко варианта, но бихме искали да тестваме още, преди да изберем един от тях.
SAFE API
План на проекта
Много сме развълнувани да споделим ново издание на safe-api артефактите днес. Тези нови версии надграждат safe_client_libs до най-новата версия 0.13.0 версия в safe-api v0.7.0 . Публикуваме и съответната нова версия на safe-nodejs (v0.7.0), която обновява safe-api.
Тази версия също идва с нови версии на safe-cli (v0.7.2) и safe-authd (v0.0.2) , но най-важното е, че с тези нови версии потребителите вече могат да инсталират safe-authd с помощта на CLI ( $ safe auth install ) и също така ще може го актуализирате, когато бъдат публикувани нови версии на authd ( $ safe auth update ). Authd файла се инсталира по подразбиране в домашната директория на потребителя под ~/.safe/authd/ , което също прави ненужно за потребителите на CLI да определят пътя на файла safe-authd, когато го извикват с auth safe-cli командите, и няма нужда да задавате място за съхранение в системата. Актуализирахме Ръководството за потребителя за CLI с новите подробности за инсталирането на safe-authd, така че моля, обърнете се към него за конкретна информация и, разбира се, моля споделете всички проблеми, с които се сблъскате за да ги разрешим.
Като паралелна задача с нисък приоритет инвестирахме и известно време в опит да мигрираме внедряването на authd, да използва новия синтаксис за асинхронизация / изчакване на Rust, само за да видим с какви проблеми може да се сблъскаме и да започнем да се учим от тях. В крайна сметка разработихме първия проект за изпълнение на тази миграция и използваме най-новата версия на quinn. Тази миграция също опростява внедряването на authd, като я прави по-чиста и лесна за поддържане. Засега спряхме тази задача, тъй като тя се нуждае от quic-p2p и quinn, да бъдат надстроени в Трезорите и SCL, преди да можем да продължим по-нататък.
В допълнение, работим върху някои допълнителни функции към CLI-то, които бяха предложени от общността, напр. въвеждането на files ls и files tree команди. Работим и върху xorurl decode команда, която ще позволи на потребителите да видят цялата информация, която е кодирана в XOR-URL, т.е. xorname, маркер тип, тип съдържание, общия тип данни, за който се поддържа целевото съдържание и т.н.
Стремим се към по-редовни версии на CLI сега, когато имаме нашите CI скриптове, способни да пуснат само един артефакт наведнъж, ако желаем (плюс CLI и командите за актуализиране на authd), следователно се надяваме новите функции да се слеят в основния клон не след дълго и да го пуснем.
Етикети за данните, индексиране и оторизиране на маркери
RFC, План на проекта
Тази седмица успешно усъвършенствахме базовата реализация на маркерите в safe-nd и това вече се използва както при Трезорите, така и в SAFE Клиентските библиотеки, с добавени тестове за проверка на генерирането на маркери, подписването, основните предупреждения и проверка за валидността на маркерите.
Това е краят на първата част по работата с маркери, което ще осигури добра основа да направим тези маркери действително полезни. Въпреки че все още не сме готови да внедряваме етикети, следващите стъпки трябва да включват действителното генериране на предупреждение и проверка за някои операции, да проверим и добавим повече тестове за това, преди в крайна сметка да можем да премахнем настоящия си код за удостоверяване за същите тези операции.
Уточняване на видовете данни
RFC, План на проекта
RFC-а беше актуализиран с опростяване на контрола за съвместимост, което опростява наличните типове данни до три ( Blob | Map | Sequence ), налични в две области ( Public | Private ), което прави общо 6 варианта. Можете да прочетете за подробностите тук.
Освен това, от миналата седмица има заявка за PR към safe-nd за прилагането на Sequence , а сега е включена и горната промяна.
Членът на общността @tfa съобщи за възможни области, които се нуждаят от разяснения в RFC-а, и плануваме да го актуализираме през следващите дни, за да стане по-ясно какви свойства и възможности ще се съхраняват и какво ще видим допълнително.
Уточняване на йерархията на данните
RFC
@oetyng работи върху разширение за Уточняването на типовете данни RFC, което се занимава с обектната йерархия в мрежата.
Днес членът на общността @jlpell доведе дискусията за Уточняване на типовете данни към тази съседна тема, по която работихме паралелно. Там той представя вариация на възможна йерархия на обектите.
Тъй като това съвпада с настоящата ни работа, публикувахме RFC-а във форума, за да продължат дискусиите там. Работата е на ранен етап, но искаме да ви включим по-рано, така че отидете в темата и хвърлете един поглед!
RFC обобщение
Предложението описва система, при която всички типове данни са изградени от парчета и заедно с отделените метаданни извършва еднакво обработване на данните за всички видове структури от данни. Това също решава устойчивостта на типовете AppendOnlyData / MutableData .
Цялото съдържание е разделено от парчета информация. Съхраняването на парче е организирано в различни видове структури от данни (наричани също типове данни), където данните, съхранявани в структурата, сочат към парче или набор от парчета. Имената на структурите от данни са следните:
Blob , чиято структура е просто единично парче от данни.Sequence , чиято структура е последователност от данни.Map , чиято структура е набор от уникални ключове, и набор от стойности на данни, където ключ сочи към стойност.Shell модел съхраняващ информация за типа данни, като действителната структура с показалеца/ците към парчето/тата, име, маркер тип, собственик и разрешения.
С други думи; потребителят може да постави всякакъв тип данни във всяка структура, разделянето на данните работи по същия начин, независимо от типа на данните.
SAFE Network програма
Проследяване на подробностите
Тази седмица продължихме с фокуса си върху потребителското изживяване при даването на достъп до информацията ви и как може да прилагате и управлявате достъпа до конкретни файлове, папки или данни с „етикети“.
И така, представяме ви разяснение на нашето мислене и до какво се свежда.
Ако вземем пред очи потребител, който има куп данни, които притежава и контролира чрез своя акаунт. Това могат да бъдат отделни файлове или папки, съдържащи файлове и други папки.
Информация притежавана от Акаунт
Или може да бъдат labels (етикети), начин за групиране, организиране и насочване към множество различни файлове и папки, които могат да се намират на различни места. Например, да кажем, създавате си „интелигентна папка“, която следи всички ваши аудио файлове.
Етикетите помагат за групиране на информацията
А от другата страна на нещата имаме програми и други потребители, на които може да искате да дадете достъп до своите данни, за да може да свършите работа.
Програми и други потребители
След това даваме на потребителите инструменти, с които имат възможност да задават разрешения и да контролират достъпа до данни си, как могат да бъдат достъпвани, до каква степен, от кого и за колко време.
Разрешенията помагат на потребителя да контролира достъпа до своите данни
Като бележка, тук си струва да се подчертае, че за разлика от стария интернет, използването на тези настройки за даване на достъп до вашите данни на дадено приложение не е същото като разрешаването на достъп на друг потребител до него. По-скоро е като да си дадете сами разрешение за манипулиране на данни с помощта на конкретно приложение, което след това можете да използвате, за да позволите достъп до тези данни на други хора, ако решите.
Така предизвикателството пред UX дизайна става как точно да дадем възможност на потребителите да задават тези разрешения, упражнявайки контрол върху достъпа до отделни файлове.
Имаме начин да зададем разрешенията по подразбиране за дадено приложение, което може да си представите като поредица от превключватели, позволяващи на приложението да вижда, редактира, публикува и споделя данни и да определя продължителността, през която тези разрешения трябва да бъдат включени.
Подход за превключване на разрешенията
Един от вариантите е да разширим този начин на мислене. Потребителите могат да променят тези превключватели за дадено приложение на индивидуално ниво за всеки файл, персонализирайки достъпа и продължителността.
Но проблемът след това се свежда до разбирането на резултата, който ще се получи от сложната последователност от превключватели.
Например, какво се случва след като се разлогнете в този случай? Приложението получава ли права за споделяне и редактиране? Или изобщо няма никакви права?
Подхода на прокламацията
Така че друг начин на мислене за това е сходен с прокламациите, като тези, използвани в авиацията. Прокламацията изброява подробности за въздухоплавателното средство, местоназначението, пътниците, товара и правните инструменти, като се отбелязва собствеността върху съдържанието на самолета. Без прокламация няма полет.
Ако приложение или друг потребител се нуждае от достъп до някои данни, те изискват прокламация, в която са посочени техните разрешения и продължителността им, заедно с други удобни метаданни.
Тази прокламация може да бъде създадена по подразбиране от глобалните разрешения или да бъде предоставена изрично, но може да бъде изменена или изтрита изцяло от потребителя. Без прокламация няма игра.
Това е фина промяна, но ни помогна да се усъвършенства идеята ни за това как да се подходи към потребителското изживяване като цяло.
Така че, нека да разгледаме някои примери за потребителски интерфейс, които изготвихме за SAFE Network програмата.
Страница с подробности за файла, със списък на прокламации
Тук имаме страница с подробности за файл, а най-отдолу можем да видим емисия с възможност за сортиране и филтриране на всички приложения и хора, които имат някакво ниво на достъп до lions.jpg .
Всички те имат валидна прокламация.
Може да влезете и да разгледате подробностите на всяка една от тях:
Екран на прокламацията
И може да влезете и да редактирате тази прокламация, като например премахнете разрешението за редактиране; добавите разрешение за споделяне; избирате продължителност за достъп.
Редактиране на прокламация
Тези настройки в края на страницата може да изглеждат доста прости и с наборите от разрешения, които имаме за първоначалната версия, може и да са, но придвижването на нещата от там могат да бъдат разширени, за да включват повече подробни „рецепти“ и т.н., за по-специфичен контрол.
Така че може да видите тези прокламации на ниво файл, папка или етикет, но разбира се може да получите достъп до тях и за директната програма.
Прокламации, показани на екрана с подробности за приложението
Може също така да получите заявка от приложение (или друг потребител) за набор от разрешения. Ще трябва да прегледате прокламацията и да я редактирате, ако е необходимо, преди да я приемете или да я отхвърлите директно.
Екран за искане на разрешение
Това може да включва и метаданни от разработчика на приложението, обяснявайки защо се нуждаят от разрешенията, подпомагайки потребителя във взимането на решение.
Тези заявки и прокламации като цяло също могат потенциално да бъдат управлявани чрез глобална емисия, като допълнително подпомагат тяхната финалност и дават на потребителя по-добър преглед къде се намират неговите данни, особено когато нещата станат малко по-фини. Това е нещо, което ще изследваме повече, когато навлезем по-задълбочено.
И така, това е, преглед на работата, която вършим по отделни разрешения за файлове и данни.
Обръщаме внимание към @m3data за това, което върши в стария интернет със сходни проблеми на потребителското съгласие и чиито вдъхновяващи блогове и документи ни бяха много полезни в работата по всичко това.
SAFE браузър / SAFE Network програма (десктоп)
Започнахме кръг от актуализации и за двете приложения. Направихме пълни версии на предишните бета версии и за двете (макар и без нови функции). Но междувременно работим и върху актуализирането на зависимостите в цялата област и подготвяме нещата за следващата партида актуализации за safe-api. За браузъра няма твърде много вълнуващи неща (извън очевидното вълнение от подобрено API 
).
Приложението SAFE Network ще стане малко по-лъскаво, с функция за фокусиране на приложението, когато получава заявки (проста опция, но със забележимо отсъствие, което водеше до това потребителите да не забелязват заявките преди да е станало твърде късно). Освен това разглеждаме как safe-authd е настроен от приложението и как най-добре това може да работи за напреднали потребители, които може би вече имат инсталиран safe-cli и safe-authd .
Тъй като стигаме до стандартизирано място за инсталиране за safe-cli , се спираме на подход, който ще позволи на SAFE Network App да управлява CLI-то като всяко друго настолно приложение (все пак ще можете да го управлявате независимо от SAFE Network App, ако искате), откриване на неговото инсталиране или подкана за инсталирането му, ако липсва.
SAFE браузър / SAFE Удостоверител (мобилни устройства)
Актуализирахме README файловете за двете хранилища и премахнахме остарялото или свързано с алфа 2 съдържание. Потребителското ръководство на Удостоверителя бе променено да включва ръководство за инсталиране и връзки за изтегляне от AppCenter и QR кодове.
Настройките на CI на двете хранилища също бяха актуализирани, за да опростят допълнително процеса на автоматизирано изграждане и пускане. И двете хранилища вече поддържат автоматичното създаване на GitHub версии за PR за промяна на версията, заедно със създаването на нови версии за AppCenter.
За да завършим цялата работа, която вършехме през последните няколко седмици, започнахме да тестваме и двете приложения за пускане 
и паралелно, поправяме всички грешки, които срещаме по време на това тестване.
SAFE App C#
План на проекта
През последната година използвахме услугата CI на Azure DevOps за изграждане на safe_app_csharp и за тестване върху всички поддържани платформи. Използвахме настройка, базирана на потребителски интерфейс и понякога беше трудно да актуализираме новите версии. Тъй като използваме GitHub Actions за повечето от хранилищата ни и станахме по-добри в работата с YAML конфигурационни файлове базирани на CI настройка, актуализирахме хранилището, за да използваме YAML базирана настройка за нови издания. Това ще улесни всеки, за да разбере и променя CI според нуждите си.
Активирахме публикуването на кодово покритие в Coveralls, което беше деактивирано за последните няколко месеца, тъй като новите API-та не бяха достатъчно стабилни. Бяха направени някои други промени, за да се отстрани проблемът с генерирането на документация за пакета, въпреки че все още трябва да включим автоматичното публикуване на документите на страниците на GitHub, върху което ще работим следващата седмица.
Safecoin фермерство
RFC
Тази седмица направихме няколко последователни диаграми за трансфери на Safecoin и продължихме с дискусии за дизайна на Safecoin и фермерството.
По-специално, имаше известно обсъждане / вълнение около използването на безконфликтни репликирани типове данни (CRDT) за подобрена устойчивост на грешки в мрежата, закъснения, проблеми извън нормалното и т.н. Така започнахме работа по моделиране на всеки CoinBalance като CRDT със строго добавени колони за кредит / дебит и периодични запаметявания.
Имаше и кратка, импровизирана дискусия около идеята за използване на заслепени сертификати за цифрови носители в SAFE мрежата. Заслепени цифрови носители на сертификати (DBC) са предложени за първи път от Дейвид Чаум през 1983 г. като форма на цифрови пари в брой, която осигурява пълна несвързаност между плащанията и дори може да бъде прехвърлена офлайн. Дори издаващият орган не знае на кого е даден сертификат. Сертификатите могат да бъдат комбинирани за образуване на нов сертификат с по-голяма сума или разделени за извършване на по-малки плащания. Ник Сабо има приятен преглед на DBC в анализа си за договори с носител от 1997 г. DBC-тата обаче винаги са разчитали на централизиран сървър с една точка на отказ, който можем да избегнем поради груповия консенсус (секция със Старейшини).
През 2016 г. theymos (известен от форума Bitcointalk) пусна тема, в която описва как DBC може да се използва с децентрализирана система като Bitcoin. Това е интересен мисловен експеримент, в който да разгледаме дали / как би могъл да работи в SAFE мрежата или като заместител на Safecoin, или като допълващ носител / офлайн / миксер. DBC ще имат по-големи гаранции за поверителност от смесените монети като Monero или Zcash и биха могли да увеличат поверителността на Safecoin, ако бъдат използвани за тази цел. Засега това е само забавен мисловен експеримент и не е планирана никаква разработка. Анализ от общността и мненията ви са добре дошли!
Стареене на възел (Node Ageing)
План на проекта
Напреднахме с останалите части по повишаването/понижаването на Старейшините, като отстранихме някои проблеми. Също така постигнахме значителен напредък към затварянето на още един елемент, за да гарантираме, че Преместващият се възел може да провери дали новата секция е истинска.
Освен това допълнително почистихме още код. По-специално, сега избягваме излишната десериализация и сериализация на съобщения при всеки скок (при препредаващите възли) за Надеждната доставка на съобщения (RMD). Подобрихме и проверката на доверие в Сигурната доставка на съобщения (SMD). Премахването на доверения ключ от съобщението гарантира, че приемащият възел държи и се доверява на този ключ и също така избягва изпращането по мрежата на ненужен ключ.
Полезни линкове
Подробна информация може да намерите както винаги във форума на международната общност: SAFE Network Forum
Ако имате въпроси може да ги зададете или тук, или във Facebook групата на българската SAFE общност: SAFEnetwork България | Facebook
Ако искате да следите последните новини заповядайте във Facebook страницата на SAFE Network България: Safe Network България
) е проект целящ да позволи Solid приложения да работят върху SAFE Network, с възможно най-малко промени. Solid е проект на сър 
. Можете да прочетете малко повече за тази грешка и какви са последиците от нейното отстраняване в секцията за SAFE API в тези новини. Беше важно да отстраним този проблем тъй като колкото по-дълго време продължаваше, толкова повече акаунти бяха създавани неправилно чрез CLI и SAFE Network програмата.
