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

Bár volt már a Habrán nem egy cikk az IPFS-ről.

Az elején tisztázom, hogy nem vagyok szakértő ezen a területen, de már többször érdeklődtem ez iránt a technológia iránt, és a vele való kísérletezés gyakran okozott némi fájdalmat. Ma ismét nekiláttam a kísérletezésnek, és elértem néhány eredményt, amelyet szeretnék megosztani. Röviden szólva, a folyamatot az IPFS telepítéséről és néhány trükköt fogok leírni (minden Ubuntu alatt készült, más platformokon nem próbáltam).

Ha lemaradtál arról, hogy mi is az IPFS, részletesen olvashatsz róla itt: habr.com/ru/post/314768

Telepítés

A kísérlet tisztaságának érdekében javaslom, hogy az IPFS-t egy külső szerverre telepítsük, mivel néhány buktatót fogunk megvizsgálni a helyi és távoli üzemmódban. Később, ha akarod, könnyen eltávolítható, nem tart sokáig.

Telepítjük a go-t

Hivatalos dokumentáció
A legfrissebb verziót a következő oldalon találod: golang.org/dl

Megjegyzés: jobb, ha az IPFS-t azon a felhasználón nevele a telepítése, akinek a leggyakrabban használni fogja. Az a helyzet, hogy alább meg fogjuk vizsgálni a csatolással kapcsolatos lehetőségeket, és vannak finomságok. FUSE és ott vannak a részletek.

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ítened kell a környezetet (bővebben 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őrizzük, hogy a go telepítve van-e

go version

Telepítjük az IPFS-t

A legjobban a következő telepítési mód tetszett: ipfs-update.

Az alábbi paranccsal telepítjük:

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

Ezután ilyen parancsokat lehet végrehajtani:

ipfs-update versions — hogy láthasd az összes letölthető verziót.
ipfs-update version — hogy láthasd az aktuálisan telepített verziót (mivel jelenleg az IPFS nincs telepítve, az none lesz).
ipfs-update install latest — telepíti a legújabb verziót az IPFS-ből. A legújabb helyett természetesen megadhatod az elérhető verziók bármelyikét a listából.

Telepítjük az ipfs-t

ipfs-update install latest

Ellenőrzés

ipfs --version

A telepítés részleteket tekintve ennyi.

IPFS indítása

Inicializálás

Először is végre kell hajtani az inicializálást.

ipfs init

Válaszként valami ilyesmit kapsz:

 ipfs init
IPFS csomópont inicializálása itt: /home/USERNAME/.ipfs
2048-bites RSA kulcspár generálása... kész
partner azonosító: QmeCWX1DD7HnXXXXXXXXXXXXXXXXXXXXXXXXxxx
kezdéshez add meg:
	ipfs cat /ipfs/QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv/readme

Végrehajthatod a javasolt parancsot

ipfs cat /ipfs/QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv/readme

Eredmény

Helló és üdvözöljük az IPFS-en!

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

Ha ezt látja, sikeresen telepítette az IPFS-t, és most kapcsolatba lép az ipfs merkledag-gal!

 -------------------------------------------------------
| Figyelmeztetés:                                        |
|   Ez alfa szoftver. Használja saját belátása szerint! |
|   Sok dolog hiányzik, vagy nincs még polírva. Hibák vannak.
|   Még nem biztonságos. Olvassa el a biztonsági megjegyzéseket a továbbiakért. |
 -------------------------------------------------------

Nézzen meg néhány másik fájlt ebben a könyvtárban:

  .\/about
  .\/help
  .\/quick-start     <-- használati példák
  .\/readme          <-- ez a fájl
  .\/security-notes

Szerintem itt kezdődik az igazán érdekes rész. A srácok már a telepítés fázisában elkezdik használni a saját technológiájukat. A javasolt hash QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv – nem kifejezetten önnek generálták, hanem beépítették a kiadásba. Vagyis a kiadás előtt előkészítették a köszöntő szöveget, feltöltötték az IPFS-be, és a címet hozzáadták a telepítőhöz. Szerintem ez nagyon menő. És ezt a fájlt (pontosabban az egész mappát) most már nemcsak helyben, hanem az hivatalos hídon is megtekinthetjük. ipfs.io/ipfs/QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv. Ekkor biztosak lehetünk benne, hogy a mappa tartalma nem változott, mert ha megváltozott volna, akkor a hash is megváltozott volna.

Egyébként ebben az esetben az IPFS bizonyos hasonlóságot mutat a verziókezelő szerverekkel. Ha a mappa forrásfájljaiban módosítanak, és ismét feltöltik a mappát az IPFS-be, akkor új címet kap. És a régi mappa nem tűnik el csak úgy, és továbbra is elérhető marad az eredeti címén.

Közvetlen indítás

ipfs daemon

Válaszul valami ilyesmit kell kapnia:

ipfs daemon
Inicializálás...
go-ipfs verzió: 0.4.22-
Repo verzió: 7
Rendszer verzió: amd64/linux
Golang verzió: go1.12.7
Swarm hallgat a\/ip4\/x.x.x.x\/tcp\/4001
Swarm hallgat a\/ip4\/127.0.0.1\/tcp\/4001
Swarm hallgat a\/ip6\/::1\/tcp\/4001
Swarm hirdetve a\/p2p-circuit
Swarm hirdetve\/ip4\/127.0.0.1\/tcp\/4001
Swarm hirdetve\/ip6\/::1\/tcp\/4001
API szerver hallgat a\/ip4\/127.0.0.1\/tcp\/5001
WebUI: http:\/\/127.0.0.1:5001\/webui
Híd (csak olvasható) szerver hallgat a\/ip4\/127.0.0.1\/tcp\/8080
A démon készen áll

Megnyitjuk az ajtókat az Internet előtt

Figyelje meg ezt a két sort:

WebUI: http:\/\/127.0.0.1:5001\/webui
Híd (csak olvasható) szerver hallgat a\/ip4\/127.0.0.1\/tcp\/8080

Ha helyben telepítette az IPFS-t, akkor a lokális címeken keresztül férhet hozzá az IPFS-interfészekhez, és minden elérhető lesz (például, localhost:5001/webui/). Azonban ha egy külső szerverre telepítjük, alapértelmezés szerint a kapuk zárva vannak az internet előtt. Két kapu van:

WebUI adminfelület (github) az 5001-es porton.
Külső API az 8080-as porton (csak olvasható).

Kísérletezés céljából mindkét portot (5001 és 8080) meg lehet nyitni, de éles szerveren az 5001-es portot mindenképpen tűzfallal le kell zárni. Van egy 4001-es port is, amely arra szükséges, hogy más peer-ek megtaláljanak minket. Ezt nyitva kell hagyni a kérésekhez kívülről.

Nyissuk meg a ~/.ipfs/config fájlt, és keressük meg ezeket a 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ítsuk a 127.0.0.1-et a szerverünk IP-jére, és mentsük el a fájlt, majd indítsuk újra az IPFS-t (a futó parancsot állítsuk le Ctrl+C-vel, majd indítsuk újra).

A következőt kell kapnunk

...
WebUI: http:\/\/a_szerver_ipje:5001\/webui
A kapu (csak olvasható) szerver figyel a \/ip4\/a_szerver_ipje\/tcp\/8080-on

Most már a külső interfészeknek elérhetőnek kell lenniük.

Ellenőrizze

http:\/\/domain_vagy_a_szerver_ipje:8080\/ipfs\/QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv\/readme

A fent említett README fájlnak meg kell nyílnia.

http:\/\/domain_vagy_a_szerver_ipje:5001\/webui\/

A webes interfésznek meg kell nyílnia.

Ha a webui működik, akkor az IPFS beállításait közvetlenül ott lehet módosítani, beleértve a statisztikák megtekintését is, de lentebb a konfigurációs fájlon keresztüli konfigurációs lehetőségeket fogom megvitatni, ami alapvetően nem kritikus. Csak jobb, ha megjegyzi, hol található a konfiguráció, és mit kell vele csinálni, mert ha a webes felület nem működik, akkor már nehezebb lesz.

Állítsuk be a webes felületet a saját szerverünkkel való munkához

Itt van az első buktató, amelyre körülbelül három órát kellett költenem.

Ha az IPFS-t külső szerverre telepítette, de nem telepítette vagy nem indította el az IPFS-t helyben, akkor amikor belép a \/webui-ra a webes felületen, csatlakozási hibát kell látnia:

A helyzet az, hogy a webui, véleményem szerint, meglehetősen ellentmondásosan működik. Először megpróbál csatlakozni annak a szervernek az API-jához, ahol a felület nyitva van (nyilván a böngészőben látható cím alapján). Ha ez nem sikerül, megpróbál csatlakozni a helyi kapuhoz. Ha az IPFS helyben fut, akkor a webui rendben fog működni, de abban az esetben a helyi IPFS-sel fog dolgozni, nem a külsővel, még akkor is, ha a webui rendelkezésre áll egy külső szerveren. Aztán feltöltöd a fájlokat, de valamiért nem látod őket egyszerűen a külső szerveren...

Ha nem is fut helyben, akkor csatlakozási hibát kapunk. A mi esetünkben a hiba valószínűleg a CORS miatt van, amit a webui is jelez, javasolva a konfiguráció hozzáadását.

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

Én csak vadkártyát adtam meg magamnak.

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

Az hozzáadott fejlécet megtalálhatjuk a ~/.ipfs/config fájlban. Az én esetemben ez a következő:

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

Újraindítjuk az ipfs-t, és látjuk, hogy a webui sikeresen csatlakozott (legalábbis ennek kellene történnie, ha megnyitottuk a kapukat a külső kérésekhez, ahogyan azt fent leírtuk).

Most már közvetlenül a webinterfészen keresztül is feltölthetjük a mappákat és fájlokat, valamint létrehozhatunk saját mappákat is.

FUSE fájlrendszer összemontírozása

Ez egy elég érdekes dolog.

A fájlokat (ahogyan a mappákat is) nemcsak a webinterfészen keresztül, hanem közvetlenül a terminálban is hozzáadhatjuk, például

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

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

Ezen a hash-en keresztül megnyithatjuk a mappát bármely ipfs-nódon (amely képes megtalálni a mi nodunkat és megszerezni a tartalmát), aztán elérhetjük a webinterfészen a 5001-es vagy a 8080-as porton, vagy helyben az ipfs-en keresztül.

ipfs ls QmbnzgRVAP4fL814h5mQttyqk1aUxxxxxxxxxxxxx
QmfYuz2gegRZNkDUDVLNa5DXzKmKVxxxxxxxxxxxxxx 10 test.txt

De nyitható egyszerű mappaként is.

Hozzunk létre két mappát a gyökérben, és adjuk meg a jogokat a felhasználónknak.

sudo mkdir /ipfs /ipns
sudo chown FELHASZNÁLÓ_NEVÉT /ipfs /ipns

és indítsuk újra az ipfs-t a —mount flaggel.

ipfs daemon --mount

Lehet mappákat létrehozni más helyszíneken is, és megadni azokat az ipfs daemon —mount —mount-ipfs /ipfs_path —mount-ipns /ipns_path paramétereként.

Mostantól a fájlok olvasása ebből a mappából némileg szokatlan.

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

Ezért nincs közvetlen hozzáférés a mappa gyökeréhez. De a tartalom megismerhető, ha ismerjük a hash-t.

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

Ezenkívül a mappán belül az automatikus kiegészítés is működik az útvonal megadása során.

Ahogy fentebb említettem, ennek a csatolásnak vannak finomságai: alapértelmezés szerint a csatolt FUSE-mappák csak a jelenlegi felhasználó számára elérhetők (még a root sem fog tudni olvasni egy ilyen mappából, nemhogy más felhasználók a rendszerben). Ha azt szeretné, hogy ezek a mappák más felhasználók számára is elérhetők legyenek, akkor a konfigurációban a "FuseAllowOther": false értéket "FuseAllowOther": true-ra kell módosítani. De ez még nem minden. Ha az IPFS-t root felhasználóként indítja, akkor minden rendben van. Ha azonban egy normál felhasználóként (még sudo mellett is) indítja, akkor hibát fog kapni.

mount helper error: fusermount: az 'allow_other' opció csak akkor engedélyezett, ha a 'user_allow_other' be van állítva az /etc/fuse.conf fájlban

Ebben az esetben módosítani kell az /etc/fuse.conf fájlt, és el kell távolítani a #user_allow_other sor megjegyzését.

Ezután újraindítjuk az ipfs-t.

Ismert problémák a FUSE-szal

Több alkalommal észlelték, hogy az ipfs újraindításakor a csatlakozások (és lehet, hogy más esetekben is) a /ipfs és /ipns elérhetetlenné válnak. Nincs hozzáférés, és az ls -la /ipfs ????-ot mutat a jogosultságok listáján.

Találtam egy megoldást:

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

Ezt követően újraindítjuk az ipfs-t.

Szolgáltatás hozzáadása

Természetesen a terminálban történő indítás csak kezdeti tesztekhez alkalmas. Éles üzemmódban a démonnak automatikusan el kell indulnia a rendszer indításakor.

sudo néven létrehozunk egy /etc/systemd/system/ipfs.service fájlt, és beírjuk a következőt:

[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 USERNAME-t természetesen a saját felhasználójára kell cserélni (és lehet, hogy az ipfs program teljes elérési útja más lesz nálad (a pontos elérési utat kell megadni)).

A szolgáltatás aktiválása.

sudo systemctl enable ipfs.service

A szolgáltatás indítása.

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 később újraindíthatja a szervert, hogy ellenőrizze, hogy az ipfs automatikusan sikeresen elindul-e.

Hozzáadjuk az ismert pírjainkat.

Nézzük meg a helyzetet, amikor az IPFS csomópontok telepítve vannak egy külső szerveren és helyben is. A külső szerveren hozzáadunk egy fájlt, és megpróbáljuk azt az IPFS-en keresztül helyben elérni a CID alapján. Mi fog történni? Természetesen a helyi szerver valószínűleg semmit sem tud a külső szerverünkről, és egyszerűen megpróbálja megkeresni a fájlt a CID alapján, „megkérdezősködve” az összes elérhető IPFS csomóponttól, akikkel már „megismerkedett”. Ők pedig tovább kérdezősködnek másoktól. És ez így folytatódik, amíg a fájl meg nem található. Valójában ugyanez történik, amikor megpróbáljuk a fájlt elérni az hivatalos átjárón keresztül. ipfs.io. Ha szerencsénk van, akkor a fájl néhány másodperc alatt megtalálható. De ha nem, akkor akár néhány percig sem található, ami nagyon megnehezíti a munkát. De mi tudjuk, hol fog először megjelenni ez a fájl. Akkor miért ne mondanánk a helyi szerverünknek azonnal, hogy „keress először ott”? Úgy tűnik, hogy ezt meg lehet tenni.

1. Lépjünk be a távoli szerverre, és a ~/.ipfs/config fájlban keressük meg

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

2. Futassuk a sudo service ipfs status parancsot, és keressük benne a Swarm bejegyzéseket, például:

Swarm announcing /ip4/ip_a_szervered_tcp/4001

3. Ezekből összerakjuk a következő formátumú címet: „/ip4/ip_a_szervered/tcp/4001/ipfs/$PeerID”.

4. A megbízhatóság érdekében a helyi webui-n keresztül próbáljunk meg hozzáadni ezt a címet a csomópontokhoz.

5. Ha minden rendben van, nyissuk meg a helyi konfigurációt a ~/.ipfs/config fájlban, keressük meg a „Bootstrap”: […
és az első elemeként írjuk be a kapott címet a tömbbe.

Indítsuk újra az IPFS-t.

Most adjunk hozzá egy fájlt a külső szerveren, és próbáljuk meg lekérni a helyin. Gyorsan el kellene érkeznie.

De ez a funkció még instabil. Amennyire értem, még ha megadjuk is a csomópont címét a Bootstrap-ban, ipfs közben megváltoztatja az aktív csatlakozások listáját a csomópontokkal. Mindenesetre erről már folyt a diskurzus, és javaslatok érkeztek a folyamatos csomópontok megadására. itt és úgy tűnik, hogy feltételezhető valamilyen funkciót hozzanak be az ipfs@5.0+ verzióba.

A jelenlegi csomópontok listáját meg lehet nézni mind webui-ban, mind terminálban.

ipfs swarm peers

Itt és ott is lehet kézzel hozzáadni a saját csomópontodat.

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

Míg nem javítják ezt a funkciót, készíthetünk egy eszközt, amely ellenőrzi a kapcsolat meglétét a szükséges csomóponttal, és ha nem talál, hozzáadja a csatlakozást.

Gondolatok

Az IPFS-sel már ismerkedők között vannak érvek mellette és ellene is. Alapvetően, a múlt héten vita és ez arra ösztönzött, hogy újra mélyebben beleássak az IPFS-be. Ami a megemlített vitát illeti: nem mondhatom, hogy nagyon ellene lennék bármelyik felhozott érvről (csak abban nem értek egyet, hogy másfél programozó használja az IPFS-t). Összességében mindkét félnek igaza van valamilyen módon (különösen a megjegyzés a csekkekről elgondolkodtató). De ha eltekintünk a morális és jogi értékelésektől, ki adna technikai értékelést erről a technológiáról? Személy szerint van egy belső érzésem, hogy "ezt mindenképpen csinálni kell, van bizonyos jövője". De hogy miért, annak nincs világos megfogalmazása. Például, ha megnézzük a létező centralizált eszközöket, sok szempontból jóval előttünk állnak (működés stabilitása, sebesség, kezelhetőség stb.). Ennek ellenére van egy gondolatom, ami úgy tűnik, hogy értelmet nyer, és amely valószínűleg nem valósítható meg ilyen decentralizált rendszerek nélkül. Persze, talán túlságosan is, de úgy fogalmaznám meg, hogy: az információ terjesztésének elvét meg kellene változtatni.

Elmagyarázom. Ha úgy gondolkodunk, akkor jelenleg az információink a "Remélem, hogy akihez eljuttattam, megvédi, és nem veszik el, vagy nem kapja meg az, akinek nem szántam" elv alapján terjednek. Például könnyen megvizsgálhatók különböző levelező szolgáltatások, felhőtárolók stb. És mi az, amit végül kapunk? A Habr-on a Információbiztonság az első helyen áll, és szinte minden nap kapunk híreket egy újabb globális adatszivárgásról. Alapvetően az összes érdekfeszítő dolog felsorolva van a csodálatos cikkben A nyár majdnem véget ért. Szinte nincs elveszett adat.. Tehát a fő internetes óriások egyre nagyobbá válnak, egyre több információt halmoznak fel, és az ilyen szivárgások - egyfajta információs atombombaként - egyre gyakoribbak. Ilyen még sosem volt, és lám, újra itt van. Ezzel párhuzamosan, bár sokan megértik, hogy vannak kockázatok, továbbra is bíznak adataikkal a külső vállalatokban. Egyrészt különösebb alternatíva nincs, másrészt ezek azt ígérik, hogy betömtek minden lyukat, és ez soha többé nem fog megtörténni.

Milyen lehetőség tűnik számomra? Úgy vélem, az adatoknak kezdetben nyilvánosan kellene terjedniük. De a nyitottság ebben az esetben nem azt jelenti, hogy mindennek könnyen olvashatónak kell lennie. A tárolás és a terjesztés nyitottságáról beszélek, de nem a teljes olvashatóságról. Úgy gondolom, hogy az információnak nyílt kulcsokkal kell terjednie. Végül is a nyilvános/privát kulcsok elve már régi, szinte mint az internet. Ha az információ nem bizalmas, és széles kör számára készült, akkor nyílt kulccsal kerül közzétételre (de minden esetben titkosítva, csupán azt bárki dekódolhatja a meglévő kulccsal). Ha ez nem így van, akkor nyílt kulcs nélkül kerül közzétételre, és a kulcsot azt kapja meg, akinek hozzáférése van ehhez az információhoz. Ebben az esetben annak, aki el akarja olvasni, csak a kulcsra van szüksége, hogy honnan szerzi be az információt, az nem kell, hogy különösebben foglalkoztassa — egyszerűen letölti az internetről (ez az új terjesztési elv a tartalom alapján, nem pedig a cím alapján).

Így a támadóknak egy tömeges támadáshoz hatalmas mennyiségű privát kulcsra kell szert tenniük, és valószínű, hogy ezt egy helyen nem tudják megtenni. Ez a feladat számomra bonyolultabbnak tűnik, mint egy adott szolgáltatás feltörése.

És itt bezárul egy másik probléma: a szerzőség igazolása. Jelenleg az interneten rengeteg idézet található, amelyeket ismerősünk írt. De hol a garancia, hogy valóban ők írták? Ha minden ilyen bejegyzést digitális aláírás kísérne, sokkal egyszerűbb lenne. Nem számít, hogy hol van az információ, a lényeg a aláírás, amelyet nyilvánvalóan nehéz hamisítani.

És ami itt érdekes: az IPFS már beépített titkosítást tartalmaz (mivel a blokklánc technológián alapul). A konfigurációban azonnal van egy privát kulcs megadva.

  "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 szakértő, és nem tudom pontosan, hogyan kell ezt helyesen használni, de úgy tűnik, hogy az IPFS csomópontok közötti kommunikációszinten ezek a kulcsok használatosak. Ezen kívül js-ipfs és olyan projektek, mint orbit-db, amelyen fut orbit.chat. Tehát elméletileg minden eszköz (mobil és nem csak) könnyen felszerelhető a saját titkosító-dekódoló gépeivel. Ebben az esetben mindenkinek magának kell gondoskodnia a privát kulcsainak megőrzéséről, és mindenki felelős lesz a saját biztonságáért, nem pedig egy népszerű internetes óriás emberi tényezőjének áldozataként.

Csak a regisztrált felhasználók vehetnek részt a szavazáson. Kérem, jelentkezzen be., kérem.