SAFE Network новини – 30.1.2020

Новини
1

SAFE Network новини – 30.1.2020

2129a159950dc166b481c1114c265b9da814751f
2129a159950dc166b481c1114c265b9da814751f830×430 125 KB

Накратко

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

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

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

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

SAFE API

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

Публикувахме нови Safe-cli v0.8.1 и safe-authd v0.0.4 версии, които включват всички корекции и функции, над които работихме през изминалата седмица. Както и преди, можете да актуализирате вашия CLI с командата $ safe update и ако вече сте актуализирали до (или сте инсталирали) authd v0.0.3 миналата седмица, можете да го актуализирате до v0.0.4 с $ safe auth update или ако го нямате да го инсталирате с $ safe auth install . Във всеки случай пълните инструкции може да намерите в Ръководството за потребителя за CLI.

Тази нова версия на CLI добавя две нови команди, както коментирахме в новините от миналата седмица. Вече е достъпна командата xorurl decode , която позволява извличане на цялата информация, която е кодирана в XOR URL:

$ safe xorurl decode safe://hnyynyzonskbrgd57kt8c1pnb14qg8oh8wjo7xiku4mh4tc67wjax3c54sbnc
Information decoded from XOR-URL: safe://hnyynyzonskbrgd57kt8c1pnb14qg8oh8wjo7xiku4mh4tc67wjax3c54sbnc
Xorname: e02b282430f7d544ec93441969c63c387a261d7d553d2f9a8b3dda270fcb37ab
Type tag: 1100
Native data type: PublishedSeqAppendOnlyData
Path: none
Sub names: []
Content version: latest

Както беше предложено от общността, тази нова версия също добавя командата files ls , която извежда съдържанието на всеки FilesContainer по аналогичен начин с традиционната за Linux команда ls, също така ни позволява да посочим подпапки в пътя на safe:// URL адреса за да се преглежда йерархията на целевия FilesContainer, например:

$ safe files ls safe://hnyynyi6tgumo67yoauewe3ee3ojh37sbyr7rnh3nd6kkqhbo9decpjk64bnc
Files of FilesContainer (version 4) at "safe://hnyynyi6tgumo67yoauewe3ee3ojh37sbyr7rnh3nd6kkqhbo9decpjk64bnc":
Total: 6
SIZE  CREATED               MODIFIED              NAME
11    2020-01-28T20:26:05Z  2020-01-28T20:29:04Z  another.md
38    2020-01-28T20:35:43Z  2020-01-28T20:35:43Z  files-added/
30    2020-01-28T20:31:01Z  2020-01-28T20:31:01Z  new-files/
10    2020-01-28T20:29:04Z  2020-01-28T20:29:04Z  new.md
23    2020-01-28T20:26:05Z  2020-01-28T20:26:05Z  subfolder/

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

Незначителна промяна, но много полезна, когато става въпрос за отстраняване на проблеми, е добавянето на authd двоичната версия към отчета за състоянието на authd. Вече можете да проверите коя версия на authd работи и отговаря на CLI заявки, като проверите версията със следната команда $ safe auth status :

$ safe auth status
Sending request to authd to obtain an status report...
+------------------------------------------+-------+
| SAFE Authenticator status                |       |
+------------------------------------------+-------+
| Authenticator daemon version             | 0.0.4 |
+------------------------------------------+-------+
| Logged in to a SAFE account?             | Yes   |
+------------------------------------------+-------+
| Number of pending authorisation requests | 0     |
+------------------------------------------+-------+
| Number of notifications subscribers      | 0     |
+------------------------------------------+-------+

Обърнете внимание, че след като сте актуализирали до новия safe-authd v0.0.4 (с команда safe auth update ), ще трябва да рестартирате authd, за да стартирате новата версия (с команда safe auth restart ).

Беше отстранена и грешка, която засягаше акаунти, създадени с safe-authd. Поради начина, по който се анализират JSON-RPC съобщенията, идентификационните данни на акаунта се предават в мрежата с кавички ( "..." ). Това означава, че с тази нова версия на authd, ако имате стар акаунт няма да бъде намерен и няма да може да влезете. Следователно за тези, които активно използват CLI и authd, след като сте актуализирали до най-новата версия, ще трябва или да създадете нови акаунти, или като решение, ако наистина искате да използвате по-рано акаунт, просто не забравяйте да въведете идентификационните данни с кавички ( "..." ) и това ще ви позволи да влезете със стария си акаунт. Например, ако ключа ви е бил mypassphrase и паролата към него mypassword , тогава все още може да получите достъп до акаунта си след обновяването до новата версия, като въведете данни си като "mypassphrase" и "mypassword" .

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

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

Тази седмица @yogesh обедини усилията си с @joshuef за внедряване на маркерите и заедно започнаха работа по обратната връзка от първоначалното прилагане на POC, както и по-задълбочено планиране на следващите стъпки за работата по маркерите. Това включва нов, отделен RFC (идващ скоро) само за маркерите, за да се даде яснота там.

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

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

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

Изясняване на Private | Public на обхвата от последици за Map e добавено по заявка на @tfa. Освен това са добавени подробности за възможните разширения към опциите за изтриване на PrivateMap .

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

Уточняване на йерархията на данните

RFC

Дискусиите в RFC продължиха през седмицата с няколко предложения от общността. Сред тях са използването на допълнителен криптиращ слой от възли като начин за добавяне на прикриване на трезорите (@jlpell) и предложение за обща поддръжка на RDF чрез въвеждане на Triplet тип данни, т.е. предоставяне на общ triplestore (@JoeSmithJr).

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

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

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

Освен че използваме същата кодова база както при CLI и намаляваме някои проверки на Windows в програмата, също така оптимизираме администраторските подкани в Windows (изчаква се подканата да бъде приета преди да се опита нещо друго). Така че сега трябва да получите една подкана при инсталация и една при стартиране (за разлика от евентуалното получаване на множество от подкани). Което е хубаво.

И накрая, добавихме още една удобна функция: SAFE Network програмата ще се опита да спре процеса за удостоверяване само ако не е било още стартирано. Така че това не трябва да пречи на authd процесите, започнати например от CLI-то.

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

Тази седмица пуснахме няколко алфа версии на браузъра. Най-вече по поддръжката, но и за отстраняването на няколко проблема, с които @latch се сблъска, докато работеше по уеб приложение, базирано на WASM. В macOS възникна проблем, при който отварянето на devtools може да срине целия браузър. Един досаден за отстраняване проблем тъй като devmode го няма този проблем (който сам по себе си не се проявява равномерно). В крайна сметка се оказа просто случай на нужда от URI декодиране на някои заявки от devtools, които (грешно) се третираха като safe заявки.

Тези проблеми повдигат и някои добри въпроси относно API-то ни и докъде трябва да включваме отговори тип HTTP (или да не ги включваме). Повече за това във форума за програмисти.

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

Прекарахме тази седмица в тестване на Удостоверителя и мобилните браузъри за Android и iOS и в процеса направихме много подобрения и корекции на грешки.

Тестването в приложението за удостоверяване доведе до откриването на интересен бъг в safe-authd. В мобилния Удостоверител забелязахме, че когато създадем акаунт на трезор, например споделения трезор, не можем да влезем през CLI или през SAFE Network програмата, използвайки новите данни за акаунта. Същия проблем съществуваше и в обратна посока, така че нито един акаунт, създаден чрез CLI или SAFE Network App не работеше работи с мобилния Удостоверител. След известно разследване на грешките от страна на @ravinder, той успя да ограничи възможните причини за грешката, след което работи с @bochaco, за да определи точната причина за грешката в safe-authd :mag:. Можете да прочетете малко повече за тази грешка и какви са последиците от нейното отстраняване в секцията за SAFE API в тези новини. Беше важно да отстраним този проблем тъй като колкото по-дълго време продължаваше, толкова повече акаунти бяха създавани неправилно чрез CLI и SAFE Network програмата.

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

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

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

Safecoin / Фермерство

RFC

Тази седмица разделихме изследванията ни в две области: CRDT и DBC.

CRDT предлага евентуална съгласуваност между реплики (Старейшините в нашия случай) без загубата на производителност, която идва с изискването всички компютри да виждат данните в един и същ ред, напр. чрез консенсуса на PARSEC. Въпреки това повечето CRDT не ни дават възможност да наложим правило като баланс> = 0. За тази цел започнахме да разглеждаме Bounded Counter, малко известен тип, който дава възможност за налагане на такива правила, с цената на това всяка репликата да сериализира вътрешно операциите, напр. като поддържа хеш-верига от актуализации. Изследванията ни продължават, но изглежда, че подходът е обещаващ.

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

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

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

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

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

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

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

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

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

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