IPFS ilma valuta (kuid see pole täpne)

IPFS ilma valuta (kuid see pole täpne)

Vaatamata sellele, et Habré juba oli rohkem kui üks artikkel IPFS-i kohta.

Täpsustan kohe, et ma ei ole selles vallas asjatundja, kuid olen selle tehnoloogia vastu huvi tundnud rohkem kui korra, kuid sellega mängimine tekitas sageli valu. Täna hakkasin uuesti katsetama ja sain mõned tulemused, mida tahaksin jagada. Lühidalt kirjeldatakse IPFS-i installiprotsessi ja mõningaid funktsioone (kõik sai tehtud ubuntu peal, teistel platvormidel pole proovinud).

Kui jäite tähelepanuta, mis on IPFS, on see siin üksikasjalikult kirjas: habr.com/en/post/314768

Paigaldamine

Katse puhtuse huvides soovitan see kohe installida mõnda välisserverisse, kuna arvestame kohalikus režiimis ja kaugjuhtimisega töötamise mõningaid lõkse. Siis soovi korral kaua ei lammuta, vähe on.

Install go

Ametlik dokumentatsioon
Vaadake praegust versiooni aadressil golang.org/dl

Märkus: IPFS on parem installida selle kasutaja nimel, kes peaks seda kõige sagedamini kasutama. Fakt on see, et allpool käsitleme läbi paigaldamise võimalust 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 keskkonda uuendada (täpsemalt 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

Kontrollige, kas go on installitud

go version

Installige IPFS

Mulle meeldis kõige rohkem paigaldusmeetod ipfsi värskendus.

Installige see käsuga

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

Pärast seda saate käivitada järgmised käsud:

ipfs-update versioonid - et näha kõiki allalaadimiseks saadaolevaid versioone.
ipfs-uuenduse versioon - praegu installitud versiooni vaatamiseks (kuni IPFS-i pole installitud, pole seda installitud).
ipfs-update install uusim - installige IPFS-i uusim versioon. Vastavalt uusima versiooni asemel saate saadaolevate versioonide loendist määrata mis tahes soovitud versiooni.

IPfs-i installimine

ipfs-update install latest

Kontrollige

ipfs --version

Otse paigaldusega üldiselt kõike.

Käivitage IPFS

Initsialiseerimine

Kõigepealt peate läbi viima lähtestamise.

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

Hello and Welcome to IPFS!

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

If you're seeing this, you have successfully installed
IPFS and are now interfacing with the ipfs merkledag!

 -------------------------------------------------------
| Warning:                                              |
|   This is alpha software. Use at your own discretion! |
|   Much is missing or lacking polish. There are bugs.  |
|   Not yet secure. Read the security notes for more.   |
 -------------------------------------------------------

Check out some of the other files in this directory:

  ./about
  ./help
  ./quick-start     <-- usage examples
  ./readme          <-- this file
  ./security-notes

Siit algab minu arvates huvitav. Paigaldamise etapis olevad poisid hakkavad juba oma tehnoloogiaid kasutama. Pakutud räsi QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv ei ole spetsiaalselt teie jaoks loodud, vaid väljalasesse õmmeldud. See tähendab, et enne väljalaskmist koostasid nad tervitusteksti, valasid selle IPFS-i ja lisasid installijale aadressi. Minu meelest on see väga lahe. Ja seda faili (täpsemalt kogu kausta) saab nüüd vaadata mitte ainult kohapeal, vaid ka ametlikus lüüsis ipfs.io/ipfs/QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv. Samas võid kindel olla, et kausta sisu pole kuidagi muutunud, sest kui see oleks muutunud, siis oleks muutunud ka räsi.

Muide, antud juhul on IPFS-il mõningaid sarnasusi versioonihaldusserveriga. Kui muudate kausta lähtefaile ja valate kausta uuesti IPFS-i, saab see uue aadressi. Samas ei kao vana kaust niisama kuhugi ja on saadaval oma eelmisel aadressil.

Otsene käivitamine

ipfs daemon

Peaksite saama sellise vastuse:

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

Uste avamine Internetile

Pöörake tähelepanu nendele kahele reale:

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

Nüüd, kui olete IPFS-i kohapeal installinud, pääsete IPFS-i liidestele juurde kohalike aadresside abil ja kõik on teile kättesaadav (näiteks localhost:5001/webui/). Kuid välisserverisse installimisel on lüüsid Internetti vaikimisi suletud. Kaks lüüsi:

  1. webui admin (github) pordis 5001.
  2. Väline API pordis 8080 (kirjutuskaitstud).

Seni saab katseteks avada mõlemad pordid (5001 ja 8080), kuid lahinguserveris tuleks muidugi port 5001 tulemüüriga kinni panna. Samuti on olemas port 4001, mis on vajalik selleks, et teised kaaslased teid üles leiaksid. See tuleks jätta avatuks välistele taotlustele.

Avage redigeerimiseks ~/.ipfs/config ja leidke sellest järgmised 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"
}

Muutke 127.0.0.1 oma serveri IP-ks ja salvestage fail, seejärel taaskäivitage ipfs (peatage töötav käsk klahvikombinatsiooniga Ctrl+C ja käivitage see uuesti).

Peaks saama

...
WebUI: http://ip_вашего_сервера:5001/webui
Gateway (readonly) server listening on /ip4/ip_вашего_сервера/tcp/8080

Nüüd peaksid välised liidesed olema saadaval.

Kontrollima

http://домен_или_ip_сервера:8080/ipfs/QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv/readme

Ülaltoodud readme fail peaks avanema.

http://домен_или_ip_сервера:5001/webui/

Veebiliides peaks avanema.

Kui webui teie jaoks töötab, saab IPFS-i sätteid selles otse muuta, sealhulgas statistikat vaadata, kuid allpool käsitlen konfiguratsioonivõimalusi otse konfiguratsioonifaili kaudu, mis üldiselt pole kriitiline. Parem on lihtsalt meeles pidada, kus konfiguratsioon täpselt asub ja mida sellega teha, muidu kui veebinägu ei tööta, on see keerulisem.

Veebiliidese seadistamine teie serveriga töötamiseks

Siin on esimene lõks, mis võttis aega umbes kolm tundi.

Kui installisite IPFS-i välisserverisse, kuid ei installinud ega käivitanud IPFS-i lokaalselt, peaksite veebiliideses /webui minnes nägema ühenduse viga:

IPFS ilma valuta (kuid see pole täpne)

Fakt on see, et webui töötab minu arvates väga mitmetähenduslikult. Esiteks proovib see luua ühenduse selle serveri API-ga, kus liides on avatud (muidugi brauseris oleva aadressi alusel). ja kui see seal ei tööta, siis proovib luua ühenduse kohaliku lüüsiga. Ja kui teie IPFS töötab kohapeal, töötab webui teie jaoks hästi, ainult teie töötate kohaliku IPFS-iga, mitte välise, kuigi avasite webui välises serveris. Seejärel laadite failid üles, kuid mingil põhjusel ei näe te neid välises serveris niisama…

Ja kui see ei tööta lokaalselt, saame ühenduse vea. Meie puhul on vea põhjuseks suure tõenäosusega CORS, millele viitab ka webui, soovitades konfiguratsiooni lisada.

ipfs config --json API.HTTPHeaders.Access-Control-Allow-Origin '["http://ip_вашего сервера:5001", "http://127.0.0.1:5001", "https://webui.ipfs.io"]'
ipfs config --json API.HTTPHeaders.Access-Control-Allow-Methods '["PUT", "GET", "POST"]'

Registreerisin just metamärgi

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

Lisatud päised leiate samast ~/.ipfs/config-st. Minu puhul on

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

Taaskäivitame ipfsi ja näeme, et webui on edukalt ühendatud (igal juhul peaks see olema, kui avasite lüüsid väljastpoolt tulevate päringute jaoks, nagu eespool kirjeldatud).

Nüüd saate kaustu ja faile otse veebiliidese kaudu üles laadida, samuti luua oma kaustu.

FUSE failisüsteemi paigaldamine

Siin on päris huvitav funktsioon.

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

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

Viimane räsi on juurkausta räsi.

Seda räsi kasutades saame avada kausta mis tahes ipfs-i sõlmes (mis võib leida meie sõlme ja saada sisu), saame seda teha veebiliideses pordil 5001 või 8080 või lokaalselt ipfs-i kaudu.

ipfs ls QmbnzgRVAP4fL814h5mQttyqk1aUxxxxxxxxxxxxx
QmfYuz2gegRZNkDUDVLNa5DXzKmKVxxxxxxxxxxxxxx 10 test.txt

Kuid saate selle ikkagi avada nagu tavalist kausta.

Loome juurusse kaks kausta ja anname oma kasutajale nende õigused.

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

ja taaskäivitage ipfs lipuga --mount

ipfs daemon --mount

Saate luua kaustu mujal ja määrata nende tee ipfs deemoni parameetrite kaudu -mount -mount-ipfs /ipfs_path -mount-ipns /ipns_path

Nüüd on sellest kaustast lugemine mõnevõrra ebatavaline.

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

See tähendab, et selle kausta juurtele pole otsest juurdepääsu. Aga sisu saab kätte, teades räsi.

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

Samal ajal töötab kausta sees isegi automaatne lõpetamine, kui tee on määratud.

Nagu ma eespool ütlesin, on sellisel paigaldamisel nüansse: vaikimisi on ühendatud FUSE-kaustad saadaval ainult praegusele kasutajale (isegi root ei saa sellisest kaustast lugeda, rääkimata teistest süsteemi kasutajatest). Kui soovite need kaustad teistele kasutajatele kättesaadavaks teha, peate konfiguratsioonis muutma "FuseAllowOther": false väärtuseks "FuseAllowOther": true. Kuid see pole veel kõik. Kui käivitate IPFS-i root kasutajana, on kõik korras. Ja kui tavakasutaja nimel (isegi sudo), siis saad veateate

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

Sel juhul peate faili /etc/fuse.conf redigeerima, eemaldades rea #user_allow_other kommentaarid.

Pärast seda taaskäivitage ipfs.

Teadaolevad probleemid FUSE-ga

Rohkem kui üks kord on märgatud probleemi, et pärast ipfsi taaskäivitamist koos paigaldamisega (ja võib-olla ka muudel juhtudel) muutuvad /ipfs ja /ipns ühenduspunktid kättesaamatuks. Neile pole juurdepääsu ja ls -la /ipfs näitab ???? õiguste nimekirjas.

Leidsin sellise lahenduse:

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

Seejärel taaskäivitage ipfs.

Teenuse lisamine

Mõistagi sobib terminalis jooksmine vaid esmaseks testimiseks. Võitlusrežiimis peaks deemon süsteemi käivitamisel automaatselt käivituma.

Looge sudo nimel fail /etc/systemd/system/ipfs.service ja kirjutage sellele:

[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 teie kasutajaga (ja võib-olla on ipfs-programmi täielik tee teie jaoks erinev (peate määrama täieliku tee)).

Aktiveerime teenuse.

sudo systemctl enable ipfs.service

Alustame teenust.

sudo service ipfs start

Teenuse oleku kontrollimine.

sudo service ipfs status

Katse puhtuse huvides on tulevikus võimalik serverit taaskäivitada, et kontrollida, kas ipfs käivitub automaatselt.

Meile tuntud pühade lisamine

Mõelge olukorrale, kus meil on IPFS-sõlmed installitud nii välisesse serverisse kui ka lokaalselt. Välises serveris lisame mõne faili ja proovime selle IPFS-i kaudu CID-i abil kohapeal hankida. Mis juhtub? Loomulikult ei tea kohalik server suure tõenäosusega meie välisserverist midagi ja püüab faili lihtsalt CID järgi leida, “küsib” kõigilt talle saadaolevatelt IPFS-i kaaslastelt (millega tal on juba õnnestunud “tutvuda”). Need omakorda küsivad teistelt. Ja nii edasi, kuni fail leitakse. Tegelikult juhtub sama asi, kui proovime faili ametliku lüüsi kaudu hankida ipfs.io. Kui veab, leitakse fail mõne sekundiga üles. Ja kui ei, siis ei leita seda isegi mõne minutiga, mis mõjutab oluliselt töö mugavust. Kuid me teame, kus see fail esmakordselt ilmub. Miks me siis ei ütle kohe oma kohalikule serverile "Otsi kõigepealt sealt"? Ilmselt saab seda teha.

1. Läheme kaugserverisse ja vaatame faili ~/.ipfs/config config

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

2. Käivitage sudo teenuse ipfs status ja otsige sellest Swarmi kirjeid, näiteks:

Swarm announcing /ip4/ip_вашего_сервера/tcp/4001

3. Lisame sellest vormi "/ip4/ip_your_server/tcp/4001/ipfs/$PeerID" üldaadressi.

4. Usaldusväärsuse huvides proovime selle aadressi oma kohaliku webui kaudu kaaslastele lisada.

IPFS ilma valuta (kuid see pole täpne)

5. Kui kõik on korras, avage kohalik config ~ / .ipfs / config, leidke sealt "Bootstrap": [...
ja lisage saadud aadress kõigepealt massiivi.

Taaskäivitage IPFS.

Nüüd lisame faili välisserverisse ja proovime seda kohalikus serveris taotleda. Peaks kiiresti lendama.

Kuid see funktsioon ei ole veel stabiilne. Niipalju kui ma aru saan, siis isegi kui me Bootstrapis määrame kaaslase aadressi, muudab ipfs töö ajal aktiivsete ühenduste loendit partneritega. Igatahes selle ja soovide arutelu püsipidustuste täpsustamise võimaluse osas käib siin ja tundub, et peaks lisage sellele mõni funktsionaalsus [meiliga kaitstud]+

Praeguste kaaslaste nimekirja saab vaadata nii webuis kui ka terminalis.

ipfs swarm peers

Ja siin-seal saate oma pidu käsitsi lisada.

ipfs swarm connect "/ip4/ip_вашего_сервера/tcp/4001/ipfs/$PeerID"

Kuni seda funktsionaalsust pole täiustatud, saate kirjutada tööriista, et kontrollida ühenduse olemasolu soovitud partneriga ja kui mitte, siis ühenduse lisamiseks.

Põhjendamine

IPFS-iga juba tuttavate seas on nii IPFS-i poolt- kui ka vastuargumente. Põhimõtteliselt eile arutelu ja ajendas mind uuesti IPFS-i uurima. Ja mis puudutab ülalmainitud arutelu: ma ei saa öelda, et oleksin kindlalt vastu ühelegi sõnavõtjate argumendile (ei nõustu ainult sellega, et poolteist programmeerijat kasutab IPFS-i). Üldiselt on mõlemal omal moel õigus (eriti kommentaar tšekkide kohta paneb mõtlema). Aga kui me loobume moraalsest ja juriidilisest hinnangust, siis kes annab sellele tehnoloogiale tehnilise hinnangu? Minul isiklikult on mingisugune sisetunne, et "seda tuleb teha ühemõtteliselt, sellel on teatud väljavaated". Aga miks täpselt, selget sõnastust pole. Nagu, kui vaadata olemasolevaid tsentraliseeritud tööriistu, siis on need paljuski ees (stabiilsus, kiirus, juhitavus jne). Sellegipoolest on mul üks mõte, mis tundub olevat mõttekas ja mida ilma selliste detsentraliseeritud süsteemideta on vaevalt võimalik rakendada. Muidugi kiikun liiga kõvasti, aga sõnastaksin selle nii: internetis info levitamise põhimõtet tuleb muuta.

Las ma seletan. Kui järele mõelda, siis nüüd on meil infot jaotatud põhimõttel "Loodan, et see, kellele ma selle andsin, kaitseb seda ja see ei lähe kaduma ega lähe kätte nende poolt, kellele see pole mõeldud." Näitena on lihtne kaaluda erinevaid postiteenuseid, pilvesalvestusi jne. Ja millega me lõpuks jõuame? Habré keskuses Infoturbe on esimesel real ja peaaegu iga päev saame uudiseid järjekordse globaalse lekke kohta. Põhimõtteliselt on kõik huvitavamad asjad kirjas <iroonia> imeline artiklit Suvi on peaaegu läbi. Lekkimata andmeid pole peaaegu üldse alles. See tähendab, et peamised Interneti-hiiglased muutuvad suuremaks, nad koguvad üha rohkem teavet ja sellised lekked on omamoodi teabe aatomiplahvatused. Seda pole kunagi varem juhtunud ja siin see on jälle. Samal ajal, kuigi paljud mõistavad riskide olemasolu, usaldavad nad jätkuvalt oma andmeid kolmandate osapoolte ettevõtete kätte. Esiteks pole palju alternatiivi ja teiseks lubavad nad, et on kõik augud lappinud ja seda enam kunagi ei juhtu.

Millist varianti ma näen? Mulle tundub, et andmeid tuleks esialgu levitada avalikult. Kuid avatus ei tähenda antud juhul, et kõik peaks olema lihtsalt loetav. Ma räägin talletamise ja levitamise avatusest, kuid mitte lugemise täielikust avatusest. Eeldan, et infot tuleks levitada avalike võtmetega. Lõppude lõpuks on avalike / privaatvõtmete põhimõte juba vana, peaaegu nagu Internet. Kui teave ei ole konfidentsiaalne ja on mõeldud laiale ringile, siis paigutatakse see kohe avaliku võtmega (kuid siiski krüpteeritud kujul, lihtsalt igaüks saab selle olemasoleva võtmega dekrüpteerida). Ja kui ei, siis pannakse see ilma avaliku võtmeta ja võti ise kantakse üle sellele, millel peaks sellele teabele juurdepääs olema. Samal ajal peaks sellel, kes seda lugema peaks, olema ainult võti ja kust seda teavet saada, ei tohiks ta tegelikult tõusta - ta tõmbab selle lihtsalt võrgust välja (see on uus sisu ja mitte levitamise põhimõte aadress).

Seega peavad ründajad massirünnaku jaoks hankima tohutul hulgal privaatvõtmeid ja tõenäoliselt ei tehta seda ühes kohas. Minu arvates on see ülesanne keerulisem kui konkreetse teenuse häkkimine.

Ja siin on suletud veel üks probleem: autorsuse kinnitamine. Nüüd leiate Internetist palju meie sõprade kirjutatud tsitaate. Aga kus on garantii, et just nemad need kirjutasid? Nüüd, kui iga sellise kirjega kaasneks digiallkiri, oleks see palju lihtsam. Ja pole vahet, kus see teave asub, peamine on allkiri, mida on muidugi raske võltsida.

Ja siin on huvitav: IPFS kannab juba krüpteerimistööriistu (see on ju ehitatud plokiahela tehnoloogiale). Privaatvõti määratakse kohe konfiguratsioonis.

  "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 turbespetsialist ega tea täpselt, kuidas seda õigesti kasutada, kuid mulle tundub, et neid võtmeid kasutatakse IPFS-i sõlmede vahelise vahetuse tasemel. Ja ka js-ipfs ja näidisprojektid nagu orbiit-dbmillel see töötab orbiit.vestlus. See tähendab, et teoreetiliselt saab iga seade (mobiilne ja mitte ainult) hõlpsasti varustada oma krüpteerimis-dekrüpteerimismasinatega. Sel juhul jääb igaühe enda kanda oma privaatvõtmete salvestamine ja igaüks vastutab oma turvalisuse eest ise, mitte ei saa olla mõne ülipopulaarse Interneti-hiiglase järjekordse inimfaktori pantvangis.

Küsitluses saavad osaleda ainult registreerunud kasutajad. Logi sissepalun.

Kas olete IPFS-ist varem kuulnud?

  • Ma pole kunagi IPFS-ist kuulnud, kuid see tundub huvitav

  • Ei ole kuulnud ja ei taha kuulda

  • Kuulnud, aga pole huvitatud

  • Kuulnud, aga aru ei saanud, aga nüüd tundub huvitav

  • Olen IPFS-i aktiivselt kasutanud pikka aega.

69 kasutajat hääletas. 13 kasutajat jäi erapooletuks.

Allikas: www.habr.com

Lisa kommentaar