🥇IPFS bez sāpēm (bet tas nav precīzi)

Lai gan Habrā jau ir bijušas ne viena raksts par IPFS.

Vispirms gribu precizēt, ka neesmu eksperts šajā jomā, taču ne vienu reizi vien esmu izrādījis interesi par šo tehnoloģiju, un mēģinājumi ar to kaut ko izdarīt ir bieži radījuši zināmas grūtības. Šodien atkal ķēros pie eksperimentiem un ieguvu dažus rezultātus, ar kuriem vēlētos padalīties. Īsumā, tiks aprakstīts IPFS uzstādīšanas process un dažas īpatnības (viss tika veikts uz ubuntu, uz citām platformām neesmu mēģinājis).

Ja jūs esat palaidis garām, kas ir IPFS, diezgan detalizēti par to rakstīts šeit: habr.com/ru/post/314768

Uzstādīšana

Eksperimenta tīrībai iesaku uzreiz instalēt kādā ārējā serverī, jo mēs apskatīsim dažas problēmas, strādājot lokālā režīmā un attālināti. Vēlāk, ja būs vēlme, tur nebūs ilgi jādara, tur nav daudz.

Uzstādām go

Oficiālā dokumentācija
Aktuālo versiju skatiet uz golang.org/dl

Piezīme: labāk uzstādīt IPFS ar lietotāja kontu, kuru paredzēts visbiežāk izmantot. Proti, tālāk mēs aplūkosim variantu ar montēšanu caur FUSE un tur ir nianses.

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

Pēc tam jāatjaunina vide (sīkāk šeit: 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

Pārbaudām, vai go ir uzstādīts

go version

Uzstādām IPFS

Man visvairāk patika uzstādīšanas veids caur ipfs-update.

Uzstādām to ar komandu

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

Pēc tam var izpildīt šādas komandas:

ipfs-update versions — lai redzētu visus pieejamos versijas lejupielādei.
ipfs-update version — lai redzētu pašreizējo uzstādīto versiju (kamēr mums IPFS nav uzstādīts, būs none).
ipfs-update install latest — uzstādīt jaunāko IPFS versiju. Vietā latest attiecīgi var norādīt jebkuru vēlamo versiju no pieejamo saraksta.

Uzstādām ipfs

ipfs-update install latest

Pārbaudām

ipfs --version

Tieši ar uzstādīšanu vispārīgā skatījumā viss.

IPFS palaišana

Inicializācija

Vispirms ir jāveic inicializācija.

ipfs init

Atbilde būs kaut kas līdzīgs šim:

 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

Varat izpildīt ieteikto komandu

ipfs cat /ipfs/QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv/readme

Rezultāts

Sveiki un laipni lūdzam IPFS!

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

Ja redzat šo, tad jūs veiksmīgi esat uzstādījuši
IPFS un tagad sadarbojaties ar ipfs merkledag!

 -------------------------------------------------------
| Brīdinājums:                                         |
|   Tas ir alfa programmatūru. Lietojiet uz savu atbildību! |
|   Daudz kas trūkst vai nav attīrīts. Ir kļūdas.      |
|   Vēl nav droši. Izlasiet drošības piezīmes vairāk.  |
 -------------------------------------------------------

Pārbaudiet dažus citus failus šajā direktorijā:

  .\/about
  .\/help
  .\/quick-start     <-- lietošanas piemēri
  .\/readme          <-- šis fails
  .\/security-notes

Manuprāt, šeit sākas kas interesants. Puisis jau uzstādīšanas procesā sāk izmantot savas tehnoloģijas. Piedāvātais hashes QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv — nav speciāli ģenerēts jums, bet iekļauts laidienā. Tas nozīmē, ka līdz laidienam viņi sagatavoja sagaidīšanas tekstu, izlaida to IPFS un pievienoja adresi instalētājam. Manuprāt, tas ir ļoti forši. Un šo failu (precīzāk, visu mapi) tagad var apskatīt ne tikai lokāli, bet arī oficiālajā vārtejā. ipfs.io/ipfs/QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv. Tajā pašā laikā var būt drošs, ka mapes saturs nav mainījies, jo, ja tas būtu mainījies, tad hash arī būtu mainījies.

Starpcitu, šajā gadījumā IPFS daļēji atgādina versiju kontroles serveri. Ja sākotnējos failos ieviest izmaiņas un atkal izlaist mapi IPFS, tai būs jauna adrese. Tajā pašā laikā vecā mapa nekad nepazudīs un būs pieejama pa savu iepriekšējo adresi.

Tūlītējā palaišana

ipfs daemon

Atbildei vajadzētu būt līdzīgai šādai:

ipfs daemon
Initializing daemon...
go-ipfs version: 0.4.22-
Repo version: 7
System version: amd64/linux
Golang version: go1.12.7
Swarm listening on /ip4/x.x.x.x/tcp/4001
Swarm listening on /ip4/127.0.0.1/tcp/4001
Swarm listening on /ip6/::1/tcp/4001
Swarm listening on /p2p-circuit
Swarm announcing /ip4/127.0.0.1/tcp/4001
Swarm announcing /ip6/::1/tcp/4001
API server listening on /ip4/127.0.0.1/tcp/5001
WebUI: http://127.0.0.1:5001/webui
Gateway (readonly) server listening on /ip4/127.0.0.1/tcp/8080
Daemon is ready

Atveram durvis uz internetu

Pievērsiet uzmanību šīm divām rindām:

WebUI: http://127.0.0.1:5001/webui
Gateway (readonly) server listening on /ip4/127.0.0.1/tcp/8080

Ja jūs esat uzstādījis IPFS lokāli, tad jūs piekļūsiet IPFS interfeisiem caur lokālajām adresēm un viss būs pieejams (piemēram, localhost:5001/webui/). Taču, kad tiek uzstādīts uz ārēja servera, noklusējuma vārti ir slēgti no interneta. Ir divi vārti:

Webui administrācija (github) uz porta 5001.
Ārējais API uz porta 8080 (tikai lasīšanai).

Eksperimentiem var atvērt abus portus (5001 un 8080), taču darba serverī portam 5001 protams jābūt slēgtam ar ugunsmūri. Vēl ir 4001 ports, tas ir nepieciešams, lai citi pavadoņi varētu jūs atrast. To jāatstāj atvērtam ārējiem pieprasījumiem.

Atveram rediģēšanai ~/ipfs/config un atrodam tajā šīs rindas:

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

Nomainām 127.0.0.1 uz jūsu servera IP un saglabājam failu, pēc tam pārstartējam ipfs (apturēto komandu apturam ar Ctrl+C un atkal palaižam).

Jums jāsaņem

...
WebUI: http://ip_jūsu_servera:5001/webui
Vārteju (tikai lasīšanai) serveris klausās uz /ip4/ip_jūsu_servera/tcp/8080

Tagad ārējie saskarnes jābūt pieejamiem.

Pārbaudiet

http://domein_vai_ip_servera:8080/ipfs/QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv/readme

Atvērsies iepriekš minētais readme fails.

http://domein_vai_ip_servera:5001/webui/

Atvērsies tīmekļa saskarne.

Ja jums strādā webui, tad IPFS iestatījumus var mainīt tieši tajā, tostarp apskatīt statistiku, taču zemāk es apskatīšu konfigurācijas iespējas tieši caur failu konfigurāciju, kas kopumā nav kritiski. Tikai labāk atcerēties, kur tieši konfigurācija atrodas un ko ar to darīt, jo, ja tīmekļa saskarne nedarbosies, būs jau sarežģītāk.

Konfigurējam tīmekļa saskarni darbam ar savu serveri

Te ir pirmais akmenis, uz kura tika pavadītas trīs stundas.

Ja esat IPFS uzstādījis uz ārēja servera, bet neesat uzstādījis vai palaidis IPFS lokāli, tad, dodoties uz /webui tīmekļa saskarnē, jums jādara kļūdas savienojumā:

Problēma ir tā, ka webui, manuprāt, darbojas diezgan neskaidri. Sākumā tas mēģina pieslēgties API tam serverim, kur ir atvērta saskarne (protams, pamatojoties uz pārlūkprogrammas adresi). Un, ja tas tur neizdodas, tas cenšas pieslēgties lokālajam vārtiem. Un, ja jums ir lokāli palaists IPFS, tad jūsu webui darbosies normāli, tikai, ka jūs strādāsiet ar lokālo IPFS, nevis ārējo, lai arī esat atvēruši webui uz ārēja servera. Pēc tam augšupielādējat failus, bet kaut kāpēc tos nenojaucat vienkārši tā uz ārēja servera...

Ja, ja neesmu palaidis lokāli, mēs saņemam savienojuma kļūdu. Mūsu gadījumā kļūda visticamāk ir saistīta ar CORS, par ko liecina arī webui, piedāvājot pievienot konfigurāciju.

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

Es pie sevis vienkārši norādīju wildcard.

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

Pievienotās galvenes var atrast tajā pašā ~/.ipfs/config. Manā gadījumā tas ir

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

Pārstartējam ipfs un redzam, ka webui veiksmīgi savienojies (vismaz tā vajadzētu būt, ja esat atvēris vārtejas piekļuvei no ārpuses, kā aprakstīts iepriekš).

Tagad var tieši caur tīmekļa saskarni augšupielādēt mapes un failus, kā arī izveidot savas mapes.

FUSE failu sistēmas montēšana

Šis ir diezgan interesants funkcionalitātes elements.

Failus (tāpat kā mapes) mēs varam pievienot ne tikai caur tīmekļa saskarni, bet arī tieši terminālī, piemēram,

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

Pēdējais hash ir saknes mapes hash.

Izmantojot šo hash, mēs varam atvērt mapi jebkurā ipfs mezglā (kas var atrast mūsu mezglu un iegūt saturu), varam izmantot tīmekļa saskarni portā 5001 vai 8080, vai lokāli caur ipfs.

ipfs ls QmbnzgRVAP4fL814h5mQttyqk1aUxxxxxxxxxxxxx
QmfYuz2gegRZNkDUDVLNa5DXzKmKVxxxxxxxxxxxxxx 10 test.txt

Bet vēl var atvērt arī kā parastu mapi.

Izveidosim divas mapes saknē un piešķirsim tām tiesības mūsu lietotājam.

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

un pārstartēsim ipfs ar karogu —mount

ipfs daemon --mount

Var izveidot mapes arī citās vietās un norādīt ceļu uz tām, izmantojot ipfs daemon —mount —mount-ipfs /ipfs_path —mount-ipns /ipns_path

Tagad lasīšana no šīs mapes ir nedaudz neparasta.

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

Proti, tiešas piekļuves saknei šai mapē nav. Bet var iegūt saturu, zinot 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

Šajā mapē pat automātiskā pabeigšana darbojas, norādot ceļu.

Kā jau iepriekš teicu, šādā montēšanā ir nianses: pēc noklusējuma FUSE mapes ir pieejamas tikai pašreizējam lietotājam (pat root nevar izlasīt no šādas mapes, nemaz nerunājot par citiem sistēmas lietotājiem). Ja vēlaties, lai šīs mapes būtu pieejamas citiem lietotājiem, konficē jāmaina „FuseAllowOther”: false uz „FuseAllowOther”: true. Bet tas vēl nav viss. Ja jūs IPFS palaidat root vārdā, tad viss ir kārtībā. Bet, ja parastā lietotāja vārdā (pat ar sudo), tad saņemsiet kļūdu.

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

Šādā gadījumā jāpamaina /etc/fuse.conf, komentējot ārā rindu #user_allow_other.

Pēc tam pārstartējam ipfs.

Zināmas problēmas ar FUSE

Nav reizi novērota problēma, ka pēc ipfs pārstartēšanas ar montēšanu (un iespējams citos gadījumos) montēšanas punkti /ipfs un /ipns kļūst nepieejami. Pieejas pie tām nav nekāda, un ls -la /ipfs parāda ???? saraksta tiesībās.

Atradu tādu risinājumu:

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

Pēc tam atkal pārstartējam ipfs.

Pievienojam pakalpojumu

Protams, palaišana terminālī ir piemērota tikai sākotnējiem testiem. Ražošanas režīmā deva jāpalaiž automātiski, kad tiek uzsākta sistēma.

Soda vārdā izveidojam failu /etc/systemd/system/ipfs.service un ierakstām tajā:

[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 protams jāaizstāj ar savu lietotāju (un iespējams pilnais ceļš uz ipfs programmu jums būs citāds (norādiet tieši pilno ceļu)).

Aktivizējam pakalpojumu.

sudo systemctl enable ipfs.service

Palaidiet pakalpojumu.

sudo service ipfs start

Pārbaudām pakalpojuma statusu.

sudo service ipfs status

Eksperimenta tīrībai varētu vēlāk restartēt serveri, lai pārbaudītu, vai ipfs veiksmīgi sākās automātiski.

Pievienojam zināmos mums pīrus.

Apsverīsim situāciju, kad mums ir IPFS mezgli uzstādīti gan uz ārējā servera, gan lokāli. Uz ārējā servera mēs pievienojam kādu failu un cenšamies to iegūt caur IPFS lokāli pēc CID. Kas notiks? Protams, ka lokālais servers, iespējams, neko nezina par mūsu ārējo serveri un vienkārši mēģinās atrast failu pēc CID, "jautājot" visiem tam pieejamajiem IPFS mezgliem (ar kuriem tam jau izdevies "iepazīties"). Tie savukārt vaicās citiem. Un tā, līdz fails tiek atrasts. Faktiski tas pats notiek, kad mēs cenšamies failu iegūt caur oficiālo vārteju. ipfs.io. Ja paveiksies, fails tiks atrasts dažu sekunžu laikā. Bet, ja nē, tad tas netiks atrasts pat dažu minūšu laikā, kas ļoti stipri ietekmē darba komfortu. Bet mēs taču zinām, kur šis fails vispirms parādīsies. Kāpēc tad uzreiz nepasakām mūsu lokālajam serverim "Meklē vispirms tur"? Izskatās, ka to var izdarīt.

1. Ieejam attālinātajā serverī un konfigūrācijā ~/.ipfs/config meklējam

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

2. Izpildām sudo service ipfs status un meklējam tajā ierakstus Swarm, piemēram:

Swarm announcing /ip4/ip_ūsu_servera/tcp/4001

3. Izveidojam no tā kopējo adresi veidā "/ip4/ip_ūsu_servera/tcp/4001/ipfs/$PeerID".

4. Lai nodrošinātu uzticamību, caur mūsu lokālo webui mēģinām pievienot šo adresi mezgliem.

5. Ja viss ir kārtībā, atveram lokālo konfigurāciju ~/.ipfs/config, atrodam tajā "Bootstrap": […
un pievienojam pirmajam masīvā iegūto adresi.

Restartējam IPFS.

Tagad pievienosim failu uz ārējā servera un mēģināsim to pieprasīt lokāli. Tam jāierodas ātri.

Bet šī funkcionalitāte pagaidām nav stabila. Cik es saprotu, pat ja mēs norādām adrese mezgam Bootstrap, IPFS darbības laikā maina aktīvo savienojumu sarakstu ar mezgliem. Katrā ziņā diskusijas par to un vēlmes attiecībā uz iespēju norādīt pastāvīgus mezglus norisinās. šeit un izskatās, ka ir paredzēts pievienot kādu funkcionalitāti ipfs@5.0+

Pašreizējā mezglu sarakstu var apskatīt gan webui, gan terminālī.

ipfs swarm peers

Gan tur, gan šeit var manuāli pievienot savu mezglu.

ipfs swarm connect "/ip4/ip_ūsu_servera/tcp/4001/ipfs/$PeerID"

Kamēr šo funkcionalitāti neuzlabos, var uzrakstīt rīku, lai pārbaudītu savienojuma esamību ar nepieciešamo mezglu un, ja nav, pievienotu savienojumu.

Pārdomas

Starp tiem, kas jau pazīst IPFS, ir gan argumenti par, gan pret IPFS. Principā, aizvadītajā dienā diskusiju un tas mudināja mani vēlreiz izpētīt IPFS. Un attiecībā uz minēto diskusiju: es nevaru teikt, ka es ļoti iebilstu pret kādu no izteiktajiem argumentiem (nepiekrītu tikai tam, ka pusotrs programmētājs izmanto IPFS). Kopumā katrs ir pa savam taisnīgs, un jo īpaši komentārs par čeku ir pārdomu vērts). Bet, ja atmetam morālo un juridisko vērtējumu, kāds sniegs tehnisko novērtējumu šai tehnoloģijai? Personīgi man ir kāds iekšējs sajūta, ka "tas noteikti ir nepieciešams, tam ir noteiktas perspektīvas". Bet kāpēc tieši, nav skaidras formulējuma. Tipa, ja paskatāmies uz jau esošajiem centralizētajiem līdzekļiem, tad pēc daudziem parametriem tie ir ievērojami priekšā (darba stabilitāte, darba ātrums, pārvaldāmība utt.). Tomēr man ir viena doma, kas šķiet jēgpilna, un kuru, visticamāk, nevarēs īstenot bez šādām decentralizētām sistēmām. Protams, es ļoti izvēlos riskēt, bet es to formulētu šādi: principam, kā informācija izplatās internetā, ir jāmainās.

Izskaidrošu. Ja padomājam, šobrīd mūsu informācija izplatās pēc principa: "Es ceru, ka tas, kuram es to nodevu, to aizsargās un tā netiks pazaudēta vai iegūta no tiem, kam tā nav paredzēta." Piemēram, viegli var apsvērt dažādus e-pasta pakalpojumus, mākoņa krātuves utt. Un ko mēs iegūstam beigās? Habrā Informācijas drošība stāv pirmajā vietā, un praktiski katru dienu saņemam ziņas par kārtējo globālo noplūdi. Principā, viss interesantākais ir uzskaitīts "brīnišķīgajā" rakstā Vasara gandrīz beigusies. Gandrīz nav nemaz neizsūtītu datu. Tātad galvenie interneta milži kļūst arvien lielāki, uzkrājot pie sevis arvien vairāk informācijas, un līdzīgas noplūdes ir sava veida informācijas atomu sprādzieni. Nekad tā nav bijis, un lūk, atkal. Tajā pašā laikā, lai gan daudzi saprot, ka pastāv riski, turpinās uzticēt savus datus trešām pusēm. Pirmkārt, alternatīvu īpaši nav, un, otrkārt, viņi solās, ka ir aizlāpījuši visas vājās vietas un tā vairs nekad neatkārtosies.

Kāds variants man šķiet vispiemērotākais? Man šķiet, ka datiem no sākuma jābūt izplatītiem publiski. Taču atklātība šajā gadījumā nenozīmē, ka visam jābūt viegli lasāmam. Es runāju par datu uzglabāšanas un izplatīšanas atklātību, bet ne par pilnīgu pieejamību lasīšanai. Es pieņemu, ka informācijai jāizplatās ar atklātiem atslēgām. Galu galā atklāto/slēpto atslēgu princips ir jau vecs, tikpat vecs kā internets. Ja informācija nav konfidenciāla un tiek paredzēta plašam lokam, tad tā tiek publicēta tūlīt ar atklātu atslēgu (tomēr šī informācija joprojām ir šifrēta, tikai ikviens to var atšifrēt, izmantojot esošo atslēgu). Un, ja tā nav, informācija tiek publicēta bez atklātas atslēgas, savukārt pati atslēga tiek nodota tam, kuram ir jāpiekļūst pie šīs informācijas. Tajā pašā laikā tam, kuram jāizlasa, ir jābūt tikai atslēgai, un viņam nav jāuztraucas, kur iegūt šo informāciju — viņš to vienkārši velk no tīkla (tas ir jaunais izplatīšanas princips pēc satura, nevis pēc adreses).

Tādējādi uzbrucējiem, lai veiktu masveida uzbrukumu, būs jāiegūst milzīgs skaits slēptu atslēgu, un, visticamāk, to nevienā vietā nevarēs izdarīt. Šis uzdevums, manuprāt, ir sarežģītāks nekā kāda konkrēta pakalpojuma uzlaušana.

Un šeit slēdzas vēl viena problēma: autortiesību apstiprināšana. Tagad internetā var atrast daudz citātu, ko uzrakstījuši mūsu paziņas. Bet kur ir garantija, ka tieši viņi tos rakstījuši? Ja katrs šāds ieraksts tiktu pavadīts ar digitālo parakstu, tad būtu daudz vieglāk. Un nav svarīgi, kur šī informācija atrodas, galvenais ir paraksts, kuru, iespējams, ir grūti vilto.

Un kas šeit ir interesanti: IPFS jau satur šifrēšanas līdzekļus (galu galā tas ir balstīts uz blokķēdes tehnoloģiju). Konfigurācijā uzreiz ir norādīta privātā atslēga.

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

Es neesmu drošības speciālists un nevaru precīzi zināt, kā to pareizi izmantot, bet man šķiet, ka IPFS mezglu apmaiņas līmenī tiek izmantoti šie taustiņi. Un arī js-ipfs un tādi projekti-kādi piemēri kā orbit-db, uz kuru pamata strādā orbit.chat. Tātad teorētiski katrs ierīce (mobilā un ne tikai) var viegli tikt aprīkota ar savām šifrēšanas-dešifrēšanas mašīnām. Šajā gadījumā katram jāparūpējas par savu privāto taustiņu glabāšanu, un katrs pats būs atbildīgs par savu drošību, nevis jābūt ķ hostage jebkuras cilvēku kļūdas dēļ kādā no super populāriem interneta gigantiem.

Tikai reģistrētie lietotāji var piedalīties aptaujā. Pieteikties, lūdzu.

Vai esat iepriekš dzirdējuši par IPFS?

Nekad neesmu dzirdējis par IPFS, bet izklausās interesanti.
Nekad neesmu dzirdējis un nevēlos dzirdēt.
Esmu dzirdējis, bet tas mani neinteresēja.
Esmu dzirdējis, bet nesapratu, bet tagad izklausās interesanti.
Jau ilgāku laiku aktīvi izmantoju IPFS.

69 lietotāji nobalsoja. 13 lietotāji atturējās.

Avots: habr.com