🥇IPFS fájdalom nélkül (de ez nem biztos)

Annak ellenére, hogy Habré már az volt egynél több cikk az IPFS-ről.

Mindjárt leszögezem, hogy nem vagyok szakértő ezen a területen, de nem egyszer érdeklődtem ez iránt a technológia iránt, de sokszor okozott némi fájdalmat a vele való játszadozás. Ma újra elkezdtem kísérletezni, és olyan eredményeket kaptam, amelyeket szeretnék megosztani. Röviden leírom az IPFS telepítési folyamatát és néhány szolgáltatást (ubuntu-n minden megtörtént, más platformon nem próbáltam).

Ha kihagytad, mi az az IPFS, itt le van írva részletesen: habr.com/en/post/314768

Telepítés

A kísérlet tisztasága érdekében azt javaslom, hogy azonnal telepítse valamilyen külső szerverre, mivel figyelembe vesszük néhány buktatót a helyi módban és távolról történő munkavégzés során. Aztán, ha kívánják, sokáig nem bontják, nincs sok.

Install go

Hivatalos dokumentáció
Az aktuális verzióhoz lásd golang.org/dl

Megjegyzés: jobb, ha az IPFS-t annak a felhasználónak a nevében telepíti, aki azt leggyakrabban használja. Az a tény, hogy az alábbiakban megvizsgáljuk a szerelési lehetőséget FUSE és vannak finomságok.

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

Ezután frissítenie kell a környezetet (további részletek itt: 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

Ellenőrizze, hogy a go telepítve van-e

go version

Telepítse az IPFS-t

A telepítési mód tetszett a legjobban: ipfs-frissítés.

Telepítse a paranccsal

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

Ezt követően a következő parancsokat futtathatja:

ipfs-update verziók - az összes letölthető verzió megtekintéséhez.
ipfs-update verzió — az aktuális telepített verzió megtekintéséhez (amíg nem telepítjük az IPFS-t, addig nem lesz).
Az ipfs-update legújabb telepítése - telepítse az IPFS legújabb verzióját. A legfrissebb helyett bármelyik kívánt verziót megadhatja az elérhetők listájából.

ipfs telepítése

ipfs-update install latest

Ellenőrzés

ipfs --version

Közvetlenül a telepítéssel általában mindent.

Indítsa el az IPFS-t

Inicializálás

Először inicializálást kell végrehajtania.

ipfs init

Válaszul valami ilyesmit fog kapni:

 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

Futtathatja a javasolt parancsot

ipfs cat /ipfs/QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv/readme

Eredmény

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

Véleményem szerint itt kezdődik az érdekes. A telepítési szakaszban lévő srácok már elkezdik használni a saját technológiáikat. A javasolt QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv hash nem kifejezetten az Ön számára készült, hanem bele van varrva a kiadásba. Vagyis a megjelenés előtt elkészítettek egy üdvözlő szöveget, beöntötték az IPFS-be, és hozzáadták a címet a telepítőhöz. Szerintem nagyon klassz. Ez a fájl (pontosabban a teljes mappa) pedig már nem csak helyben, hanem a hivatalos átjárón is megtekinthető ipfs.io/ipfs/QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv. Ugyanakkor biztos lehet benne, hogy a mappa tartalma semmiben sem változott, mert ha változott volna, akkor a hash is megváltozott volna.

Mellesleg, ebben az esetben az IPFS-nek van némi hasonlósága a verzióvezérlő szerverrel. Ha módosítja a mappa forrásfájljait, és újra feltölti az IPFS-be, akkor az új címet kap. Ugyanakkor a régi mappa nem megy sehova csak úgy, és a korábbi címén lesz elérhető.

Közvetlen indítás

ipfs daemon

Ilyen választ kellene kapnod:

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

Az internet kapujának megnyitása

Ügyeljen erre a két sorra:

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

Most, ha az IPFS-t helyileg telepítette, akkor helyi címekkel fog hozzáférni az IPFS-interfészekhez, és minden elérhető lesz az Ön számára (például localhost:5001/webui/). De ha külső szerverre telepíti, az átjárók alapértelmezés szerint zárva vannak az internet felé. Két átjáró:

webui admin (GitHub) az 5001-es porton.
Külső API a 8080-as porton (csak olvasható).

Egyelőre mindkét port (5001-es és 8080-as) nyitható kísérletekhez, de éles szerveren természetesen az 5001-es portot kellene tűzfallal lezárni. Van a 4001-es port is, arra van szükség, hogy a többi társ megtalálhassa. Nyitva kell hagyni a külső kérések előtt.

Nyissa meg a ~/.ipfs/config fájlt szerkesztéshez, és keresse meg benne a következő sorokat:

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

Módosítsa a 127.0.0.1-et a szerver IP-jére, mentse a fájlt, majd indítsa újra az ipfs-t (a Ctrl+C billentyűkombinációval állítsa le a futó parancsot, és indítsa újra).

Meg kellene szerezni

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

Most már elérhetővé kell tenni a külső interfészeket.

Jelölje be

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

A fenti readme fájlnak meg kell nyílnia.

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

A webes felületnek meg kell nyílnia.

Ha a webui működik az Ön számára, akkor az IPFS beállításai közvetlenül módosíthatók benne, beleértve a statisztikák megtekintését is, de az alábbiakban a konfigurációs lehetőségeket közvetlenül a konfigurációs fájlon keresztül vizsgálom, ami általában nem kritikus. Csak jobb, ha pontosan megjegyzi, hol van a konfig és mit kell vele csinálni, különben ha a weblap nem működik, akkor nehezebb lesz.

Webes felület beállítása a szerverrel való együttműködéshez

Íme az első buktató, amelyen három órát töltöttek.

Ha az IPFS-t külső kiszolgálóra telepítette, de nem telepítette vagy futtatta helyileg az IPFS-t, akkor a webes felületen a /webui megnyitásakor kapcsolódási hibaüzenetet kell látnia:

Az a helyzet, hogy a webui véleményem szerint nagyon másképp működik. Először annak a szervernek az API-jához próbál csatlakozni, ahol az interfész nyitva van (természetesen a böngészőben lévő cím alapján). és ha ott nem működik, akkor megpróbál csatlakozni a helyi átjáróhoz. És ha az IPFS helyileg fut, akkor a webui jól fog működni, csak te fogsz helyi IPFS-sel dolgozni, és nem külső, bár a webui-t külső szerveren nyitottad meg. Ezután feltölti a fájlokat, de valamiért nem csak a külső szerveren látja őket...

És ha nem indul el helyben, akkor kapunk egy kapcsolati hibát. Esetünkben a hiba nagy valószínűséggel a CORS miatt van, amit a webui is jelez, ami konfig hozzáadását javasolja.

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

Most regisztráltam egy helyettesítő karaktert

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

A hozzáadott fejlécek ugyanabban a ~/.ipfs/config fájlban találhatók. Az én esetemben az

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

Újraindítjuk az ipfs-t, és azt látjuk, hogy a webui sikeresen csatlakozott (mindenesetre meg kell tennie, ha megnyitotta az átjárókat a kívülről érkező kérések számára, a fent leírtak szerint).

Mostantól közvetlenül a webes felületen keresztül tölthet fel mappákat és fájlokat, valamint létrehozhat saját mappákat.

A FUSE fájlrendszer csatlakoztatása

Itt van egy nagyon érdekes funkció.

Fájlokat (és mappákat) nem csak a webes felületen, hanem közvetlenül a terminálon is hozzáadhatunk, pl.

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

Az utolsó kivonat a gyökérmappa hash-je.

Ezt a hash-t használva bármelyik ipfs csomóponton megnyithatjuk a mappát (ami meg tudja találni a csomópontunkat és fogadja a tartalmat), megtehetjük ezt a webes felületen az 5001-es vagy 8080-as porton, vagy megtehetjük lokálisan ipfs-en keresztül.

ipfs ls QmbnzgRVAP4fL814h5mQttyqk1aUxxxxxxxxxxxxx
QmfYuz2gegRZNkDUDVLNa5DXzKmKVxxxxxxxxxxxxxx 10 test.txt

De megnyithatja úgy is, mint egy normál mappát.

Hozzunk létre két mappát a gyökérben, és biztosítsunk hozzájuk jogokat a felhasználónknak.

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

és indítsa újra az ipfs-t a --mount kapcsolóval

ipfs daemon --mount

Más helyeken is létrehozhat mappákat, és megadhatja azok elérési útját az ipfs démon paraméterekkel -mount -mount-ipfs /ipfs_path -mount-ipns /ipns_path

Most ebből a mappából olvasni kissé szokatlan.

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

Vagyis ennek a mappának nincs közvetlen hozzáférése a gyökérkönyvtárhoz. De a tartalmat a hash ismeretében megkaphatja.

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

Ugyanakkor még az automatikus kiegészítés is működik a mappán belül, ha az elérési út meg van adva.

Ahogy fentebb is mondtam, az ilyen rögzítésnek vannak finomságai: alapértelmezés szerint a csatlakoztatott FUSE mappák csak az aktuális felhasználó számára érhetők el (még a root sem tud olvasni egy ilyen mappából, nem beszélve a rendszer többi felhasználójáról) . Ha ezeket a mappákat más felhasználók számára is elérhetővé szeretné tenni, akkor a konfigurációban módosítania kell a „FuseAllowOther”: false értéket „FuseAllowOther”: true értékre. De ez még nem minden. Ha az IPFS-t rootként futtatod, akkor minden rendben van. És ha egy normál felhasználó nevében (akár sudo), akkor hibaüzenetet kap

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

Ebben az esetben szerkesztenie kell az /etc/fuse.conf fájlt a #user_allow_other sor megjegyzésének törlésével.

Ezután indítsa újra az ipfs-t.

Ismert problémák a FUSE-val

Nemegyszer észlelték már azt a problémát, hogy az ipfs újraindítása után (és talán más esetekben) az /ipfs és /ipns csatolási pontok elérhetetlenné válnak. Nincs hozzáférésük hozzájuk, és az ls -la /ipfs megjeleníti a ???? a jogok listájában.

Ezt a megoldást találtam:

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

Ezután indítsa újra az ipfs-t.

Szolgáltatás hozzáadása

Természetesen a terminálban való futás csak a kezdeti tesztekre alkalmas. Harci módban a démonnak automatikusan el kell indulnia a rendszer indításakor.

A sudo nevében hozza létre az /etc/systemd/system/ipfs.service fájlt, és írja be:

[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

A FELHASZNÁLÓNÉV-t természetesen le kell cserélni a felhasználóval (és lehet, hogy az ipfs program teljes elérési útja más lesz (meg kell adnia a teljes elérési utat)).

Aktiváljuk a szolgáltatást.

sudo systemctl enable ipfs.service

Elkezdjük a szolgáltatást.

sudo service ipfs start

A szolgáltatás állapotának ellenőrzése.

sudo service ipfs status

A kísérlet tisztasága érdekében a jövőben lehetőség lesz a szerver újraindítására annak ellenőrzésére, hogy az ipfs automatikusan elindul-e.

Ismert ünnepek hozzáadása

Vegyünk egy olyan helyzetet, amikor az IPFS-csomópontok külső kiszolgálón és helyileg is telepítve vannak. Egy külső szerveren hozzáadunk néhány fájlt, és megpróbáljuk IPFS-en keresztül helyileg, CID-n keresztül lekérni. Mi fog történni? Természetesen a helyi szerver nagy valószínűséggel nem tud semmit a külső szerverünkről, és egyszerűen megpróbálja megtalálni a fájlt CID alapján úgy, hogy „megkéri” az összes rendelkezésére álló IPFS-társat (amivel már sikerült „megismerkednie”). Azok viszont megkérdeznek másokat. És így tovább, amíg meg nem találja a fájlt. Valójában ugyanez történik, amikor a fájlt a hivatalos átjárón keresztül próbáljuk elérni ipfs.io. Ha szerencséd van, a fájlt néhány másodpercen belül megtalálod. És ha nem, akkor még néhány perc alatt sem találja meg, ami nagyban befolyásolja a munka kényelmét. De tudjuk, hol jelenik meg először ez a fájl. Akkor miért nem mondjuk azonnal a helyi szerverünknek, hogy „Keressen ott először”? Úgy tűnik, ezt meg lehet tenni.

1. A távoli szerverre lépünk, és megnézzük a ~/.ipfs/config config fájlt

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

2. Futtassa a sudo szolgáltatás ipfs állapotát, és keresse meg a Swarm bejegyzéseket, például:

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

3. Ebből adjuk hozzá az "/ip4/ip_your_server/tcp/4001/ipfs/$PeerID" űrlap általános címét.

4. A megbízhatóság érdekében megpróbáljuk hozzáadni ezt a címet a partnerekhez a helyi webujon keresztül.

5. Ha minden rendben van, nyissa meg a helyi config ~ / .ipfs / config fájlt, keresse meg benne a „Bootstrap” elemet: [...
és először adja hozzá a kapott címet a tömbhöz.

Indítsa újra az IPFS-t.

Most adjuk hozzá a fájlt a külső szerverhez, és próbáljuk lekérni a helyi szerveren. Gyorsan kell repülnie.

De ez a funkció még nem stabil. Ha jól értem, hiába adjuk meg a peer címet a Bootstrapban, az ipfs működés közben peerekre változtatja az aktív kapcsolatok listáját. Mindenesetre ennek és az állandó társak meghatározásának lehetőségével kapcsolatos kívánságok megvitatása folyamatban van itt és úgy tűnik feltételezett adjunk hozzá néhány funkciót [e-mail védett]+

Az aktuális társak listája a webuiban és a terminálban is megtekinthető.

ipfs swarm peers

És itt-ott kézzel is hozzáadhatja a lakomát.

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

Amíg ezt a funkciót nem javítják, írhat egy eszközt, amely ellenőrzi, hogy van-e kapcsolat a kívánt partnerrel, és ha nem, akkor a kapcsolat felvételéhez.

Érvelés

Azok között, akik már ismerik az IPFS-t, vannak érvek az IPFS mellett és ellen is. Lényegében tegnap vita és arra késztetett, hogy újra beleássak az IPFS-be. És ami a fent említett vitát illeti: nem mondhatom, hogy határozottan ellenzem a felszólalók bármely érvelését (csak azzal nem értek egyet, hogy másfél programozó használ IPFS-t). Általában mindkettőnek igaza van a maga módján (főleg megjegyzés a csekkekkel kapcsolatban elgondolkodtat). De ha félretesszük az erkölcsi és jogi értékelést, ki milyen technikai értékelést ad ennek a technológiának? Személy szerint van egyfajta belső érzésem, hogy „erre mindenképpen szükség van, ennek vannak bizonyos kilátásai”. De miért pontosan, nincs egyértelmű megfogalmazás. Például ha a meglévő központosított eszközöket nézzük, akkor sok tekintetben messze előrébb járnak (működés stabilitása, működési sebessége, irányíthatósága stb.). Ennek ellenére van egy ötletem, amely logikusnak tűnik, és amelyet ilyen decentralizált rendszerek nélkül aligha lehet megvalósítani. Természetesen túlságosan drukkolok, de én így fogalmaznám meg: az internetes információterjesztés elvét meg kell változtatni.

Hadd magyarázzam. Ha így gondolja, akkor most a „Remélem, hogy akinek átadtam, az megvédi, és nem veszi el, nem kapja meg olyan, akinek nem szánták.” Példaként könnyű megfontolni a különféle e-mail szolgáltatásokat, a felhőalapú tárolást stb. És mi van a végén? Hub a Habré-n Információ biztonság az első vonalban van, és szinte minden nap kapunk híreket egy újabb globális kiszivárogtatásról. Elvileg minden legérdekesebb dolog fel van sorolva az <irónia> csodálatos cikk Mindjárt vége a nyárnak. Szinte nem maradtak kiszivárgott adatok. Vagyis a fő internetes óriások egyre nagyobbak, egyre több információt halmoznak fel, az ilyen kiszivárogtatások pedig egyfajta információs atomrobbanások. Ilyen még nem fordult elő, és újra itt van. Ugyanakkor, bár sokan megértik, hogy vannak kockázatok, adataikat továbbra is külső cégekre bízzák. Egyrészt nincs sok alternatíva, másodszor pedig azt ígérik, hogy minden lyukat befoltoztak, és ez soha többé nem fordul elő.

Milyen lehetőséget látok? Számomra úgy tűnik, hogy az adatokat kezdetben nyíltan kell terjeszteni. De a nyitottság ebben az esetben nem jelenti azt, hogy mindennek könnyen olvashatónak kell lennie. A tárolás és terjesztés nyitottságáról beszélek, de nem az olvasás teljes nyitottságáról. Feltételezem, hogy az információkat nyilvános kulcsokkal kell terjeszteni. Végül is a nyilvános / privát kulcsok elve már régi, majdnem olyan, mint az internet. Ha az információ nem bizalmas és széles körnek szól, akkor azonnal közzétesszük nyilvános kulccsal (de továbbra is titkosított formában, a meglévő kulccsal bárki visszafejtheti). És ha nem, akkor a nyilvános kulcs nélkül kerül közzétételre, és magát a kulcsot átadják annak, akinek hozzá kell férnie ehhez az információhoz. Ugyanakkor annak, akinek el kell olvasnia, csak kulcsa kell, hogy legyen, és az, hogy ezt az információt honnan szerezze meg, nem igazán számíthat neki - egyszerűen kihúzza a hálózatból (ez az új tartalom szerinti terjesztés elve, és nem cím szerint).

Így egy tömeges támadáshoz a támadóknak hatalmas számú privát kulcsot kell beszerezniük, és ez nem valószínű, hogy egy helyen fog megtörténni. Ez a feladat, ahogy látom, nehezebb, mint egy adott szolgáltatás feltörése.

És itt jön egy másik probléma: a szerzőség megerősítése. Most az interneten számos, barátaink által írt idézetet találhat. De hol a garancia, hogy ők írták őket? Most, ha minden ilyen rekordhoz digitális aláírás járna, sokkal egyszerűbb lenne. És nem számít, hol találhatók ezek az információk, a lényeg az aláírás, amelyet nyilvánvalóan nehéz hamisítani.

És itt van, ami itt érdekes: az IPFS már tartalmaz titkosítási eszközöket (elvégre blockchain technológiára épül). A privát kulcs azonnal megadásra kerül a konfigurációban.

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

Nem vagyok biztonsági szakember, és nem tudom pontosan, hogyan kell helyesen használni, de számomra úgy tűnik, hogy ezeket a kulcsokat az IPFS csomópontok közötti csere szintjén használják. És még js-ipfs és példaprojektek, mint pl pálya-dbamelyen működik kering.csevegés. Azaz elméletileg minden eszköz (mobil és nem csak) könnyen felszerelhető saját titkosító-visszafejtő gépekkel. Ebben az esetben mindenkinek csak a magánkulcsai mentéséről kell gondoskodnia, és mindenki a saját biztonságáért lesz felelős, nem pedig egy újabb emberi tényező túsza valamelyik szupernépszerű internetes óriáscégen.

A felmérésben csak regisztrált felhasználók vehetnek részt. Bejelentkezés, kérem.

Hallottál már az IPFS-ről?

Még soha nem hallottam az IPFS-ről, de érdekesnek tűnik
Nem hallottam és nem is akarom hallani
Hallottam, de nem érdekelt
Hallottam, de nem értettem, de most érdekesnek tűnik
Régóta használom aktívan az IPFS-t.

69 felhasználó szavazott. 13 felhasználó tartózkodott.

Forrás: will.com

IPFS fájdalom nélkül (de ez nem pontos)