IPFS sen doloro (sed ĉi tio ne estas preciza)

Malgraŭ tio, ke Habré jam estis pli ol unu artikolo pri IPFS.

Mi tuj klarigos, ke mi ne estas fakulo pri ĉi tiu areo, sed mi montris intereson pri ĉi tiu teknologio pli ol unufoje, sed provi ludi kun ĝi ofte kaŭzis iom da doloro. Hodiaŭ mi komencis eksperimenti denove kaj ricevis kelkajn rezultojn, kiujn mi ŝatus dividi. Resume, la instalado de IPFS kaj iuj funkcioj estos priskribitaj (ĉio estis farita en ubuntu, mi ne provis ĝin sur aliaj platformoj).

Se vi maltrafis kio estas IPFS, ĝi estas skribita iom detale ĉi tie: habr.com/en/post/314768

fikso

Por la pureco de la eksperimento, mi sugestas tuj instali ĝin sur iu ekstera servilo, ĉar ni konsideros iujn malfacilaĵojn kun laborado en loka kaj fora. Tiam, se oni volas, ĝi ne estos malkonstruita dum longa tempo, estas ne multe.

Instalu iru

Oficiala dokumentaro
Vidu la nunan version ĉe golang.org/dl

Noto: estas pli bone instali IPFS nome de la uzanto, kiu supozeble uzas ĝin plej ofte. La fakto estas, ke ĉi-sube ni konsideros la eblon munti per FUSO kaj estas subtilecoj.

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

Tiam vi devas ĝisdatigi la medion (pli da detaloj ĉi tie: 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

Kontroli ke iri estas instalita

go version

Instalu IPFS

Mi plej ŝatis la instalan metodon ipfs ĝisdatigo.

Instalu ĝin per la komando

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

Post tio, vi povas ruli la jenajn komandojn:

ipfs-ĝisdatigaj versioj - por vidi ĉiujn disponeblajn versiojn por elŝuti.
ipfs-ĝisdatigo versio - por vidi la nuntempe instalitan version (ĝis ni instalos IPFS, ĝi estos neniu).
ipfs-update instalu plej laste - instalu la lastan version de IPFS. Anstataŭ lasta, respektive, vi povas specifi ajnan deziratan version el la listo de disponeblaj.

Instalante ipfs

ipfs-update install latest

Kontrolante

ipfs --version

Rekte kun la instalado ĝenerale ĉio.

Komencu IPFS

Inicialigo

Unue vi devas fari inicialigon.

ipfs init

Responde, vi ricevos ion tian:

 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

Vi povas ruli la proponitan komandon

ipfs cat /ipfs/QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv/readme

rezulto

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

Ĉi tie, laŭ mi, komenciĝas la interesa. La uloj en la instala stadio jam komencas uzi siajn proprajn teknologiojn. La proponita hash QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv ne estas kreita specife por vi, sed kudrita en la eldonon. Tio estas, antaŭ la liberigo, ili preparis bonvenan tekston, verŝis ĝin en IPFS kaj aldonis la adreson al la instalilo. Mi pensas, ke ĝi estas tre mojosa. Kaj ĉi tiu dosiero (pli precize, la tuta dosierujo) nun videblas ne nur loke, sed ankaŭ ĉe la oficiala enirejo ipfs.io/ipfs/QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv. Samtempe, vi povas esti certa, ke la enhavo de la dosierujo neniel ŝanĝiĝis, ĉar se ĝi ŝanĝiĝus, tiam ankaŭ la haŝo ŝanĝiĝus.

Cetere, en ĉi tiu kazo, IPFS havas iujn similecojn kun la versio-kontrolservilo. Se vi faras ŝanĝojn al la fontdosieroj de la dosierujo kaj denove verŝas la dosierujon en IPFS, tiam ĝi ricevos novan adreson. Samtempe, la malnova dosierujo ne iros ien nur tiel kaj estos disponebla ĉe sia antaŭa adreso.

Rekta lanĉo

ipfs daemon

Vi devus ricevi respondon kiel ĉi tiu:

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

Malfermante la pordojn al la Interreto

Atentu ĉi tiujn du liniojn:

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

Nun, se vi instalis IPFS loke, tiam vi aliros IPFS-interfacojn ĉe lokaj adresoj kaj ĉio estos disponebla por vi (Ekzemple, localhost:5001/webui/). Sed instalite sur ekstera servilo, defaŭlte, la enirejoj estas fermitaj al la Interreto. Enirejoj du:

1. administranto de webui (GitHub) sur haveno 5001.
2. Ekstera API sur haveno 8080 (nurlega).

Ĝis nun, ambaŭ havenoj (5001 kaj 8080) povas esti malfermitaj por eksperimentoj, sed sur batalservilo, kompreneble, haveno 5001 devus esti fermita per fajroŝirmilo. Ekzistas ankaŭ haveno 4001, kiu estas bezonata por ke aliaj kunuloj povas trovi vin. Ĝi estu lasita malfermita al eksteraj petoj.

Malfermu ~/.ipfs/config por redaktado kaj trovu ĉi tiujn liniojn en ĝi:

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

Ŝanĝu 127.0.0.1 al la ip de via servilo kaj konservu la dosieron, poste rekomencu ipfs (ĉesigu la kurantan komandon per Ctrl+C kaj rekomencu ĝin).

Devus akiri

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

Nun la eksteraj interfacoj devus esti disponeblaj.

Kontrolu

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

La supra legu min dosiero devus malfermiĝi.

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

La retinterfaco devus malfermiĝi.

Se webui funkcias por vi, tiam la IPFS-agordoj povas esti ŝanĝitaj rekte en ĝi, inkluzive de vidado de statistikoj, sed sube mi konsideros agordajn opciojn rekte per la agorda dosiero, kiu ĝenerale ne estas kritika. Estas nur pli bone memori precize kie estas la agordo kaj kion fari kun ĝi, alie se la retvizaĝo ne funkcias, ĝi estos pli malfacila.

Agordante retan interfacon por labori kun via servilo

Jen la unua faŭlto, kiu daŭris ĉirkaŭ tri horojn.

Se vi instalis IPFS sur ekstera servilo, sed ne instalis aŭ funkciis IPFS loke, tiam kiam vi iras al /webui en la retinterfaco, vi devus vidi konektan eraron:

La fakto estas, ke webui, laŭ mi, funkcias tre ambigue. Unue, ĝi provas konekti al la API de la servilo kie la interfaco estas malfermita (surbaze de la adreso en la retumilo, kompreneble). kaj se ĝi ne funkcias tie, ĝi provas konektiĝi al la loka enirejo. Kaj se vi havas IPFS funkciantan loke, tiam webui funkcios bone por vi, nur vi laboros kun loka IPFS, kaj ne ekstera, kvankam vi malfermis webui sur ekstera servilo. Poste vi alŝutas la dosierojn, sed ial vi ne vidas ilin ĝuste tiel sur ekstera servilo...

Kaj se ĝi ne funkcias loke, tiam ni ricevas konektan eraron. En nia kazo, la eraro plej verŝajne estas pro CORS, kiu ankaŭ estas indikita per webui, sugestante aldoni agordon.

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"]'

Mi ĵus registris ĵokeron

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

La aldonitaj kaplinioj troviĝas en la sama ~/.ipfs/config. En mia kazo ĝi estas

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

Ni rekomencas ipfs kaj ni vidas, ke webui sukcese konektiĝis (ĉiaokaze, ĝi devus, se vi malfermis la enirejojn por petoj de ekstere, kiel priskribite supre).

Nun vi povas alŝuti dosierujojn kaj dosierojn rekte per la retinterfaco, kaj ankaŭ krei viajn proprajn dosierujojn.

Muntante la dosiersistemon FUSE

Jen sufiĉe interesa trajto.

Dosieroj (same kiel dosierujoj), ni povas aldoni ne nur per la retinterfaco, sed ankaŭ rekte en la terminalo, ekzemple

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

La lasta hash estas la hash de la radika dosierujo.

Uzante ĉi tiun hash, ni povas malfermi dosierujon sur iu ipfs-nodo (kiu povas trovi nian nodon kaj akiri la enhavon), ni povas en la retinterfaco sur haveno 5001 aŭ 8080, aŭ ni povas loke per ipfs.

ipfs ls QmbnzgRVAP4fL814h5mQttyqk1aUxxxxxxxxxxxxx
QmfYuz2gegRZNkDUDVLNa5DXzKmKVxxxxxxxxxxxxxx 10 test.txt

Sed vi ankoraŭ povas malfermi ĝin kiel regula dosierujo.

Ni kreu du dosierujojn ĉe la radiko kaj donu rajtojn al ili al nia uzanto.

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

kaj rekomencu ipfs per --mount flago

ipfs daemon --mount

Vi povas krei dosierujojn en aliaj lokoj kaj specifi la vojon al ili per la parametroj de demono ipfs -mount -mount-ipfs /ipfs_path -mount-ipns /ipns_path

Nun legado el ĉi tiu dosierujo estas iom nekutima.

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

Tio estas, ne ekzistas rekta aliro al la radiko de ĉi tiu dosierujo. Sed vi povas akiri la enhavon, konante la haŝiŝon.

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

Samtempe, eĉ aŭtomata kompletigo funkcias ene de la dosierujo kiam la vojo estas specifita.

Kiel mi diris supre, estas subtilecoj kun tia muntado: defaŭlte, muntitaj FUSE-dosierujoj estas disponeblaj nur por la nuna uzanto (eĉ root ne povos legi el tia dosierujo, sen mencii aliajn uzantojn en la sistemo). Se vi volas disponigi ĉi tiujn dosierujojn al aliaj uzantoj, tiam en la agordo vi devas ŝanĝi "FuseAllowOther": false al "FuseAllowOther": true. Sed tio ne estas ĉio. Se vi rulas IPFS kiel radiko, tiam ĉio estas en ordo. Kaj se nome de kutima uzanto (eĉ sudo), tiam vi ricevos eraron

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

En ĉi tiu kazo, vi devas redakti /etc/fuse.conf malkomentante la #user_allow_other linion.

Post tio, rekomencu ipfs.

Konataj problemoj kun FUSE

La problemo estis rimarkita pli ol unufoje, ke post rekomenco de ipfs kun muntado (kaj eble en aliaj kazoj), la /ipfs kaj /ipns-muntpunktoj fariĝas neatingeblaj. Ne estas aliro al ili, kaj ls -la /ipfs montras ???? en la listo de rajtoj.

Trovis ĉi tiun solvon:

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

Tiam rekomencu ipfs.

Aldono de Servo

Kompreneble, funkcii en la terminalo taŭgas nur por komencaj provoj. En batalreĝimo, la demono devus komenci aŭtomate ĉe la starto de la sistemo.

Nome de sudo, kreu la dosieron /etc/systemd/system/ipfs.service kaj skribu al ĝi:

[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, kompreneble, devas esti anstataŭigita per via uzanto (kaj eble la plena vojo al la ipfs-programo estos malsama por vi (vi devas specifi la plenan vojon)).

Ni aktivigas la servon.

sudo systemctl enable ipfs.service

Ni komencas la servon.

sudo service ipfs start

Kontrolante la staton de la servo.

sudo service ipfs status

Por la pureco de la eksperimento, estonte eblos rekomenci la servilon por kontroli, ke ipfs startas sukcese aŭtomate.

Aldonante konatajn al ni festenojn

Konsideru situacion, kie ni havas IPFS-nodojn instalitajn kaj sur ekstera servilo kaj loke. Sur ekstera servilo, ni aldonas iun dosieron kaj provas akiri ĝin per IPFS loke per CID. Kio okazos? Kompreneble, la loka servilo plej verŝajne nenion scias pri nia ekstera servilo kaj simple provos trovi la dosieron per CID "petante" ĉiujn IPFS-kunulojn disponeblajn al ĝi (kun kiuj ĝi jam sukcesis "konatiĝi"). Tiuj siavice demandos aliajn. Kaj tiel plu, ĝis la dosiero estas trovita. Efektive, la sama afero okazas kiam ni provas ricevi la dosieron tra la oficiala enirejo ipfs.io. Se vi bonŝancas, la dosiero estos trovita post kelkaj sekundoj. Kaj se ne, ĝi ne trovos eĉ post kelkaj minutoj, kio multe influas la komforton de laboro. Sed ni scias kie ĉi tiu dosiero unue aperos. Do kial ni ne tuj diras al nia loka servilo "Serĉu tie unue"? Ŝajne, ĉi tio povas esti farita.

1. Ni iras al la fora servilo kaj rigardas en la ~/.ipfs/config agordo

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

2. Rulu sudo-servo ipfs-statuson kaj serĉu Swarm-enskribojn en ĝi, ekzemple:

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

3. Ni aldonas el tio la ĝeneralan adreson de la formo "/ip4/ip_via_servilo/tcp/4001/ipfs/$PeerID".

4. Por fidindeco, ni provos aldoni ĉi tiun adreson al samuloj per nia loka webui.

5. Se ĉio estas en ordo, malfermu la lokan agordon ~ / .ipfs / config, trovu "Bootstrap" en ĝi: [...
kaj aldonu la ricevitan adreson unue al la tabelo.

Rekomencu IPFS.

Nun ni aldonu la dosieron al la ekstera servilo kaj provu peti ĝin sur la loka. Devus flugi rapide.

Sed ĉi tiu funkcio ankoraŭ ne estas stabila. Laŭ mia kompreno, eĉ se ni specifas la adreson de samulo en Bootstrap, ipfs ŝanĝas la liston de aktivaj konektoj kun samuloj dum operacio. Ĉiukaze, la diskuto pri tio kaj deziroj koncerne la eblon precizigi konstantajn festenojn estas survoje tie kaj ŝajnas kiel supozis aldoni kelkajn funkciojn al [retpoŝte protektita]+

La listo de nunaj kunuloj videblas kaj en la webui kaj en la terminalo.

ipfs swarm peers

Kaj jen kaj jen vi povas aldoni vian festenon permane.

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

Ĝis ĉi tiu funkcio estos plibonigita, vi povas skribi ilon por kontroli konekton al la dezirata kunulo kaj, se ne, aldoni konekton.

Rezonado

Inter tiuj, kiuj jam konas IPFS, ekzistas ambaŭ argumentoj por kaj kontraŭ IPFS. Esence, hieraŭ diskuto kaj instigis min denove fosi en IPFS. Kaj koncerne la supre menciitan diskuton: mi ne povas diri, ke mi forte kontraŭas ajnan argumenton de tiuj, kiuj parolis (mi malkonsentas nur pri tio, ke unu kaj duono programistoj uzas IPFS). Ĝenerale, ambaŭ pravas laŭ sia propra maniero (precipe komento pri ĉekoj pensigas vin). Sed se ni forĵetas la moralan kaj leĝan takson, kiu donos teknikan takson de ĉi tiu teknologio? Persone, mi havas ian internan senton, ke "ĉi tio devas esti farita sendube, ĝi havas certajn perspektivojn." Sed kial ĝuste, ne ekzistas klara formuliĝo. Kiel, se vi rigardas la ekzistantajn centralizitajn ilojn, tiam en multaj rilatoj ili estas malproksime antaŭen (stabileco, rapideco, mastreblo, ktp.). Tamen mi havas unu penson, kiu ŝajnas havi sencon kaj kiu apenaŭ povas esti efektivigita sen tiaj malcentralizitaj sistemoj. Kompreneble, mi svingiĝas tro forte, sed mi formulus ĝin jene: la principo de disvastigo de informoj en Interreto devas esti ŝanĝita.

Lasu min klarigi. Se vi pensas pri tio, nun ni havas informojn distribuitajn laŭ la principo "Mi esperas, ke tiu, al kiu mi donis ĝin, protektos ĝin kaj ĝi ne estos perdita aŭ ricevata de tiuj, al kiuj ĝi ne estis destinita." Ekzemple, estas facile konsideri diversajn poŝtservojn, nubajn stokaĵojn, ktp. Kaj per kio ni finas? Sur Habré-nabo Informa Sekureco estas sur la unua linio kaj preskaŭ ĉiutage ni ricevas novaĵojn pri alia tutmonda liko. Principe ĉiuj plej interesaj aferoj estas listigitaj en <ironio> mirinda artikolo Somero preskaŭ finiĝis. Preskaŭ ne restas nefluitaj datumoj. Tio estas, la ĉefaj interretaj gigantoj pligrandiĝas, ili amasigas pli kaj pli da informoj, kaj tiaj likoj estas speco de informaj atomeksplodoj. Ĉi tio neniam okazis antaŭe, kaj jen ĝi denove. Samtempe, kvankam multaj komprenas, ke ekzistas riskoj, ili daŭre konfidos siajn datumojn al triaj kompanioj. Unue, ne ekzistas multe da alternativo, kaj due, ili promesas, ke ili flikis ĉiujn truojn kaj ĉi tio neniam plu okazos.

Kian opcion mi vidas? Ŝajnas al mi, ke datumoj komence devas esti distribuitaj malkaŝe. Sed malfermiteco ĉi-kaze ne signifas, ke ĉio estu facile legebla. Mi parolas pri la malfermo de stokado kaj distribuo, sed ne totala malfermiteco en legado. Mi supozas, ke tiu informo estu distribuata per publikaj ŝlosiloj. Post ĉio, la principo de publikaj / privataj ŝlosiloj jam estas malnova, preskaŭ kiel interreto. Se la informoj ne estas konfidencaj kaj estas destinitaj al larĝa rondo, tiam ĝi estas aranĝita tuj per publika ŝlosilo (sed ankoraŭ en ĉifrita formo, ĉiu povas malĉifri ĝin per la disponebla ŝlosilo). Kaj se ne, tiam ĝi estas aranĝita sen publika ŝlosilo, kaj la ŝlosilo mem estas transdonita al tio, kio devus havi aliron al ĉi tiu informo. Samtempe, tiu, kiu legu ĝin, havu nur ŝlosilon, kaj kie akiri ĉi tiun informon, li ne vere ŝvebu - li nur tiras ĝin el la reto (jen la nova principo de dissendo laŭ enhavo, ne per adreso).

Tiel, por amasa atako, atakantoj devos akiri grandegan nombron da privataj ŝlosiloj, kaj ĉi tio verŝajne ne estos farita en unu loko. Ĉi tiu tasko, kiel mi vidas ĝin, estas pli malfacila ol haki apartan servon.

Kaj ĉi tie fermiĝas alia problemo: konfirmo de aŭtoreco. Nun en la interreto vi povas trovi multajn citaĵojn skribitajn de niaj amikoj. Sed kie estas la garantio, ke estis ili, kiuj skribis ilin? Nun, se ĉiu tia rekordo estus akompanata de cifereca subskribo, ĝi estus multe pli facila. Kaj ne gravas, kie ĉi tiu informo kuŝas, la ĉefa afero estas la subskribo, kiu, kompreneble, malfacilas forĝi.

Kaj jen kio estas interesa ĉi tie: IPFS jam portas ĉifradajn ilojn (post ĉio, ĝi estas konstruita sur blokĉena teknologio). La privata ŝlosilo estas tuj specifita en la agordo.

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

Mi ne estas sekurecspecialisto kaj ne povas scii ĝuste kiel uzi ĝin ĝuste, sed ŝajnas al mi, ke ĉi tiuj ŝlosiloj estas uzataj je la nivelo de interŝanĝo inter IPFS-nodoj. Kaj ankaŭ js-ipfs kaj ekzemploprojektoj kiel ekz orbito-dbsur kiu ĝi funkcias orbito.babili. Tio estas, teorie, ĉiu aparato (poŝtelefona kaj ne nur) povas esti facile ekipita per siaj propraj ĉifrad-malĉifraj maŝinoj. En ĉi tiu kazo, restas nur por ĉiuj zorgi pri konservi siajn privatajn ŝlosilojn, kaj ĉiu respondecos pri sia propra sekureco, kaj ne estos ostaĝo de alia homa faktoro sur iu super-populara Interreta giganto.

Nur registritaj uzantoj povas partopreni la enketon. Ensaluti, bonvolu.

Ĉu vi antaŭe aŭdis pri IPFS?

• Mi neniam aŭdis pri IPFS, sed ĝi ŝajnas interesa

• Ne aŭdis kaj ne volas aŭdi

• Aŭdis sed ne interesiĝas

• Aŭdis, sed ne komprenis, sed nun ĝi ŝajnas interesa

• Mi aktive uzas IPFS dum longa tempo.

69 uzantoj voĉdonis. 13 uzantoj sindetenis.

fonto: www.habr.com