🥇IPFS zonder pijn (maar dit klopt niet)

Ondanks dat Habré dat al was meer dan één artikel over IPFS.

Ik zal meteen duidelijk maken dat ik geen expert op dit gebied ben, maar ik heb meer dan eens interesse getoond in deze technologie, maar ermee spelen deed vaak pijn. Vandaag ben ik weer begonnen met experimenteren en heb een aantal resultaten behaald die ik graag wil delen. In het kort zullen het IPFS-installatieproces en enkele functies worden beschreven (alles is gedaan op ubuntu, ik heb het niet op andere platforms geprobeerd).

Als je hebt gemist wat IPFS is, staat het hier in detail beschreven: habr.com/en/post/314768

installatie

Voor de zuiverheid van het experiment raad ik aan het onmiddellijk op een externe server te installeren, omdat we enkele valkuilen zullen overwegen bij het werken in de lokale modus en op afstand. Dan wordt er desgewenst lange tijd niet gesloopt, veel is er niet.

Installeer gaan

Officiële documentatie
Zie de huidige versie op golang.org/dl

Let op: het is beter om IPFS te installeren namens de gebruiker die het het meest zou moeten gebruiken. Feit is dat we hieronder de optie van montage via zullen overwegen FUSE en er zijn subtiliteiten.

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

Vervolgens moet u de omgeving bijwerken (meer details hier: 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

Controleren of go is geïnstalleerd

go version

Installeer IPFS

Ik vond de installatiemethode het leukst ipfs-update.

Installeer het met de opdracht

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

Hierna kunt u de volgende opdrachten uitvoeren:

ipfs-update versies - om alle beschikbare versies te zien om te downloaden.
ipfs-update-versie - om de momenteel geïnstalleerde versie te zien (totdat we IPFS hebben geïnstalleerd, zal dit geen versie zijn).
ipfs-update installeer laatste - installeer de nieuwste versie van IPFS. In plaats van respectievelijk de nieuwste kunt u elke gewenste versie opgeven uit de lijst met beschikbare versies.

Ipf's installeren

ipfs-update install latest

check de

ipfs --version

Direct bij de installatie in algemene zin alles.

IPFS starten

Initialisatie

Eerst moet u de initialisatie uitvoeren.

ipfs init

Als antwoord ontvang je zoiets als dit:

 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

U kunt de voorgestelde opdracht uitvoeren

ipfs cat /ipfs/QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv/readme

Resultaat

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

Hier begint naar mijn mening het interessante. De jongens in de installatiefase beginnen al hun eigen technologieën te gebruiken. De voorgestelde hash QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv wordt niet specifiek voor u gegenereerd, maar in de release genaaid. Dat wil zeggen dat ze vóór de release een welkomsttekst hadden voorbereid, deze in IPFS hadden gegoten en het adres aan het installatieprogramma hadden toegevoegd. Ik vind het heel cool. En dit bestand (meer precies, de hele map) kan nu niet alleen lokaal worden bekeken, maar ook op de officiële gateway ipfs.io/ipfs/QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv. Tegelijkertijd kunt u er zeker van zijn dat de inhoud van de map op geen enkele manier is veranderd, want als deze was veranderd, zou de hash ook zijn veranderd.

Overigens heeft IPFS in dit geval enkele overeenkomsten met de versiebeheerserver. Als u wijzigingen aanbrengt in de bronbestanden van de map en de map opnieuw in IPFS giet, krijgt deze een nieuw adres. Tegelijkertijd zal de oude map niet zomaar ergens naartoe gaan en beschikbaar zijn op het vorige adres.

Directe lancering

ipfs daemon

U zou een antwoord als dit moeten ontvangen:

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

De deuren naar internet openen

Let op deze twee regels:

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

Als u IPFS nu lokaal hebt geïnstalleerd, krijgt u toegang tot IPFS-interfaces op lokale adressen en is alles voor u beschikbaar (bijvoorbeeld localhost:5001/webui/). Maar bij installatie op een externe server zijn de gateways standaard gesloten voor internet. Gateways twee:

webui-beheerder (GitHub) op poort 5001.
Externe API op poort 8080 (alleen-lezen).

Tot nu toe kunnen beide poorten (5001 en 8080) worden geopend voor experimenten, maar op een gevechtsserver moet poort 5001 uiteraard worden afgesloten met een firewall. Er is ook poort 4001, die nodig is zodat andere peers u kunnen vinden. Het moet open blijven voor verzoeken van buitenaf.

Open ~/.ipfs/config om te bewerken en zoek deze regels erin:

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

Wijzig 127.0.0.1 naar het ip-adres van uw server en sla het bestand op, start vervolgens ipfs opnieuw (stop de lopende opdracht met Ctrl+C en start deze opnieuw).

Moet krijgen

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

Nu zouden de externe interfaces beschikbaar moeten zijn.

Rekening

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

Het bovenstaande leesmij-bestand zou moeten openen.

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

De webinterface zou moeten openen.

Als webui voor u werkt, kunnen de IPFS-instellingen er rechtstreeks in worden gewijzigd, inclusief het bekijken van statistieken, maar hieronder zal ik configuratie-opties rechtstreeks via het configuratiebestand bekijken, wat over het algemeen niet kritisch is. Het is gewoon beter om precies te onthouden waar de configuratie zich bevindt en wat u ermee moet doen, anders zal het moeilijker zijn als de webface niet werkt.

Een webinterface opzetten om met uw server te werken

Hier is de eerste valkuil, die ongeveer drie uur duurde.

Als u IPFS op een externe server hebt geïnstalleerd, maar IPFS niet lokaal hebt geïnstalleerd of uitgevoerd, zou u een verbindingsfout moeten zien als u in de webinterface naar /webui gaat:

Feit is dat webui naar mijn mening zeer dubbelzinnig werkt. Eerst probeert het verbinding te maken met de API van de server waarop de interface open is (uiteraard op basis van het adres in de browser). en als het daar niet werkt, probeert het verbinding te maken met de lokale gateway. En als IPFS lokaal draait, dan werkt webui prima voor u, alleen werkt u met lokale IPFS, en niet extern, hoewel u webui op een externe server hebt geopend. Vervolgens upload je de bestanden, maar om een of andere reden zie je ze niet zomaar op een externe server…

En als het niet lokaal draait, krijgen we een verbindingsfout. In ons geval is de fout hoogstwaarschijnlijk te wijten aan CORS, wat ook wordt aangegeven door webui, wat suggereert dat een config.

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

Ik heb zojuist een wildcard geregistreerd

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

De toegevoegde headers zijn te vinden in hetzelfde ~/.ipfs/config. In mijn geval wel

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

We herstarten ipfs en we zien dat webui succesvol verbinding heeft gemaakt (in ieder geval zou dit moeten gebeuren als je de gateways hebt geopend voor verzoeken van buitenaf, zoals hierboven beschreven).

Nu kunt u mappen en bestanden rechtstreeks via de webinterface uploaden en uw eigen mappen maken.

Het FUSE-bestandssysteem koppelen

Hier is een behoorlijk interessante functie.

Bestanden (maar ook mappen) kunnen we niet alleen via de webinterface toevoegen, maar bijvoorbeeld ook rechtstreeks in de terminal

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

De laatste hash is de hash van de hoofdmap.

Met behulp van deze hash kunnen we een map openen op elk ipfs-knooppunt (die ons knooppunt kan vinden en de inhoud kan ophalen), we kunnen in de webinterface op poort 5001 of 8080, of we kunnen lokaal via ipfs.

ipfs ls QmbnzgRVAP4fL814h5mQttyqk1aUxxxxxxxxxxxxx
QmfYuz2gegRZNkDUDVLNa5DXzKmKVxxxxxxxxxxxxxx 10 test.txt

Maar je kunt het nog steeds openen als een gewone map.

Laten we twee mappen in de root maken en rechten daarop verlenen aan onze gebruiker.

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

en start ipfs opnieuw met de vlag --mount

ipfs daemon --mount

U kunt op andere plaatsen mappen maken en het pad ernaartoe opgeven via de ipfs daemon-parameters -mount -mount-ipfs /ipfs_path -mount-ipns /ipns_path

Het lezen uit deze map is enigszins ongebruikelijk.

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

Dat wil zeggen dat er geen directe toegang is tot de hoofdmap van deze map. Maar je kunt de inhoud krijgen, als je de hash kent.

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

Tegelijkertijd werkt zelfs automatisch aanvullen binnen de map als het pad is opgegeven.

Zoals ik hierboven al zei, zijn er subtiliteiten bij een dergelijke montage: standaard zijn aangekoppelde FUSE-mappen alleen beschikbaar voor de huidige gebruiker (zelfs root kan niet uit zo'n map lezen, om nog maar te zwijgen van andere gebruikers in het systeem). Als u deze mappen beschikbaar wilt maken voor andere gebruikers, moet u in de configuratie "FuseAllowOther": false wijzigen in "FuseAllowOther": true. Maar dat is niet alles. Als u IPFS als root uitvoert, is alles in orde. En als u namens een gewone gebruiker (zelfs sudo) bent, krijgt u een foutmelding

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

In dit geval moet u /etc/fuse.conf bewerken door de commentaarregel #user_allow_other te verwijderen.

Start daarna ipfs opnieuw op.

Bekende problemen met FUSE

Het probleem is meer dan eens opgemerkt dat na het herstarten van ipfs met mount (en misschien in andere gevallen), de mountpunten /ipfs en /ipns niet meer beschikbaar zijn. Er is geen toegang daartoe, en ls -la /ipfs toont ???? in de lijst met rechten.

Deze oplossing gevonden:

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

Start vervolgens ipfs opnieuw op.

Een dienst toevoegen

Uiteraard is het draaien in de terminal alleen geschikt voor eerste tests. In gevechtsmodus zou de daemon automatisch moeten starten bij het opstarten van het systeem.

Maak namens sudo het bestand /etc/systemd/system/ipfs.service en schrijf ernaar:

[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

GEBRUIKERSNAAM moet uiteraard worden vervangen door uw gebruiker (en misschien zal het volledige pad naar het ipfs-programma voor u anders zijn (u moet het volledige pad opgeven)).

Wij activeren de dienst.

sudo systemctl enable ipfs.service

Wij starten de dienst.

sudo service ipfs start

Het controleren van de status van de dienst.

sudo service ipfs status

Voor de zuiverheid van het experiment zal het mogelijk zijn om de server in de toekomst opnieuw op te starten om te controleren of ipfs automatisch succesvol start.

Het toevoegen van ons bekende feesten

Beschouw een situatie waarin we IPFS-knooppunten zowel op een externe server als lokaal hebben geïnstalleerd. Op een externe server voegen we een bestand toe en proberen dit via IPFS lokaal via CID op te halen. Wat zal er gebeuren? Natuurlijk weet de lokale server hoogstwaarschijnlijk niets van onze externe server en zal hij eenvoudigweg proberen het bestand te vinden via CID door alle beschikbare IPFS-peers te "vragen" (waarmee hij al heeft kunnen "kennismaken"). Die zullen op hun beurt anderen vragen. En zo verder, totdat het bestand wordt gevonden. Eigenlijk gebeurt hetzelfde wanneer we proberen het bestand via de officiële gateway te krijgen ipfs.io. Als je geluk hebt, wordt het bestand binnen enkele seconden gevonden. En zo niet, dan wordt het zelfs binnen een paar minuten niet gevonden, wat het werkcomfort enorm beïnvloedt. Maar we weten waar dit bestand voor het eerst zal verschijnen. Dus waarom vertellen we onze lokale server niet onmiddellijk "Zoek daar eerst"? Blijkbaar kan dit worden gedaan.

1. We gaan naar de externe server en kijken in de ~/.ipfs/config configuratie

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

2. Voer sudo service ipfs status uit en zoek daarin naar Swarm-vermeldingen, bijvoorbeeld:

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

3. Hieruit voegen we het algemene adres toe van het formulier "/ip4/ip_your_server/tcp/4001/ipfs/$PeerID".

4. Voor de betrouwbaarheid zullen we proberen dit adres toe te voegen aan peers via onze lokale webui.

5. Als alles in orde is, open dan de lokale config ~ / .ipfs / config, zoek daarin “Bootstrap”: [...
en voeg het ontvangen adres eerst toe aan de array.

Start IPFS opnieuw.

Laten we nu het bestand toevoegen aan de externe server en proberen het op te vragen op de lokale server. Moet snel vliegen.

Maar deze functionaliteit is nog niet stabiel. Voor zover ik het begrijp, verandert ipfs, zelfs als we het adres van een peer in Bootstrap specificeren, de lijst met actieve verbindingen met peers tijdens de werking. De discussie hierover en de wensen over de mogelijkheid om permanente feesten te specificeren zijn in ieder geval gaande hier en het lijkt erop verondersteld voeg wat functionaliteit toe [e-mail beveiligd]+

De lijst met huidige peers kan zowel in de webui als in de terminal worden bekeken.

ipfs swarm peers

En hier en daar kun je handmatig je feestmaal toevoegen.

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

Totdat deze functionaliteit is verbeterd, kunt u een tool schrijven om te controleren op een verbinding met de gewenste peer en, zo niet, om een verbinding toe te voegen.

Redenering

Onder degenen die al bekend zijn met IPFS zijn er zowel argumenten vóór als tegen IPFS. Eigenlijk gisteren discussie en vroeg me om opnieuw in IPFS te duiken. En wat betreft de hierboven genoemde discussie: ik kan niet zeggen dat ik sterk gekant ben tegen welk argument dan ook van degenen die spraken (ik ben het alleen niet eens met het feit dat anderhalve programmeur IPFS gebruikt). Over het algemeen hebben beide op hun eigen manier gelijk (vooral commentaar over cheques aan het denken zetten). Maar als we de morele en juridische beoordeling terzijde schuiven, wie zal dan een technische beoordeling van deze technologie geven? Persoonlijk heb ik een soort innerlijk gevoel dat "dit ondubbelzinnig moet gebeuren, het heeft bepaalde perspectieven." Maar waarom precies, daar bestaat geen duidelijke formulering voor. Als je bijvoorbeeld naar de bestaande gecentraliseerde tools kijkt, dan lopen ze in veel opzichten ver vooruit (stabiliteit, snelheid, beheersbaarheid, enz.). Niettemin heb ik één gedachte die logisch lijkt en die zonder zulke gedecentraliseerde systemen nauwelijks kan worden geïmplementeerd. Natuurlijk zwaai ik te hard, maar ik zou het zo formuleren: het principe van het verspreiden van informatie op internet moet veranderd worden.

Laat het me uitleggen. Als je erover nadenkt, hebben we nu informatie die wordt verspreid volgens het principe: "Ik hoop dat degene aan wie ik het heb gegeven het zal beschermen en dat het niet verloren zal gaan of ontvangen zal worden door degenen voor wie het niet bedoeld was." Het is bijvoorbeeld gemakkelijk om verschillende e-maildiensten, cloudopslag, enz. te overwegen. En waar eindigen we mee? Op Habré-hub Informatiebeveiliging staat aan de eerste lijn en bijna elke dag ontvangen we nieuws over een nieuw mondiaal lek. In principe worden alle interessantste dingen vermeld in <irony> prachtig artikel De zomer is bijna voorbij. Er zijn vrijwel geen ongelekte gegevens meer over. Dat wil zeggen, de belangrijkste internetgiganten worden groter, ze verzamelen steeds meer informatie, en dergelijke lekken zijn een soort informatie-atoomexplosies. Dit is nog nooit eerder gebeurd, en hier is het weer. Tegelijkertijd zullen velen, hoewel ze begrijpen dat er risico's zijn, hun gegevens aan externe bedrijven blijven toevertrouwen. Ten eerste is er niet veel alternatief, en ten tweede beloven ze dat ze alle gaten hebben gedicht en dat dit nooit meer zal gebeuren.

Welke optie zie ik? Het lijkt mij dat gegevens in eerste instantie openlijk moeten worden verspreid. Maar openheid betekent in dit geval niet dat alles gemakkelijk leesbaar moet zijn. Ik heb het over de openheid van opslag en distributie, maar niet over totale openheid bij het lezen. Ik ga ervan uit dat informatie met publieke sleutels moet worden verspreid. Het principe van publieke/private sleutels is immers al oud, bijna net als internet. Als de informatie niet vertrouwelijk is en voor een breed bereik bestemd is, wordt deze direct met een publieke sleutel opgemaakt (maar nog steeds in gecodeerde vorm, iedereen kan deze met de beschikbare sleutel ontsleutelen). En zo niet, dan wordt het zonder een openbare sleutel opgemaakt en wordt de sleutel zelf overgedragen aan wat toegang zou moeten hebben tot deze informatie. Tegelijkertijd zou degene die het zou moeten lezen alleen een sleutel moeten hebben, en waar hij deze informatie kan krijgen, zou hij niet echt moeten stijgen - hij haalt het gewoon uit het netwerk (dit is het nieuwe principe van distributie op basis van inhoud, niet op basis van adres).

Voor een massa-aanval zullen aanvallers dus een groot aantal privésleutels moeten verkrijgen, en het is onwaarschijnlijk dat dit op één plek gebeurt. Deze taak is, zoals ik het zie, moeilijker dan het hacken van een bepaalde dienst.

En hier is een ander probleem opgelost: bevestiging van auteurschap. Nu kun je op internet veel citaten vinden die door onze vrienden zijn geschreven. Maar waar is de garantie dat zij het waren die ze hebben geschreven? Als elk van deze documenten vergezeld zou gaan van een digitale handtekening, zou het veel eenvoudiger zijn. En het maakt niet uit waar deze informatie ligt, het belangrijkste is de handtekening, die natuurlijk moeilijk te vervalsen is.

En dit is wat hier interessant is: IPFS beschikt al over encryptietools (het is tenslotte gebouwd op blockchain-technologie). De privésleutel wordt onmiddellijk gespecificeerd in de configuratie.

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

Ik ben geen beveiligingsspecialist en weet niet precies hoe ik deze correct moet gebruiken, maar het lijkt mij dat deze sleutels worden gebruikt op het niveau van uitwisseling tussen IPFS-knooppunten. En ook js-ipfs en voorbeeldprojecten zoals baan-dbwaarop het werkt orbit.chat. Dat wil zeggen dat in theorie elk apparaat (mobiel en niet alleen) eenvoudig kan worden uitgerust met zijn eigen coderings-decoderingsmachines. In dit geval blijft het alleen aan iedereen om ervoor te zorgen dat zijn privésleutels worden bewaard, en iedereen zal verantwoordelijk zijn voor zijn eigen veiligheid, en niet de gijzelaar zijn van een andere menselijke factor bij een of andere superpopulaire internetgigant.

Alleen geregistreerde gebruikers kunnen deelnemen aan het onderzoek. Inloggen, Alsjeblieft.

Heeft u al eerder over IPFS gehoord?

Ik heb nog nooit van IPFS gehoord, maar het lijkt me interessant
Ik heb het niet gehoord en wil het niet horen
Gehoord maar niet geïnteresseerd
Gehoord, maar niet begrepen, maar nu lijkt het interessant
Ik gebruik IPFS al heel lang actief.

69 gebruikers hebben gestemd. 13 gebruikers onthielden zich van stemming.

Bron: www.habr.com

IPFS zonder pijn (maar dit is niet juist)