🥇IPFS bez bólu (ale to nie jest pewne)

Mimo że na Habrze pojawiło się już nie jedna artykuł na temat IPFS.

Od razu zaznaczę, że nie jestem ekspertem w tej dziedzinie, ale niejednokrotnie interesowałem się tą technologią, a próby bawienia się nią często przynosiły pewien ból. Dziś znów wziąłem się za eksperymenty i uzyskałem kilka rezultatów, którymi chciałbym się podzielić. Krótko mówiąc, opiszę proces instalacji IPFS oraz niektóre sztuczki (wszystko przeprowadzono na ubuntu, na innych platformach nie próbowałem).

Jeśli przegapiłeś, czym jest IPFS, to dość szczegółowo opisano to tutaj: habr.com/ru/post/314768

Instalacja

Aby zachować czystość eksperymentu, proponuję od razu zainstalować na jakimś zewnętrznym serwerze, ponieważ będziemy omawiać pewne pułapki związane z pracą w trybie lokalnym i zdalnym. Później, jeśli zechcesz, łatwo będzie to usunąć, zajmuje to niewiele czasu.

Instalujemy go

Oficjalna dokumentacja
Aktualną wersję znajdziesz na golang.org/dl

Uwagi: lepiej zainstalować IPFS na koncie użytkownika, którym najczęściej planujesz się posługiwać. Chodzi o to, że poniżej omówimy opcję montowania przez FUSE i są tam pewne szczegóły.

cd ~
curl -O https://dl.google.com/go/go1.12.9.linux-amd64.tar.gz
tar xvf go1.12.9.linux-amd64.tar.gz
sudo chown -R root:root ./go
sudo mv go /usr/local
rm go1.12.9.linux-amd64.tar.gz

Następnie musisz zaktualizować środowisko (więcej szczegółów tutaj: golang.org/doc/code.html#GOPATH).

echo 'export GOPATH=$HOME/work' >> ~/.bashrc
echo 'export PATH=$PATH:/usr/local/go/bin:$GOPATH/bin' >> ~/.bashrc
source ~/.bashrc

Sprawdzamy, czy go jest zainstalowane

go version

Instalujemy IPFS

Najbardziej spodobał mi się sposób instalacji przez ipfs-update.

Instalujemy go poleceniem

go get -v -u github.com/ipfs/ipfs-update

Po tym można wykonywać następujące polecenia:

ipfs-update versions — aby zobaczyć wszystkie dostępne wersje do pobrania.
ipfs-update version — aby zobaczyć aktualnie zainstalowaną wersję (ponieważ nie mamy jeszcze zainstalowanego IPFS, będzie none).
ipfs-update install latest — aby zainstalować najnowszą wersję IPFS. Zamiast latest można podać dowolną pożądaną wersję z listy dostępnych.

Instalujemy ipfs

ipfs-update install latest

Sprawdzamy

ipfs --version

Bezpośrednio z instalacją w ogólnych zarysach wszystko.

Uruchamianie IPFS

Inicjalizacja

Na początek musisz wykonać inicjalizację.

ipfs init

W odpowiedzi otrzymasz coś takiego:

 ipfs init
initializing IPFS node at /home/USERNAME/.ipfs
generating 2048-bit RSA keypair...done
peer identity: QmeCWX1DD7HnXXXXXXXXXXXXXXXXXXXXXXXXxxx
to get started, enter:
	ipfs cat /ipfs/QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv/readme

Możesz wykonać zaproponowane polecenie

ipfs cat /ipfs/QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv/readme

Wynik

Witaj w IPFS!

██╗██████╗ ███████╗███████╗
██║██╔══██╗██╔════╝██╔════╝
██║██████╔╝█████╗  ███████╗
██║██╔═══╝ ██╔══╝  ╚════██║
██║██║     ██║     ███████║
╚═╝╚═╝     ╚═╝     ╚══════╝

Jeśli to widzisz, oznacza to, że pomyślnie zainstalowałeś
IPFS i teraz łączysz się z merkledag ipfs!

 -------------------------------------------------------
| Uwaga:                                              |
|   To jest oprogramowanie w wersji alfa. Używaj na własną odpowiedzialność! |
|   Wiele funkcji brakuje lub nie jest dopracowanych. Mogą występować błędy.  |
|   Jeszcze nie jest bezpieczne. Przeczytaj notatki o bezpieczeństwie, aby dowiedzieć się więcej.   |
 -------------------------------------------------------

Zobacz inne pliki w tym katalogu:

  .\/about
  .\/help
  .\/quick-start     <-- przykłady użycia
  .\/readme          <-- ten plik
  .\/security-notes

Tu zaczyna się, moim zdaniem, interesująca część. Chłopaki już na etapie instalacji zaczynają używać swoich technologii. Proponowany hash QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv — nie został wygenerowany specjalnie dla was, ale wbudowany w wydanie. To znaczy, że przed wydaniem przygotowali tekst powitalny, wrzucili go do IPFS i dodali adres do instalatora. Uważam, że to naprawdę fajne. A ten plik (a dokładniej, cały folder) można teraz przeglądać nie tylko lokalnie, ale także w oficjalnej bramie. ipfs.io/ipfs/QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv. Można mieć pewność, że zawartość folderu się nie zmieniła, ponieważ gdyby się zmieniła, to hash również by się zmienił.

Przy okazji, w tym przypadku IPFS ma pewne podobieństwo do serwera kontroli wersji. Jeśli w oryginalnych plikach folderu dokonasz zmian i ponownie wrzucisz folder do IPFS, otrzyma on nowy adres. Stary folder nie zniknie i będzie dostępny pod swoim wcześniejszym adresem.

Bezpośrednio uruchomienie

ipfs daemon

Powinieneś otrzymać coś takiego w odpowiedzi:

ipfs daemon
Inicjalizacja daemona...
go-ipfs wersja: 0.4.22-
Wersja repo: 7
Wersja systemu: amd64/linux
Wersja Golanga: go1.12.7
Swarm nasłuchuje na /ip4/x.x.x.x/tcp/4001
Swarm nasłuchuje na /ip4/127.0.0.1/tcp/4001
Swarm nasłuchuje na /ip6/::1/tcp/4001
Swarm nasłuchuje na /p2p-circuit
Swarm ogłasza /ip4/127.0.0.1/tcp/4001
Swarm ogłasza /ip6/::1/tcp/4001
Serwer API nasłuchuje na /ip4/127.0.0.1/tcp/5001
WebUI: http://127.0.0.1:5001/webui
Serwer bramy (tylko do odczytu) nasłuchuje na /ip4/127.0.0.1/tcp/8080
Daemon jest gotowy

Otwieramy drzwi do Internetu

Zwróć uwagę na te dwa wiersze:

WebUI: http://127.0.0.1:5001/webui
Serwer bramy (tylko do odczytu) nasłuchuje na /ip4/127.0.0.1/tcp/8080

Jeśli zainstalowałeś IPFS lokalnie, będziesz miał dostęp do interfejsów IPFS przez lokalne adresy i wszystko będzie dla ciebie dostępne (Na przykład, localhost:5001/webui/). Domyślnie bramy są zamknięte dla internetu, gdy są instalowane na zewnętrznym serwerze. Istnieją dwie bramy:

Panel administracyjny webui (github) na porcie 5001.
Zewnętrzne API na porcie 8080 (tylko do odczytu).

Na razie można otworzyć oba porty (5001 i 8080) do eksperymentów, ale na serwerze produkcyjnym port 5001 oczywiście należy zamknąć zaporą. Jest jeszcze port 4001, który służy do tego, aby inne węzły mogły cię znaleźć. Należy go pozostawić otwartym dla zapytań zewnętrznych.

Otwórz do edycji ~/.ipfs/config i znajdź te linie:

"Addresses": {
  "Swarm": [
    "\/ip4\/0.0.0.0\/tcp\/4001",
    "\/ip6\/:\/tcp\/4001"
  ],
  "Announce": [],
  "NoAnnounce": [],
  "API": "\/ip4\/127.0.0.1\/tcp\/5001",
  "Gateway": "\/ip4\/127.0.0.1\/tcp\/8080"
}

Zmień 127.0.0.1 na adres IP twojego serwera i zapisz plik, a następnie zrestartuj ipfs (wstrzymaj działającą komendę Ctrl+C i uruchom ponownie).

Powinieneś uzyskać

...
WebUI: http://ip_twojego_serwera:5001/webui
Serwer bramy (tylko do odczytu) nasłuchuje na /ip4/ip_twojego_serwera/tcp/8080

Teraz zewnętrzne interfejsy powinny być dostępne.

Sprawdź

http://domena_lub_ip_serwera:8080/ipfs/QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv/readme

Powinien otworzyć się powyższy plik readme.

http://domena_lub_ip_serwera:5001/webui/

Powinien otworzyć się interfejs sieciowy.

Jeśli masz działający webui, to ustawienia IPFS można zmieniać bezpośrednio w nim, w tym przeglądać statystyki, ale poniżej omówię opcje konfiguracji bezpośrednio poprzez plik konfiguracyjny, co nie jest krytyczne. Po prostu lepiej zapamiętać, gdzie leży konfiguracja i co z nią zrobić, bo jeśli interfejs webowy przestanie działać, będzie już trudniej.

Konfigurujemy interfejs sieciowy do współpracy z własnym serwerem

Tu jest pierwszy zakręt, na który straciłem około trzech godzin.

Jeśli zainstalowałeś IPFS na zewnętrznym serwerze, ale nie instalowałeś ani nie uruchamiałeś IPFS lokalnie, to przy przejściu do /webui w interfejsie sieciowym powinieneś widzieć błąd połączenia:

Chodzi o to, że webui, moim zdaniem, działa dość niejednoznacznie. Najpierw próbuje połączyć się z API tego serwera, na którym otwarty jest interfejs (opierając się na adresie w przeglądarce). Jeśli się to nie powiedzie, próbuje połączyć się z lokalną bramą. A jeśli masz uruchomione IPFS lokalnie, to webui będzie działać normalnie, ale będziesz pracować z lokalnym IPFS, a nie z zewnętrznym, pomimo otwarcia webui na zewnętrznym serwerze. Potem przesyłasz pliki, ale z jakiegoś powodu nie widzisz ich po prostu na zewnętrznym serwerze...

A jeśli lokalnie nie jest uruchomiona, otrzymujemy błąd połączenia. W naszym przypadku błąd prawdopodobnie wynika z CORS, o czym informuje także webui, proponując dodanie konfiguracji.

ipfs config --json API.HTTPHeaders.Access-Control-Allow-Origin '["http://ip_twojego_serwera:5001", "http://127.0.0.1:5001", "https://webui.ipfs.io"]'
ipfs config --json API.HTTPHeaders.Access-Control-Allow-Methods '["PUT", "GET", "POST"]'

Ja u siebie po prostu ustawiłem wildcard.

ipfs config --json API.HTTPHeaders.Access-Control-Allow-Origin '["*"]'

Dodane nagłówki można znaleźć wszystkie w tym samym ~/.ipfs/config. W moim przypadku to:

  "API": {
    "HTTPHeaders": {
      "Access-Control-Allow-Origin": [
        "*"
      ]
    }
  },

Restartujemy ipfs i widzimy, że webui pomyślnie się połączył (w każdym razie powinien, jeśli otworzyłeś bramy dla zapytań zewnętrznych, jak opisano powyżej).

Teraz można bezpośrednio przez interfejs webowy przesyłać foldery i pliki, a także tworzyć własne foldery.

Montaż systemu plików FUSE

To dość interesująca funkcja.

Pliki (jak i foldery) możemy dodawać nie tylko przez interfejs webowy, ale także bezpośrednio w terminalu, na przykład:

ipfs add test -r
added QmfYuz2gegRZNkDUDVLNa5DXzKmxxxxxxxxxx test/test.txt
added QmbnzgRVAP4fL814h5mQttyqk1aURxxxxxxxxxxxx test

Ostatni hash to hash folderu głównego.

Na podstawie tego hasha możemy otworzyć folder na dowolnym węźle ipfs (który będzie w stanie znaleźć nasz węzeł i uzyskać zawartość), możemy w interfejsie webowym na porcie 5001 lub 8080, a także lokalnie przez ipfs.

ipfs ls QmbnzgRVAP4fL814h5mQttyqk1aUxxxxxxxxxxxxx
QmfYuz2gegRZNkDUDVLNa5DXzKmKVxxxxxxxxxxxxxx 10 test.txt

Ale można również otwierać go jak zwykły folder.

Utworzymy w katalogu głównym dwa foldery i przyznamy do nich prawa naszemu użytkownikowi.

sudo mkdir /ipfs /ipns
sudo chown USERNAME /ipfs /ipns

a ponownie uruchomimy ipfs z flagą —mount

ipfs daemon --mount

Można tworzyć foldery również w innych miejscach i określić ścieżkę do nich przez parametry ipfs daemon —mount —mount-ipfs /ipfs_path —mount-ipns /ipns_path

Teraz odczyt z tego folderu jest nieco nietypowy.

ls -la /ipfs
ls: reading directory '/ipfs': Operation not permitted
total 0

Oznacza to, że nie ma bezpośredniego dostępu do korzenia tego folderu. Jednak można uzyskać zawartość, znając hash.

ls -la /ipfs/QmbnzgRVAP4fL814h5mQttyqxxxxxxxxxxxxxxxxx
total 0
-r--r--r-- 1 root root 10 Aug 31 07:03 test.txt

cat /ipfs/QmbnzgRVAP4fL814h5mQttyqxxxxxxxxxxxxxxxxx/test.txt 
test
test

Przy tym wewnątrz folderu autouzupełnianie działa nawet przy wskazywaniu ścieżki.

Jak wspomniałem wcześniej, przy takim montażu są pewne niuanse: domyślnie zamontowane foldery FUSE są dostępne tylko dla bieżącego użytkownika (nawet root nie będzie mógł czytać z takiego folderu, nie wspominając o innych użytkownikach w systemie). Jeśli chcesz, aby te foldery były dostępne dla innych użytkowników, musisz w konfiguracji zmienić „FuseAllowOther”: false na „FuseAllowOther”: true. Ale to jeszcze nie wszystko. Jeśli uruchamiasz IPFS jako root, to wszystko jest w porządku. A jeśli jako zwykły użytkownik (nawet z sudo), to otrzymasz błąd.

błąd pomocnika montowania: fusermount: opcja allow_other jest dozwolona tylko wtedy, gdy 'user_allow_other' jest ustawione w /etc/fuse.conf

W takim przypadku należy dostosować /etc/fuse.conf, odkomentowując linię #user_allow_other.

Po tym restartujemy ipfs.

Znane problemy z FUSE

Nie raz zauważono problem, że po restarcie ipfs z montowaniem (a może i w innych przypadkach), punkty montowania /ipfs i /ipns stają się niedostępne. Nie ma do nich dostępu, a ls -la /ipfs pokazuje ???? w liście uprawnień.

Znalazłem takie rozwiązanie:

fusermount -z -u /ipfs
fusermount -z -u /ipns

Po czym restartujemy ipfs.

Dodajemy usługę

Oczywiście uruchomienie w terminalu nadaje się tylko do początkowych testów. W trybie produkcyjnym demon powinien uruchamiać się automatycznie przy uruchamianiu systemu.

Z uprawnieniami sudo tworzymy plik /etc/systemd/system/ipfs.service i zapisujemy w nim:

[Unit]
Description=Demon IPFS
After=syslog.target network.target remote-fs.target nss-lookup.target

[Service]
Type=simple
ExecStart=/home/USERNAME/work/bin/ipfs daemon --mount
User=USERNAME
Restart=always

[Install]
WantedBy=multi-user.target

USERNAME należy oczywiście zastąpić swoim użytkownikiem (i być może pełna ścieżka do programu ipfs będzie u Ciebie inna (należy podać dokładnie pełną ścieżkę)).

Aktywujemy usługę.

sudo systemctl enable ipfs.service

Uruchamiamy usługę.

sudo service ipfs start

Sprawdzamy status usługi.

sudo service ipfs status

Dla czystości eksperymentu można później zrestartować serwer, aby sprawdzić, czy ipfs uruchamia się automatycznie.

Dodajemy znane nam węzły.

Rozważmy sytuację, gdy nasze węzły IPFS są zainstalowane zarówno na zewnętrznym serwerze, jak i lokalnie. Na zewnętrznym serwerze dodajemy jakiś plik i próbujemy go uzyskać lokalnie przez CID. Co się wydarzy? Oczywiście lokalny serwer prawdopodobnie nic nie wie o naszym zewnętrznym serwerze i będzie po prostu próbować znaleźć plik po CID, «pytając» wszystkich dostępnych mu węzłów IPFS (z którymi udało mu się «zapoznać»). Te z kolei będą pytać inne. I tak, aż plik zostanie znaleziony. Właściwie to samo dzieje się, gdy próbujemy uzyskać plik przez oficjalną bramę. ipfs.io. Jeśli mamy szczęście, plik zostanie znaleziony w kilka sekund. A jeśli nie, to nie zostanie znaleziony nawet po kilku minutach, co znacząco obniża komfort pracy. Ale my wiemy, gdzie ten plik najpierw się pojawi. Dlaczego więc od razu nie powiedzieć naszemu lokalnemu serwerowi „Szukaj najpierw tam”? Z tego, co widać, można to zrobić.

1. Wchodzimy na zdalny serwer i w pliku konfiguracyjnym ~/.ipfs/config szukamy

"Identity": {
    "PeerID": "QmeCWX1DD7HnPSuMHZSh6tFuxxxxxxxxxxxxxxxx",

2. Wykonujemy sudo service ipfs status i szukamy w nim zapisów Swarm, na przykład:

Swarm announcing /ip4/ip_ Twojego serwera/tcp/4001

3. Tworzymy z tego wspólny adres w postaci „/ip4/ip_ Twojego serwera/tcp/4001/ipfs/$PeerID”.

4. Dla pewności przez nasz lokalny webui spróbujemy dodać ten adres do węzłów.

5. Jeśli wszystko OK, otwieramy lokalny plik konfiguracyjny ~/.ipfs/config, znajdujemy w nim „Bootstrap”: […
i dodajemy jako pierwszy do tablicy uzyskany adres.

Restartujemy IPFS.

Teraz dodajemy plik na zewnętrzny serwer i próbujemy go zażądać lokalnie. Powinien szybko się pojawić.

Ale ta funkcjonalność jest na razie niestabilna. Z tego, co rozumiem, nawet jeśli podajemy adres węzła w Bootstrap, w trakcie pracy ipfs zmienia listę aktywnych połączeń z węzłami. W każdym razie prowadzone są dyskusje na ten temat i sugestie dotyczące możliwości wskazywania stałych węzłów. tutaj I wygląda na to, że zakłada się dodanie jakiejś funkcjonalności w ipfs@5.0+

Obecny wykaz węzłów można zobaczyć zarówno w webui, jak i w terminalu.

ipfs swarm peers

I tam i tam można ręcznie dodać swój węzeł.

ipfs swarm connect "/ip4/ip_ Twojego serwera/tcp/4001/ipfs/$PeerID"

Dopóki nie poprawią tej funkcjonalności, można napisać narzędzie, które sprawdzi połączenie z potrzebnym węzłem i jeśli go nie będzie, doda to połączenie.

Rozważania

Wśród tych, którzy już znają IPFS, są zarówno argumenty za, jak i przeciw IPFS. W zasadzie, przedwczoraj omawianie i skłoniło mnie to, by jeszcze raz przyjrzeć się IPFS. A odnosząc się do wspomnianej dyskusji: nie mogę powiedzieć, że jestem szczególnie przeciwny jakimkolwiek przedstawionym argumentom (nie zgadzam się tylko z tym, że półtora programisty używa IPFS). W sumie, zarówno jedna, jak i druga strona mają swoje racje (szczególnie komentarz dotyczący czeków skłania do refleksji). Ale jeśli odrzucimy ocenę moralną i prawną, to kto da jakąś techniczną ocenę tej technologii? Osobiście mam jakieś wewnętrzne odczucie, że „to jest zdecydowanie konieczne, ma to określone perspektywy”. Ale dlaczego tak jest, nie mam jasnej formuły. Typowo, jeśli spojrzeć na już istniejące centralizowane środki, to w wielu parametrach są znacznie przed nami (stabilność działania, szybkość działania, zarządzalność itd.). Niemniej jednak, mam jedną myśl, która wydaje się sensowna i która raczej nie może być zrealizowana bez takich zdecentralizowanych systemów. Oczywiście, mocno się wybieram, ale formułowałbym to tak: zasady rozpowszechniania informacji w Internecie trzeba zmienić.

Wyjaśnię. Jeśli tak się nad tym zastanowić, to teraz mamy informację rozpowszechnianą na zasadzie „Mam nadzieję, że ten, komu ją przekazałem, ją ochroni i nie zostanie utracona lub uzyskana przez kogoś, komu nie była przeznaczona”. Łatwo jest rozważyć różne usługi pocztowe, chmury i tym podobne. I co mamy na końcu? Na Habra Hub Bezpieczeństwo informacyjne znajduje się na pierwszej pozycji i praktycznie codziennie otrzymujemy wiadomości o kolejnej globalnej wycieczce. W zasadzie wszystko, co najciekawsze, jest wymienione w cudownej artykule Lato prawie się skończyło. Prawie nie pozostały żadne przecieki danych. To znaczy, że główni giganci internetowi stają się coraz więksi, gromadzą coraz więcej informacji, a podobne wycieki to swoiste atomowe wybuchy informacyjne. Nigdy wcześniej czegoś takiego nie było, a oto znowu to się zdarza. Przy tym, chociaż wielu rozumie, że istnieją ryzyka, będą nadal ufać swoim danym firmom zewnętrznym. Po pierwsze, nie ma szczególnych alternatyw, a po drugie, one obiecują, że załatały wszystkie dziury i więcej to się nie powtórzy.

Jaki wariant wydaje mi się właściwy? Moim zdaniem, dane powinny być pierwotnie rozpowszechniane w sposób otwarty. Jednak otwartość w tym przypadku nie oznacza, że wszystko musi być łatwe do przeczytania. Mówię o otwartości przechowywania i rozpowszechniania, ale nie o całkowitej otwartości w czytaniu. Uważam, że informacje powinny być rozpowszechniane z otwartymi kluczami. Przecież zasada otwartych/zamkniętych kluczy jest już stara, prawie tak jak Internet. Jeśli informacja nie jest poufna i jest przeznaczona dla szerokiego kręgu, powinna być udostępniana od razu z otwartym kluczem (ale i tak w formie zaszyfrowanej, tylko każdy może ją odszyfrować posiadającym kluczem). A jeśli nie, to jest udostępniana bez otwartego klucza, a sam klucz jest przekazywany temu, kto powinien mieć dostęp do tych informacji. Przy tym, ten, kto miałby to przeczytać, powinien mieć tylko klucz, a gdzie znaleźć te informacje, nie powinno go zbytnio interesować — po prostu ściąga je z sieci (to jest nowa zasada rozpowszechniania według treści, a nie według adresu).

W ten sposób, aby przeprowadzić masowy atak, przestępcy muszą zdobyć ogromną liczbę zamkniętych kluczy, co raczej nie będzie możliwe do zrobienia w jednym miejscu. Ta zadanie, moim zdaniem, jest bardziej skomplikowane niż złamanie jakiejś określonej usługi.

I tutaj zamyka się kolejny problem: potwierdzenie autorstwa. Obecnie w Internecie można znaleźć mnóstwo cytatów napisanych przez naszych znajomych. Ale gdzie jest gwarancja, że to oni je napisali? Gdyby każda taka notka była opatrzona podpisem cyfrowym, byłoby to znacznie prostsze. I nieważne, gdzie te informacje się znajdują, najważniejszy jest podpis, który z góry jest trudny do podrobienia.

I oto co jest ciekawe: IPFS już wyposażone jest w środki szyfrowania (przecież opiera się na technologii blockchain). W konfiguracji od razu podany jest prywatny klucz.

  "Identity": {
    "PeerID": "QmeCWX1DD7HnPSuMHZSh6tFuMxxxxxxxxxxxxxx",
    "PrivKey": "CAASqAkwggSkAgEAAoIBAQClZedVmj8JkPvT92sGrNIQmofVF3ne8xSWZIGqkm+t9IHNN+\/NDI51jA0MRzpBviM3o\/c\/Nuz30wo95vWToNyWzJlyAISXnUHxnVhvpeJAbaeggQRcFxO9ujO9DH61aqgN1m+JoEplHjtc4KS5
pUEDqamve+xAJO8BWt\/LgeRKA70JN4hlsRSghRqNFFwjeuBkT1kB6tZsG3YmvAXJ0o2uye+y+7LMS7jKpwJNJBiFAa\/Kuyu3W6PrdOe7SqrXfjOLHQ0uX1oYfcqFIKQsBNj\/Fb+GJMiciJUZaAjgHoaZrrf2b\/Eii3z0i+QIVG7OypXT3Z9JUS60
KKLfjtJ0nVLjAgMBAAECggEAZqSR5sbdffNSxN2TtsXDa3hq+WwjPp\/908M10QQleH\/3mcKv98FmGz65zjfZyHjV5C7GPp24e6elgHr3RhGbM55vT5dQscJu7SGng0of2bnzQCEw8nGD18dZWmYJsE4rUsMT3wXxhUU4s8\/Zijgq27oLyxKNr9T7
2gxqPCI06VTfMiCL1wBBUP1wHdFmD\/YLJwOjV\/sVzbsl9HxqzgzlDtfMn\/bJodcURFI1sf1e6WO+MyTc3.................

Nie jestem ekspertem w dziedzinie bezpieczeństwa i nie mogę dokładnie wiedzieć, jak to prawidłowo wykorzystać, ale wydaje mi się, że na poziomie wymiany między węzłami IPFS te klucze są używane. A dodatkowo js-ipfs i takie projekty-przykłady jak orbit-db, na której działa orbit.chat. Teoretycznie każde urządzenie (mobilne i nie tylko) może być łatwo wyposażone w swoje maszyny do szyfrowania i deszyfrowania. W takim przypadku każdy będzie musiał zadbać o przechowywanie swoich kluczy prywatnych, a każdy sam będzie odpowiedzialny za swoje bezpieczeństwo, zamiast być zakładnikiem kolejnego ludzkiego czynnika w jakimś super popularnym gigancie internetowym.

Tylko zarejestrowani użytkownicy mogą brać udział w ankiecie. Zaloguj się, proszę.