🥇IPFS valutult (aga see ei ole täpselt nii)

Kuigi Habr'is on juba rohkem kui üks artikkel IPFS-ist.

Selgitan kohe, et ma ei ole selle valdkonna ekspert, kuid olen korduvalt olnud huvitatud sellest tehnoloogiast, kuid selle katsetamine on sageli kaasa toonud teatud valu. Täna võtsin ma taas ette eksperimendid ja sain mõningaid tulemusi, mida soovin jagada. Lühiülevaates kirjeldatakse IPFS-i installimise protsessi ja mõningaid nippe (kõik tehti ubuntu'is, teistel platvormidel ei ole proovitud).

Kui oled IPFS-i olemust maha maganud, siis on selle kohta siin üsna põhjalikult kirjeldatud: habr.com/ru/post/314768

Paigaldamine

Katselise puhtuse huvides soovitan installida see mõnel välist teenusel, kuna vaatame mõningaid allveelehti töötades kohaliku ja kaugjuhtimise režiimis. Hiljem saab vajadusel hõlpsasti eemaldada, seal pole palju.

Installime go

Ametlik dokumentatsioon
Praegust versiooni vaata golang.org/dl

Märkus: parem on installida IPFS kasutaja alt, kellel on plaanis seda kõige sagedamini kasutada. Asi on selles, et hiljem vaatame varianti mälu ühendamiseks FUSE ja seal on peensusi.

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

Siis tuleb keskkond uuendada (lisaks vaata siit: 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, et go on installeeritud

go version

Installime IPFS-i

Mulle meeldis kõige rohkem installida läbi ipfs-update.

Installime selle käsuga

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

Pärast seda saab käivitada selliseid käske:

ipfs-update versions — et näha kõiki saadaval olevaid versioone allalaadimiseks.
ipfs-update version — et näha praegu installitud versiooni (kuna meil pole veel IPFS-i paigaldatud, on see none).
ipfs-update install latest — installida viimane versioon IPFS-ist. Selle asemel latest võib vastavalt märkida mis tahes soovitud versiooni saadavalolevates.

Installime ipfs

ipfs-update install latest

Kontrollime.

ipfs --version

Otseselt installimise osas on kõik selge.

IPFS-i käitamine

Algatamine

Alustuseks on vaja teha initsialiseerimine.

ipfs init

Vastuseks saad 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

Sa saad täita soovitatud käsk

ipfs cat /ipfs/QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv/readme

Tulemus

Tere tulemast IPFS-i!

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

Kui te seda näete, olete edukalt installinud
IPFS-i ja olete nüüd ühenduses ipfs merkledag-iga!

 -------------------------------------------------------
| Ho.Peatsus:                                           |
|   See on alfa tarkvara. Kasutage oma riski alusel!   |
|   Palju on puudu või pole lihvitud. Seal on tõrkeid.  |
|   Mitte veel turvaline. Loe turvanoteid rohkemaks.    |
 -------------------------------------------------------

Vaadake mõnda muud faili selles kataloogis:

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

Siit hakkavad huvitavad asjad pihta. Poisid kasutavad oma tehnoloogiaid juba installimise faasis. Pakutud hash QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv — ei ole teie jaoks spetsiaalselt genereeritud, vaid sisseehitatud versiooni. See tähendab, et enne versiooni väljalaskmist olid nad ette valmistanud tervitusteksti, laadisid selle IPFS-i ja lisasid aadressi installijasse. Minu arvates on see väga äge. Ja seda faili (täpsemalt, kogu kausta) saab nüüd vaadata mitte ainult kohapeal, vaid ka ametlikul väraval. ipfs.io/ipfs/QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv. Selle juures võib olla kindel, et kausta sisu ei ole muutunud, sest kui see oleks muutunud, oleks hash ka muutunud.

Muide, antud juhul sarnaneb IPFS teataval määral versioonikontrolli serveriga. Kui kausta algfailides teha muudatusi ja see uuesti IPFS-i laadida, saab see uue aadressi. Kuid vana kaust ei kao kuhugi ja jääb kättesaadavaks oma endisel aadressil.

Otsene käivitamine

ipfs daemon

Peate vastuseks saama midagi sellist:

ipfs daemon
Initsialiseerib deemonit...
go-ipfs versioon: 0.4.22-
Repo versioon: 7
Süsteemi versioon: amd64/linux
Golang versioon: go1.12.7
Swarm kuulamine aadressil \/ip4\/x.x.x.x\/tcp\/4001
Swarm kuulamine aadressil \/ip4\/127.0.0.1\/tcp\/4001
Swarm kuulamine aadressil \/ip6\/::1\/tcp\/4001
Swarm kuulutamine \/p2p-circuit
Swarm kuulutamine aadressil \/ip4\/127.0.0.1\/tcp\/4001
Swarm kuulutamine aadressil \/ip6\/::1\/tcp\/4001
API server kuulamine aadressil \/ip4\/127.0.0.1\/tcp\/5001
WebUI: http:\/\/127.0.0.1:5001\/webui
Värav (ainult lugemiseks) server kuulamine aadressil \/ip4\/127.0.0.1\/tcp\/8080
Deemon on valmis

Avame uksed Internetile

Pange tähele neid kahte rida:

WebUI: http:\/\/127.0.0.1:5001\/webui
Värav (ainult lugemiseks) server kuulamine aadressil \/ip4\/127.0.0.1\/tcp\/8080

Kui olete IPFS-i enda kohalikult installinud, siis pääsete IPFS-i liidestele ligi kohalikelt aadressidelt ja kõik on teile kergesti kättesaadav (näiteks, localhost:5001/webui/). Kuid välises serveris installimisel on vaikimisi väravad internetile suletud. Väravaid on kaks:

Admin paneel webui (github) porti 5001.
Väline API porti 8080 (ainult lugemiseks).

Katsetamiseks võib avada mõlemad portid (5001 ja 8080), kuid tootmiserveris tuleks port 5001 kindlasti tulemüüriga sulgeda. Veel on port 4001, mis on vajalik, et teised peerid saaksid sind leida. See tuleks jätta avatud väliste päringute jaoks.

Avame redigeerimiseks ~/.ipfs/config ja otsime 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"
}

Asendame 127.0.0.1 oma serveri IP-iga ja salvestame faili, seejärel taaskäivitame ipfs (peatusime jooksva käsu Ctrl+C ja käivitame uuesti).

Peame saama

...
WebUI: http:\/\/ip_oma_serveri:5001\/webui
Gateway (ainult lugemiseks) server kuulab adresimil \/ip4\/ip_oma_serveri\/tcp\/8080

Nüüd peaksid välised liidesed olema kergesti ligipääsetavad.

Kontrollige

http:\/\/domeen_või_ip_serverist:8080\/ipfs\/QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv\/readme

Peab avama ülaltoodud readme faili.

http:\/\/domeen_või_ip_serverist:5001\/webui\/

Peab avanema veebiliides.

Kui sinu webui töötab, saad IPFS-i seadeid otse selles muuta, sealhulgas vaadata statistikat, kuid allpool vaatan konfiguratsiooni võimalusi otse konfiguratsioonifaili kaudu, mis pole tegelikult kriitiline. On parem lihtsalt meeles pidada, kus see fail asub ja mida sellega teha, sest kui veebiliides ei töötaks, oleks see keerulisem.

Konfigureerime veebiliidese töötamiseks oma serveriga

Siin on esimene lõks, millele kulus umbes kolm tundi.

Kui olete IPFS-i installinud välises serveris, kuid ei ole seda kohalikult installinud ega käivitanud, siis kui sisenete /webui veebiliidesesse, peaksite nägema ühenduse viga:

Asi on selles, et minu arvates töötab webui väga segaselt. Alguses proovib see ühendust luua selle serveri API-ga, kus liides on avatud (muidugi browseris oleva aadressi põhjal). Ja kui see ei õnnestu, proovib see ühendust saada kohalikule väravale. Ja kui sul on kohalikult IPFS käivitatud, siis töötab sinu webui normaalselt, kuid sa töötad kohaliku IPFS-iga, mitte välisega, kuigi avasid webui välises serveris. Siis laed failid üles, aga mingil põhjusel ei näe neid lihtsalt niisama välises serveris...

Ja kui ka kohapeal ei käivitu, saame ühenduse vea. Meie puhul on veaks tõenäoliselt CORS, millest räägib ka webui, pakkudes konfi lisada.

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

Mina olen lihtsalt wildcardsi seadnud.

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

Lisatud päiseid saab leida kõik ~/.ipfs/config. Minu puhul need on

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

Taaskäivitame ipfs-i ja näeme, et webui on edukalt ühendatud (vähemalt peaks olema, kui avate väravad väljastpoolt päringute tegemiseks, nagu eespool kirjeldatud).

Nüüd saab otse läbi veebiliidese üles laadida kaustu ja faile ning luua oma kaustu.

FUSE failisüsteemi monteerimine

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 hashiga saame avada kausta mis tahes ipfs-sõlmes (mis suudab meie sõlme leida ja sisu saada), kas veebiliidese kaudu portidel 5001 või 8080, või kohapeal ipfs-i kaudu.

ipfs ls QmbnzgRVAP4fL814h5mQttyqk1aUxxxxxxxxxxxxx
QmfYuz2gegRZNkDUDVLNa5DXzKmKVxxxxxxxxxxxxxx 10 test.txt

Kuid 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 näidata nende teed ipfs daemon —mount —mount-ipfs /ipfs_path —mount-ipns /ipns_path parameetrite kaudu.

Nüüd on selle kausta lugemine mõnevõrra ebatavaline.

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

Stiilis ei ole otsest ligipääsu selle kausta juurele. Kuid sisu saab kätte, kui tead 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

Samuti töötab kaustas isegi automaatne täiendamine, kui näidatakse teed.

Nagu ma eelnevalt ütlesin, on sellise montaaži puhul teatud nüansid: vaikimisi on monteeritud FUSE-kaustad ainult praegusele kasutajale kergesti kättesaadavad (isegi root ei saa selliselt kaustalt lugeda, rääkimata süsteemi teistest kasutajatest). Kui soovite neid kaustu jagada teiste kasutajatega, tuleb konfiguratsioonis muuta "FuseAllowOther": false "le "FuseAllowOther": true. Kuid see ei ole veel kõik. Kui käitate IPFS-i root-kasutajana, siis on kõik korras. Kui aga tavalise kasutajana (isegi sudo kaudu), siis saate vea.

mount helper error: fusermount: option allow_other only allowed if 'user_allow_other' is set in /etc/fuse.conf

Sel juhul tuleb muuta /etc/fuse.conf, eemaldades kommenteerimise rea #user_allow_other.

Peale seda taaskäivitame ipfs.

Tuntud probleemid FUSE-iga

On rohkem kui korra märgatud, et pärast ipfs-i restartimist montaažiga (võib-olla ka muudel juhtudel) muutuvad monteerimispunktid /ipfs ja /ipns kättesaamatuks. Neile ei pääse ligipääsu ja ls -la /ipfs näitab ???? õiguste loendis.

Leidsin sellise lahenduse:

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

Peale seda taaskäivitame ipfs.

Lisame teenuse

Loomulikult sobib terminalis käivitamine ainult algseteks testideks. Tootmisrežiimis peaks demon automaatselt käivituma süsteemi käivitamisel.

Sudo kasutades 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 loomulikult asendada enda kasutajanimega (ja võib-olla on teie ipfs programmi täispikkus erinev (täpselt täispikkus peab olema).

Aktiveerime teenuse.

sudo systemctl enable ipfs.service

Käivitage teenus.

sudo service ipfs start

Kontrollige teenuse staatust.

sudo service ipfs status

Eksperimendi puhtuse nimel võiks hiljem serverit taaskäivitada, et kontrollida, kas ipfs käivitub automaatselt.

Lisame tuntud peerid.

Vaatame olukorda, kus meil on IPFS-i sõlmed paigaldatud nii välisel serveril kui ka kohalikult. Välisel serveril lisame mõne faili ja üritame seda IPFS-i kaudu kohalikult CID järgi saada. Mis juhtub? Loomulikult ei tea kohalik server tõenäoliselt midagi meie välistest serveritest ning üritab lihtsalt faili leida CID kaudu, "küsides" kõikidelt kätte saadavatelt IPFS-i peer'idelt (kellega ta on juba "tutvunud"). Need omakorda küsivad teiste käest. Ja nii edasi, kuni fail leitakse. Tegelikult toimub sama ka siis, kui üritame faili saada ametliku värava kaudu ipfs.io. Kui meil on veidi õnne, leitakse fail mõne sekundi jooksul. Kui mitte, siis ei leita seda isegi mõne minuti jooksul, mis mõjutab töö mugavust. Kuid meie teame, kus see fail esmakordselt ilmub. Miks ei võiks meie kohalikule serverile kohe öelda "Otsi kõigepealt sealt"? Näib, et seda on võimalik teha.

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

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

2. Tõstame esile sudo service ipfs status ja otsime sealt Swarm'i kirjeid, näiteks:

Swarm announcing /ip4/ip_teie_serverist/tcp/4001

3. Koostame sellest üldise aadressi kujul "/ip4/ip_teie_serverist/tcp/4001/ipfs/$PeerID".

4. Usaldusväärsuse huvides proovime meie kohalikus webui's seda aadressi peer'idena lisada.

5. Kui kõik on OK, avame kohaliku konfi ~/.ipfs/config, leidame sealt "Bootstrap": […
ja lisame esimesena massiivi saadud aadressi.

Taaskäivitame IPFS-i.

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

Aga see funktsioon on hetkel ebastabiilne. Niipalju kui ma aru saan, isegi kui me näitame peer'i aadressi Bootstrapis, muudab ipfs töö käigus aktiivsete ühenduste nimekirja peer'idega. Igal juhul on selle arutelu ja soovide osas, et võimaldada püsivate peer'ide määramist, arutelu käimas siin ja nagu tundub on eeldatud plaanitakse lisada mingit funktsionaalsust ipfs@5.0+

Hetkel saab vaadata praeguste peer'ide nimekirja nii webui's kui ka terminalis.

ipfs swarm peers

Mõlemal platvormil on võimalik käsitsi oma peer lisada.

ipfs swarm connect "/ip4/ip_teie_serverist/tcp/4001/ipfs/$PeerID"

Kuni seda funktsionaalsust pole parendatud, võib kirjutada tööriista, mis kontrolliks ühenduse olemasolu soovitud peer'iga ning kui seda ei ole, lisab ühenduse.

Mõtisklused

IPFS-iga juba tuttavate seas on nii argumente selle poolt kui ka selle vastu. Üldiselt, eelmisel nädalal arutelu ja see pani mind uuesti IPFS-i süvitsi kaevama. Ja nüüd, mis puudutab mainitud arutelu: ma ei saa öelda, et ma oleksin midagi kellestki välja öeldud argumendist tõeliselt vastu (olen vaid nõus, et poolteist programmeerijat kasutab IPFS-i). Üldiselt on mõlemad pooled oma moodi õiged (eriti kommentaar tšekkide paneb mõtlema). Aga kui kõrvale jätta moraalne ja juriidiline hinnang, millise tehnilise hinnangu sellele tehnoloogiale antakse? Isiklikult on mul tunne, et "see on kindlasti vajalik, see omab teatud perspektiive". Kuid miks just nii, ei ole selget sõnastust. Tundub, et kui vaadata juba olemasolevaid tsentraliseeritud vahendeid, on need paljuski palju edasiviivamad (stabiilsus, töökiirus, haldusteadlikkus jne). Sellegipoolest on mul üks mõte, mis näib mõttekas ja mille elluviimine ilma selliste detsentraliseeritud süsteemideta on ebatõenäoline. Muidugi, see on üsna ambitsioonikas, kuid ma sõnastaksin selle nii: Internetis info levitamise põhimõte tuleb muuta.

Selgitan. Kui nüüd hästi mõelda, siis praegu levitatakse infot põhimõttel: "Ma loodan, et see, kellele ma selle edastasin, kaitseb seda ja see ei kao ega jõua kellegi kätesse, kellele see ei ole mõeldud". Lihtne on vaadata erinevaid postiteenuseid, pilveteenuseid jne. Ja mis me kokkuvõttes saame? Habré Infotehnoloogia turvalisus on esimesel kohal ja praktiliselt iga päev saame uudiseid järgmise suure lekke kohta. Üldiselt on kõik kõige huvitavam loetletud <ironija>imeilusas<\/ironija> artiklis. Suvi on peaaegu läbi. Peaaegu pole andmeid kaduma läinudSee tähendab, et peamised internetigigandid muutuvad üha suuremateks, koguvad endasse üha rohkem teavet ja sellised lekked on omamoodi infoaatomipommid. Midagi sellist ei ole kunagi olnud ja nüüd jälle. Kuigi paljud mõistavad, et riskid on olemas, usaldavad nad siiski oma andmed kolmandatele ettevõtetele. Esiteks, alternatiive pole, ja teiseks, need lubavad, et nad on kõik augud kinni mässinud ja midagi sellist ei juhtu enam kunagi.

Milline variant mulle paistab? Minu arvates peaks teave algselt olema vabalt kättesaadav. Aga avatus ei tähenda, et kõik peaks olema kergelt loetav. Räägin avatusest säilitamise ja levitamise osas, kuid mitte täielikust avatusest lugemise osas. Eeldan, et teave peaks levima koos avatud võtmete kasutamisega. Lõppude lõpuks on avatud/suletud võtmete printsiip juba vana, peaaegu sama vana kui Internet. Kui teave ei ole konfidentsiaalne ja on suunatud laiale publikule, siis jagatakse see kohe avatud võtmega (kuid ikkagi krüpteeritud kujul, sest igaüks saab selle dekrüpteerida olemasoleva võtmega). Kui ei, siis jagatakse see ilma avatud võtmeta ning võtme saamine antakse sellele, kellel on lubatud sellele teabele juurde pääseda. Samuti peaks selle teabe lugemiseks olema ainult võtme omamine oluline, mitte see, kust teave saada — see tuleb lihtsalt võrgu kaudu (see ongi uus printsiip sisu põhjal levimise kohta, mitte aadressi põhjal).

Seega peavad kurjategijad massiliste rünnakute jaoks saama tohutu hulga suletud võtmeid, ja tõenäoliselt ei õnnestu neil seda ühes kohas teha. See ülesanne tundub mulle keerulisem kui konkreetse teenuse häkkimine.

Ja siin tõuseb esile veel üks probleem: autorluse kinnitamine. Praegu leidub Internetis palju tsitaate, mille autoriteks on meie tuttavad. Kuid kus on garantii, et just nemad need kirjutasid? Kui iga selline kirje kaasneks digitaalse allkirjaga, oleks see palju lihtsam. Pole vahet, kus see teave asub, peamine on allkiri, mida on tõenäoliselt raske võltsida.

Ja siin on huvitav aspekt: IPFS sisaldab juba krüpteerimisvahendeid (lõppude lõpuks on see üles ehitatud plokiahela tehnoloogiale). 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\/Zijgq27oLyxKNr9T7
2gxqPCI06VTfMiCL1wBBUP1wHdFmD\/YLJwOjV\/sVzbsl9HxqzgzlDtfMn\/bJodcURFI1sf1e6WO+MyTc3.................

Ma ei ole turvaekspert ja ei oska täpselt öelda, kuidas seda õigesti kasutada, kuid tundub, et IPFS-sõlmede vahelise vahetuse tasandil kasutatakse neid võtmeid. Ja veel js-ipfs ja sellised projektid-näidised nagu orbit-db, millel põhineb orbit.chat. Teoorias võiks iga seade (mobiilne ja mitte ainult) olla kergesti varustatud oma šifreerimise-dešifreerimise masinatega. Sel juhul peab igaüks lihtsalt hoolitsema oma privaatsete võtmete säilitamise eest ja igaüks on ise vastutav oma turvalisuse eest, mitte olles teiste inimfaktorite pantvangi mõnes superpopulaarses interneti hiigis.

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