🥇IPFS valutult (aga see ei pruugi nii olla)

Kuigi Habr's on juba olnud mitmeid artikleid IPFS-i kohta.

Tahaksin kohe märkida, et ma ei ole selle ala ekspert, kuid olen korduvalt näidanud huvi selle tehnoloogia vastu. Siiski, katsetamine on tihti põhjustanud teatud ebamugavusi. Täna olen jälle katsetamisega alustanud ja saanud mõned tulemused, mida sooviksin jagada. Lühidalt öeldes, kirjeldan IPFS-i installimise protsessi ja teatud nippe (kõik toimus Ubuntu peal, teistel platvormidel ei ole proovinud).

Kui te jäite ilma, mis on IPFS, on sellest siin üsna detailselt kirjutatud: habr.com/ru/post/314768

Installeerimine

Eksperimendi puhtuse huvides soovitan kohe installida mõnele välisele serverile, kuna käsitleme teatud allveelaevade tööprobleeme kohalikus ja kaugühenduse režiimis. Hiljem on soovimisel lihtne eemaldada, seal pole palju.

Installime go

Ametlik dokumentatsioon
Aktuaalset versiooni vaadake golang.org/dl

Märkus: on parem installida IPFS-i selle kasutajanime alt, millega kavatsetakse kõige sagedamini töötada. Asi on selles, et allpool vaatame varianti, kus on ühendatud läbi FUSE ja seal on nüansse.

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

Seejärel tuleb keskkond uuendada (rohkem siin: 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

Kontrollime, kas go on paigaldatud

go version

Paigaldame IPFS

Mulle meeldis enim paigaldamisviis, mis kasutab ipfs-update.

Paigaldame selle käsuga

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

Pärast seda saab teha järgmisi käske:

ipfs-update versions — et näha kõiki saadaval olevaid versioone alla laadimiseks.
ipfs-update version — et näha praegu installitud versiooni (kuna meil ei ole IPFS-i installitud, kuvatakse none).
ipfs-update install latest — installida IPFS-i uusim versioon. Selle asemel latest võib määrata igasuguse soovitud versiooni saadavalolevatest.

Paigaldame ipfs

ipfs-update install latest

Kontrollime

ipfs --version

Paigaldamise osas on kõik üldjoontes hästi.

IPFS-i käivitamine

Initsialiseerimine

Esiteks tuleb teha initsialiseerimine.

ipfs init

Vastuseks saate midagi sellist:

 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

Saate käivitada soovitatud käsu

ipfs cat /ipfs/QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv/readme

Tulemus

Tere ja tervitame IPFS-is!

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

Kui sa neid ridu näed, on IPFS korrektselt installitud
ja sa suheld IPFS merkledag'iga!

 -------------------------------------------------------
| Hoiatamine:                                          |
|   See on alfa tarkvara. Kasuta omal äranägemisel!    |
|   Palju on puudu või ebapiisava kvaliteediga. On vigu.|
|   Veel mitte turvaline. Loe turvanoteid rohkemateks.  |
 -------------------------------------------------------

Vaata mõningaid teisi faile selles kaustas:

  ./about
  ./help
  ./quick-start     <-- kasutusnäited
  ./readme          <-- see fail
  ./security-notes

Siin, minu arvates, hakkab huvitav osa pihta. Poisid hakkavad oma tehnoloogiat kasutama juba installimise faasis. Pakutud hash QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv — ei ole teie jaoks spetsiaalselt genereeritud, vaid on sisse ehitatud väljaandes. See tähendab, et enne väljaannet valmistasid nad tervitusteksti, laadisid selle IPFS-i ja lisasid aadressi installijat. Minu arvates on see väga äge. Ja seda faili (täpsemalt, kogu kausta) saab nüüd vaadata mitte ainult kohalikult, vaid ka ametliku värava kaudu. ipfs.io/ipfs/QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv. Samas võib olla kindel, et kausta sisu ei ole muutunud, sest kui see oleks muutunud, oleks ka hash muutunud.

Üldiselt on IPFS sel juhul sarnane versioonihalduse serveriga. Kui kausta algfailidesse teha muudatusi ja kaust uuesti IPFS-i laadida, saab ta uue aadressi. Vanem kaust ei kao lihtsalt ära ja jääb endiselt kätte saadavaks oma endisel aadressil.

Otsene käivitamine

ipfs daemon

Peate vastuseks saama midagi sellist:

ipfs daemon
Daemon käivitamine...
go-ipfs versioon: 0.4.22-
Repo versioon: 7
Süsteemi versioon: amd64/linux
Golang versioon: go1.12.7
Swarm kuulab aadressil /ip4/x.x.x.x/tcp/4001
Swarm kuulab aadressil /ip4/127.0.0.1/tcp/4001
Swarm kuulab aadressil /ip6/::1/tcp/4001
Swarm kuulutab /p2p-circuit
Swarm kuulutab aadressil /ip4/127.0.0.1/tcp/4001
Swarm kuulutab aadressil /ip6/::1/tcp/4001
API server kuulab aadressil /ip4/127.0.0.1/tcp/5001
WebUI: http://127.0.0.1:5001/webui
Gateway (ainult lugemiseks) server kuulab aadressil /ip4/127.0.0.1/tcp/8080
Daemon on valmis

Avame uksed Internetile

Pöörake tähelepanu nendele kahele reale:

WebUI: http://127.0.0.1:5001/webui
Gateway (ainult lugemiseks) server kuulab aadressil /ip4/127.0.0.1/tcp/8080

Kui olete IPFS-i enda seadmesse installinud, pääsete IPFS-liidestele ligi kohalike aadresside kaudu ja kõik on teile kätte saadav (näiteks, localhost:5001/webui/). Kuid välisse serverisse installimisel on vaikimisi väravad interneti jaoks suletud. Väravaid on kaks:

WebUI adminpaneel (github) sadamal 5001.
Väline API sadamal 8080 (ainult lugemiseks).

Eksperimentide jaoks on mõlemad sadamad (5001 ja 8080) avatud, kuid tootmiserveris tuleks sadam 5001 kindlasti tulemüüriga sulgeda. Veel on sadam 4001, mis on vajalik, et teised peer’id saaksid teid leida. See tuleks jätta avatud välistele päringutele.

Avame redigeerimiseks ~/.ipfs/config ja leidke sealt need read:

"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"
}

Muuda 127.0.0.1 oma serveri IP-ks ja salvesta fail, seejärel taaskäivita ipfs (jooksvat käsku peatage Ctrl+C ja käivitage uuesti).

Peaksite saama

...
WebUI: http://serveri_ip:5001/webui
Värav (ainult lugemiseks) server kuulab /ip4/serveri_ip/tcp/8080

Nüüd peavad välised liidestused olema kättesaadavad.

Kontrollige

http://domeen_voi_serveri_ip:8080/ipfs/QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv/readme

Peaksite nägema ülaltoodud readme-faili.

http://domeen_voi_serveri_ip:5001/webui/

Webi liides peaks avanema.

Kui teie webui töötab, saate IPFS-i seadeid seal otse muuta ja statistikat vaadata. Allpool käsitlen seadistamise võimalusi, mida saab otse konfiguratsioonifaili kaudu teha, mis ei ole kriitiline. Lihtsalt on parem meeles pidada, kus konfiguratsioonifail asub ja mida sellega teha, sest kui veebiliides ei tööta, siis on probleemide lahendamine keerulisem.

Seadistame veebiliidese oma serveriga tööks

Siin on esimene takistus, millele kulus umbes kolm tundi.

Kui olete IPFS-i installinud välissevrisse, kuid ei ole IPFS-i kohapeal installinud või käivitanud, siis peaksite veebiliidese /webui avamisel nägema ühendusviga:

As I see it, the webui functions rather ambiguously. First, it attempts to connect to the API of the server where the interface is open (based on the browser's address, of course). If that fails, it tries to connect to the local gateway. If you have IPFS running locally, the webui will work fine, but you'll be interacting with your local IPFS, not the external one, even if you've opened the webui on an external server. Then you upload files, but for some reason, you don't see them directly on the external server...

And if it’s not running locally either, then we get a connection error. In our case, the error is likely due to CORS, which is also indicated by the webui, suggesting to add a configuration.

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

I just set a wildcard on my end.

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

The added headers can all be found in the same ~/.ipfs/config. In my case, it is

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

Taaskäivitasime ipfs-i ja näeme, et webui on edukalt ühendatud (iga juhul peaks olema, kui olete välised päringud lubanud, nagu eespool kirjeldatud).

Nüüd on võimalik otse veebi kaudu üles laadida kaustu ja faile ning luua oma kaustu.

FUSE failisüsteemi mountimine

See on üsna huvitav funktsioon.

Faile (nagu ka kaustu) saame lisada mitte ainult veebiliidese kaudu, vaid ka otse terminalis, näiteks

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

Viimane hash on juurkausta hash.

Selle hash'i abil saame avada kausta igas ipfs-nodes (mis suudab leida meie nodi ja saada sisu), saame veebiliidese kaudu portidel 5001 või 8080, või saame kohalikult ipfs-i kaudu.

ipfs ls QmbnzgRVAP4fL814h5mQttyqk1aUxxxxxxxxxxxxx
QmfYuz2gegRZNkDUDVLNa5DXzKmKVxxxxxxxxxxxxxx 10 test.txt

Aga seda saab avada ka nagu tavalist kausta.

Loome juures kaks kausta ja anname neile õigused meie kasutajale.

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

ja taaskäivitame ipfs-i lipuga —mount

ipfs daemon --mount

Saame luua kaustu ka teistes kohtades ja määrata tee neile parameetrite kaudu ipfs daemon —mount —mount-ipfs /ipfs_path —mount-ipns /ipns_path

Nüüd on selle kausta lugemine natuke ebatavaline.

ls -la /ipfs
ls: lugemine kataloogist '/ipfs': Tegevus pole lubatud
total 0

See tähendab, et sellele kaustale otse juurdepääsu ei ole. Kuid sisu on võimalik hankida, teades hash'i.

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

Selle juures töötab ka katalooge jaotuses automaatne täiendamine, kui on antud tee.

Nagu ma juba varem mainisin, on sellise montaaži puhul nüansse: vaikimisi on monteeritud FUSE-kaustad ainult jooksvale kasutajale nähtavad (isegi root ei saa sellisest kaustast lugeda, rääkimata süsteemi teistest kasutajatest). Kui soovite, et need kaustad oleksid teistele kasutajatele ligipääsetavad, tuleb konfiguratsioonis muuta 'FuseAllowOther': false 'ks 'FuseAllowOther': true. Kuid sellega ei ole kõik veel lõppenud. Kui käitate IPFS-i root'i nimel, siis on kõik korras. Kui aga tavalise kasutaja nimel (isegi sudo), siis saate vea.

mount helper error: fusermount: valik allow_other on lubatud ainult siis, kui 'user_allow_other' on seadistatud /etc/fuse.conf

Sel juhul tuleb parandada /etc/fuse.conf ja eemaldada kommentaar read #user_allow_other.

Pärast seda taaskäivitage ipfs.

Tuntud probleemid FUSE-iga

On kõige varem märgatud probleem, et pärast ipfs-i taaskäivitamist mountimisega (või võib-olla ka muudel juhtudel) muutuvad mountimispunktid /ipfs ja /ipns kättesaamatuks. Juhtimist neile pole üldse ja ls -la /ipfs näitab ???? õiguste loendis.

Leidsin sellise lahenduse:

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

Pärast seda taaskäivitage ipfs.

Lisame teenuse

Muidugi sobib terminalis käivitamine ainult esialgsete testide jaoks. Tootmisrežiimis peaks demon käivituma automaatselt koos süsteemi käivitamisega.

sudo nime alt loome faili /etc/systemd/system/ipfs.service ja kirjutame sellesse:

[Unit]
Description=IPFS Daemon
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 tuleb kindlasti asendada oma kasutajanimega (ja võimalik, et ipfs-i programmi täispäring on teil teine (täpselt tuleb märkida täispäring)).

Aktiveerime teenuse.

sudo systemctl enable ipfs.service

Käivitage teenus.

sudo service ipfs start

Kontrollime teenuse staatust.

sudo service ipfs status

Eksperimendi puhtuse huvides võite edaspidi serveri taaskäivitada, et veenduda, et ipfs käivitub automaatselt.

Lisame tuntud peerid

Vaatame olukorda, kus meil on IPFS sõlmed seadistatud nii välises serveris kui ka kohalikult. Välises serveris lisame mõne faili ja proovime seda IPFS kaudu kohalikult CID järgi kätte saada. Mis siis juhtub? Mõistagi ei tea kohalik server tõenäoliselt välisest serverist midagi ja proovib lihtsalt leida faili CID järgi, „küsides” kõikidelt talle teadaolevatelt IPFS peer’idelt (keda ta on juba „kohtunud”). Need omakorda küsivad teistelt. Ja nii edasi, kuni fail on leidud. Tegelikult toimub sama ka siis, kui proovime faili kätte saada ametlikust väravast ipfs.io. ipfs.io. Kui meil läheb hästi, leitakse fail mõne sekundiga. Ja kui ei, siis ei leita seda ka möödudes mõnest minutist, mis mõjutab oluliselt töö mugavust. Kuid me teame, kust see fail kõigepealt ilmub. Miks me ei ütle kohe meie kohalikule serverile „Otsi esimese asjana sealt”? Tundub, et see on võimalik.

1. Logime sisse kaugserverisse ja failis ~/.ipfs/config otsime

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

2. Käitame sudo service ipfs status ja otsime sealt kirjeid Swarm, näiteks:

Swarm announcing /ip4/ip_teie_serverist/tcp/4001

3. Koostame sellest üldise aadressi kujul „/ip4/ip_sinu_ сервер/tcp/4001/ipfs/$PeerID”.

4. Usaldusväärsuse huvides proovime meie kohaliku webui kaudu sellele aadressile lisada piire.

5. Kui kõik on korras, avame kohaliku konfiguratsiooni ~/.ipfs/config, otsime sealt „Bootstrap”: […
ja kirjutame esimese elemendina massiivi saadud aadressi.

Taaskäivitame IPFS-i.

Nüüd lisame faili välisele serverile ja proovime seda kohalikult küsida. See peaks kiiresti minema.

Kuid see funktsionaalsus on praegu ebastabiilne. Mida ma aru saan, isegi kui me määrame piire Bootstrapis, muudab ipfs protsessi käigus aktiivsete ühenduste nimekirja piiretega. Igal juhul arutatakse seda ja soovitakse võimalust määrata püsivad piirded. siit ja näiliselt eeldatakse lisada mõni funktsionaalsus ipfs@5.0+

Praeguseid piire saab vaadata nii webuis kui ka terminalis.

ipfs swarm peers

Seal ja seal saab käsitsi oma piiri lisada.

ipfs swarm connect "/ip4/ip_sinu_ сервер/tcp/4001/ipfs/$PeerID"

Kuni me seda funktsionaalsust ei paranda, saab kirjutada tööriista, mis kontrollib ühenduse olemasolu vajaliku piirdiga ja kui seda ei ole, lisab ühenduse.

Mõtisklused

IPFS-iga juba tuttavate seas on nii argumente IPFS-i kasutamise poolt kui ka vastu. Üldiselt on see mind taas IPFS-i süvenema pannud. arutelu Ja seoses mainitud aruteluga: ma ei saa öelda, et oleksin tugevalt vastu mõnele esitatud argumendile (ei nõustu ainult sellega, et poolteist programmeerijat kasutab IPFS-i). Kokkuvõttes on mõlemad pooled omaette õiged (eriti kommentaar chekitest. panebnostestmeid). Kuid kui jätta kõrvale moraali ja õiguslikud hinnangud, siis kes hindaks seda tehnoloogiat tehniliselt? Isiklikult on mul mingisugune sisetunne, et „see on kindlasti vajalik, sellel on konkreetsed perspektiivid“. Kuid miks just, puudub selge formuleering. Kui vaatame juba olemasolevaid tsentraliseeritud vahendeid, siis paljude parameetrite osas on need kaugel ees (tööstabiilsus, töökiirus, haldamisvõime jne). Siiski on mul üks mõte, mis tundub mõistlikuna ja mida ilmselt ei saa ellu viia ilma selliste detsentraliseeritud süsteemideta. Muidugi ei ole see liiga julge, kuid ma sõnastaksin selle nii: Internetis informatsiooni levitamise printsiip tuleb muuta.

Selgitan. Kui nüüd mõelda, siis praegu levib meie teave printsiibi alusel „loodan, et see, kellele ma selle edastasin, kaitseb seda ning see ei kao ära või ei jõua neile, kellele see ei olnud mõeldud“. Näiteks saab hõlpsasti vaadelda erinevaid meilitüüpe, pilveteenuseid jne. Ja mida me lõpuks saame? Habras hab Infosüsteemide turvalisus on esimene rida ja praktiliselt iga päev saame uudiseid uue globaalse lekke kohta. Põhimõtteliselt on kõik huvitav loetletud <iroonia>imeliselt</iroonia> artiklis. Suvi on peaaegu läbi. Peaaegu ei ole andmeid, mis oleks kaduma läinudSeda on öeldud, et peamised interneti hiiglased muutuvad üha suuremaks, koguvad enda alla üha rohkem teavet ning sarnased lekked on omamoodi informatsioonilised aatomipommid. Midagi sellist pole kunagi olnud, ja nüüd on see taas kord kohal. Kuigi paljud mõistavad, et riskid on olemas, jätkavad nad oma andmete usaldamist kolmandatele ettevõtetele. Esiteks ei ole alternatiive, ja teiseks lubavad nad, et on kõik augud ära täitnud ja midagi sellist ei kordugi.

Milline variant mulle tundub? Minu arvates peaks teave olema algselt avatud. Kuid avatus ei tähenda, et kõik peaks olema kergesti loetav. Räägin avatusest hoidmise ja levitamise osas, mitte täielikust avatusest lugemise osas. Ma arvan, et teave peaks olema avatud võtmetega. Lõppude lõpuks on avatud/suletud võtmete kontseptsioon juba vana, peaaegu sama vana kui internet. Kui teave ei ole konfidentsiaalne ja on suunatud laiale publikule, siis peaks see olema avaldatud kohe koos avatud võtmega (aga ikkagi krüpteeritud kujul, lihtsalt igaüks saab selle krüptovõtmega dekrüpteerida). Kui ei, siis avaldatakse see ilma avatud võtmeta, kuid võtme edastamine toimub sellele, kellele sellele teabele juurdepääs on vajalik. Sel juhul peaks see, kes peab seda lugema, olema ainult võtmega, ja kus seda teavet leida, ei peaks teda eriti huvitama — ta lihtsalt tõmbab selle võrku (see ongi uus levitamise põhimõte sisu järgi, mitte aadressi järgi).

Seega peavad ründajad massilise rünnaku jaoks hankima tohutu arvu privaatvõtmeid, ja on ebatõenäoline, et seda saab teha ühes kohas. See ülesanne on, minu arvates, keerulisem kui mingi kindla teenuse rikkumine.

Ja siin tuleb esile veel üks probleem: autorsuse kinnitamine. Praegu leiab internetist palju tsitaate, mis on kirjutatud meie tuttavate poolt. Kuid kust on garantiid, et just nemad need kirjutasid? Kui iga selline kirje kaasneks digitaalse allkirjaga, oleks see palju lihtsam. Ja pole tähtis, kus see teave asub, peamine on allkiri, mille vale välja tegemine on teadlikult keeruline.

Ja siin on huvitav asjaolu: IPFS kannab juba endas krüpteerimise vahendeid (sest see põhineb plokiahela tehnoloogial). Konfiguratsioonis on kohe märgitud privaatvõti.

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

Ma ei ole turvaekspert ja ei suuda täpselt öelda, kuidas seda õigesti kasutada, kuid tundub, et neid võtmeid kasutatakse IPFS-sõlmede vahelises vahetuses. Samuti js-ipfs ja sellised näidised projektidest nagu orbit-db, millel põhineb orbit.chat. Teisisõnu, teoreetiliselt saaks iga seade (nii mobiilne kui ka mitte) olla kergesti varustatud enda krüpteerimise ja dekrüpteerimise masinatega. Sellisel juhul jääb vaid igalühel hoolitseda oma privaatsete võtmete säilitamise eest ja igaüks on ise vastutav oma turvalisuse eest, mitte mitte mingisuguste superpopulaarsete internetigigantide inimfaktori pantvang.

Ainult registreeritud kasutajad saavad küsitluses osaleda. Logige sisse, palun.