🥇IPFS zonder pijn (maar dat is niet zeker)

Ondanks dat er al verschillende artikelen over IPFS op Habr zijn verschenen, is er niet één enkele..

Ik wil meteen verduidelijken dat ik geen expert op dit gebied ben, maar ik heb meerdere keren interesse getoond in deze technologie. Mijn pogingen om ermee te experimenteren hebben vaak wat pijn veroorzaakt. Vandaag ben ik weer aan de slag gegaan met experimenteren en heb ik een paar resultaten behaald die ik graag wil delen. Kort gezegd zal ik het installatieproces van IPFS beschrijven en enkele functies uitleggen (alles is uitgevoerd op Ubuntu; op andere platformen heb ik het niet geprobeerd).

Als je gemist hebt wat IPFS precies is, is het hier vrij uitgebreid beschreven: habr.com/ru/post/314768

Installatie

Voor de zuiverheid van het experiment stel ik voor om direct op een externe server te installeren, omdat we enkele valkuilen met lokaal en op afstand werken zullen bespreken. Het verwijderen daarvan is later eenvoudig, dus geen probleem.

Installeer Go

De officiële documentatie
De actuele versie vind je op golang.org/dl

Opmerking: het is beter om IPFS te installeren als de gebruiker die het meeste gebruik zal maken van de software. Dit omdat we hieronder een optie met montage via FUSE bespreken, en daar zijn ook enkele nuances.

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 je de omgeving updaten (meer hierover 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

Controleer of Go is geïnstalleerd

go version

Installeer IPFS

De installatie via ipfs-update.

is mijn favoriete manier om het te installeren met het commando

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

Daarna kun je de volgende commando's uitvoeren:

ipfs-update versions — om alle beschikbare versies voor download te zien.
ipfs-update version — om de huidige geïnstalleerde versie te zien (aangezien we IPFS nog niet hebben geïnstalleerd, zal er none staan).
ipfs-update install latest — om de laatste versie van IPFS te installeren. In plaats van latest kun je ook elke gewenste versie uit de beschikbare lijst opgeven.

Installeer IPFS

ipfs-update install latest

Controleer

ipfs --version

In grote lijnen is de installatie hiermee afgerond.

Start IPFS

Initialisatie

Als eerste moet je de initialisatie uitvoeren.

ipfs init

Als reactie krijg 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

Je kunt het voorgestelde commando uitvoeren

ipfs cat /ipfs/QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv/readme

Resultaat

Hallo en Welkom bij IPFS!

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

Als je dit ziet, dan heb je succesvol IPFS geïnstalleerd
en ben je nu aan het communiceren met de ipfs merkledag!

 -------------------------------------------------------
| Waarschuwing:                                         |
|   Dit is alpha software. Gebruik op eigen risico!    |
|   Er ontbreekt veel of het ontbreekt aan verfijning.   |
|   Er zijn bugs. Nog niet veilig. Lees de beveiligingsnotities voor meer. |
 -------------------------------------------------------

Bekijk een aantal andere bestanden in deze directory:

  .\/about
  .\/help
  .\/quick-start     <-- gebruiksvoorbeelden
  .\/readme          <-- dit bestand
  .\/security-notes

Wat hier gebeurt, wordt naar mijn mening interessant. Het team begint al met het toepassen van hun eigen technologieën tijdens de installatie. De voorgestelde hash QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv — is niet speciaal voor jou gegenereerd, maar ingebouwd in de release. Met andere woorden, ze hebben de welkomsttekst voorbereid, deze naar IPFS geüpload en het adres aan de installer toegevoegd. Ik vind dit echt geweldig. En dit bestand (eigenlijk de hele map) kan nu niet alleen lokaal, maar ook op de officiële gateway worden bekeken. ipfs.io/ipfs/QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv. Hierbij kan je er zeker van zijn dat de inhoud van de map niet is veranderd, want als het veranderd zou zijn, dan zou de hash ook zijn veranderd.

Trouwens, in dit geval vertoont IPFS enige gelijkenis met een versiebeheerserver. Als er wijzigingen in de bronbestanden van de map worden aangebracht en de map opnieuw naar IPFS wordt geüpload, krijgt deze een nieuw adres. De oude map zal dan niet zomaar verdwijnen en zal beschikbaar blijven op het oude adres.

Directe uitvoering

ipfs daemon

Je zou zoiets als dit moeten krijgen:

ipfs daemon
Initializing daemon...
go-ipfs versie: 0.4.22-
Repo versie: 7
Systeem versie: amd64/linux
Golang versie: go1.12.7
Swarm luisterend op /ip4/x.x.x.x/tcp/4001
Swarm luisterend op /ip4/127.0.0.1/tcp/4001
Swarm luisterend op /ip6/::1/tcp/4001
Swarm luisteren naar /p2p-circuit
Swarm aankondigen /ip4/127.0.0.1/tcp/4001
Swarm aankondigen /ip6/::1/tcp/4001
API-server luisterend op /ip4/127.0.0.1/tcp/5001
WebUI: http://127.0.0.1:5001/webui
Gateway (alleen-lezen) server luisterend op /ip4/127.0.0.1/tcp/8080
Daemon is klaar

De deuren voor het internet openen

Let op deze twee regels:

WebUI: http://127.0.0.1:5001/webui
Gateway (alleen-lezen) server luisterend op /ip4/127.0.0.1/tcp/8080

Als je IPFS lokaal hebt geïnstalleerd, dan zul je de IPFS-interfaces via lokale adressen benaderen en zal alles beschikbaar zijn (Bijvoorbeeld, localhost:5001/webui/). Maar wanneer u het op een externe server installeert, zijn de gateways standaard geblokkeerd voor internet. Er zijn twee gateways:

Admin pagina webui (github) op poort 5001.
Externe API op poort 8080 (alleen-lezen).

Voor experimenten kunnen we beide poorten (5001 en 8080) openen, maar op de productie-server moet poort 5001 natuurlijk worden geblokkeerd door de firewall. Er is ook poort 4001, die nodig is zodat andere peers u kunnen vinden. Deze moet open blijven voor externe aanvragen.

We openen voor bewerking ~/.ipfs/config en zoeken deze regels:

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

We veranderen 127.0.0.1 in het IP-adres van uw server en slaan het bestand op, waarna we ipfs opnieuw starten (de lopende opdracht stoppen met Ctrl+C en opnieuw starten).

U zou moeten krijgen

...
WebUI: http://ip_uw_server:5001/webui
Gateway (alleen-lezen) server luistert op /ip4/ip_uw_server/tcp/8080

Nu zouden de externe interfaces toegankelijk moeten zijn.

Controleer

http://domein_of_ip_server:8080/ipfs/QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv/readme

Het bovenstaande readme-bestand moet geopend worden.

http://domein_of_ip_server:5001/webui/

De webinterface moet geopend worden.

Als uw webui werkt, kunt u de IPFS-instellingen direct daar wijzigen, inclusief het bekijken van statistieken, maar hieronder zal ik configuratie-opties rechtstreeks via het configuratiebestand bespreken, wat over het algemeen niet kritiek is. Het is gewoon beter om te onthouden waar de configuratie zich bevindt en wat ermee te doen, anders, als de webinterface niet werkt, wordt het moeilijker.

We configureren de webinterface om met uw server te werken

Hier is de eerste valkuil waar ongeveer drie uur aan besteed is.

Als u IPFS op een externe server heeft geïnstalleerd, maar IPFS niet lokaal heeft geïnstalleerd of uitgevoerd, dan zou u een verbindingsfout moeten zien bij het openen van /webui in de webinterface:

Het probleem is dat webui, naar mijn mening, nogal dubbelzinnig werkt. Eerst probeert het verbinding te maken met de API van de server waar de interface is geopend (uiteraard gebaseerd op het adres in de browser). En als dat niet lukt, probeert het verbinding te maken met de lokale gateway. En als u IPFS lokaal uitvoert, zal uw webui normaal werken, maar u werkt dan met de lokale IPFS in plaats van de externe, ook al heeft u webui op de externe server geopend. Dan uploadt u bestanden, maar ziet u ze om de een of andere reden gewoon niet op de externe server...

En als lokaal niet gestart, krijgen we een verbindingsfout. In ons geval is de fout waarschijnlijk te wijten aan CORS, wat ook door de webui wordt aangegeven, en die vraagt om de configuratie toe te voegen.

ipfs config --json API.HTTPHeaders.Access-Control-Allow-Origin '["http://ip_uw_server: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 gewoon een wildcard ingesteld.

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

De toegevoegde headers kunnen allemaal worden gevonden in dezelfde ~/.ipfs/config. In mijn geval is dat

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

We herstarten ipfs en zien dat de webui succesvol is verbonden (in ieder geval zou dat moeten, als je de gateways voor externe aanvragen hebt geopend, zoals hierboven beschreven).

Nu kunnen we rechtstreeks via de webinterface mappen en bestanden uploaden en ook onze eigen mappen maken.

FUSE-bestandssysteem koppelen

Dit is een vrij interessante functie.

We kunnen bestanden (net als mappen) niet alleen via de webinterface toevoegen, maar ook rechtstreeks in de terminal, bijvoorbeeld

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

De laatste hash is de hash van de hoofdmap.

Met deze hash kunnen we de map openen op elke ipfs-node (die onze node kan vinden en de inhoud kan verkrijgen), kunnen we in de webinterface op poort 5001 of 8080, of lokaal via ipfs.

ipfs ls QmbnzgRVAP4fL814h5mQttyqk1aUxxxxxxxxxxxxx
QmfYuz2gegRZNkDUDVLNa5DXzKmKVxxxxxxxxxxxxxx 10 test.txt

Maar je kunt het ook als een gewone map openen.

Laten we twee mappen aanmaken in de hoofdmap en deze rechten geven aan onze gebruikers.

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

en herstart ipfs met de vlag --mount

ipfs daemon --mount

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

Het lezen van deze map is nu iets ongewone.

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

Dat betekent dat er geen directe toegang is tot de root 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

Binnen de map werkt zelfs de autocomplete bij het opgeven van het pad.

Zoals ik eerder zei, zijn er bij deze montage enkele nuances: standaard zijn de gemonteerde FUSE-mappen alleen toegankelijk voor de huidige gebruiker (zelfs root kan niet lezen van zo'n map, laat staan andere gebruikers in het systeem). Als je deze mappen toegankelijk wilt maken voor andere gebruikers, moet je in de configuratie "FuseAllowOther": false veranderen in "FuseAllowOther": true. Maar daarmee is het nog niet alles. Als je IPFS als root uitvoert, is alles in orde. Maar als je het uitvoert als een gewone gebruiker (zelfs met sudo), krijg je een foutmelding.

mount helper error: fusermount: optie allow_other is alleen toegestaan als 'user_allow_other' is ingesteld in /etc/fuse.conf

In dat geval moet je /etc/fuse.conf aanpassen door de regel #user_allow_other te decommentariëren.

Daarna herstarten we ipfs.

Bekende problemen met FUSE

Het is meerdere keren opgemerkt dat na het herstarten van ipfs met montage (en misschien ook in andere gevallen), de mountpoints /ipfs en /ipns ontoegankelijk worden. Er is geen toegang, en ls -la /ipfs toont ???? in de rechtenlijst.

Ik vond de volgende oplossing:

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

Daarna herstarten we ipfs.

Een dienst toevoegen

Natuurlijk is het draaien in de terminal alleen geschikt voor de eerste tests. In een productieomgeving moet de daemon automatisch starten bij het opstarten van het systeem.

Als sudo maak je het bestand /etc/systemd/system/ipfs.service aan en schrijf je erin:

[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 moet je natuurlijk vervangen door je eigen gebruiker (en mogelijk is het volledige pad naar het programma ipfs bij jou anders (je moet precies het volledige pad opgeven)).

Activeer de dienst.

sudo systemctl enable ipfs.service

Start de dienst.

sudo service ipfs start

Controleer de status van de dienst.

sudo service ipfs status

Voor de netheid van het experiment kan het later nuttig zijn om de server opnieuw op te starten, om te controleren of ipfs automatisch succesvol opstart.

Voeg de bekende peers toe

Laten we de situatie bekijken waarin we IPFS-nodes hebben geïnstalleerd, zowel op een externe server als lokaal. Op de externe server voegen we een bestand toe en proberen we het lokaal via IPFS op te halen met CID. Wat zal er gebeuren? Natuurlijk weet de lokale server waarschijnlijk niets van onze externe server en zal het gewoon proberen het bestand te vinden via CID door ‘te vragen’ aan alle beschikbare IPFS-peers waarmee het al kennis heeft gemaakt. Die peers zullen op hun beurt anderen vragen. En zo voort, totdat het bestand is gevonden. Dit gebeurt ook wanneer we proberen het bestand op te halen via de officiële gateway. ipfs.io. Als we geluk hebben, wordt het bestand binnen enkele seconden gevonden. En als dat niet zo is, dan kan het zelfs enkele minuten duren voordat het gevonden wordt, wat de werkcomfort aanzienlijk beïnvloedt. Maar wij weten waar dit bestand in eerste instantie zal verschijnen. Waarom zeggen we dan niet meteen tegen onze lokale server: ‘Zoek in de eerste plaats daar’? Vermoedelijk kan dat.

1. Log in op de externe server en zoek in het configuratiebestand ~\/ipfs\/config.

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

2. Voer sudo service ipfs status uit en kijk naar de Swarm-gegevens, bijvoorbeeld:

Swarm announcing \/ip4\/ip_uw_server\/tcp\/4001

3. We stellen hieruit een algemeen adres samen van de vorm ‘\/ip4\/ip_uw_server\/tcp\/4001\/ipfs\/$PeerID’.

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

5. Als alles goed is, openen we het lokale configuratiebestand ~\/ipfs\/config, zoeken we naar ‘Bootstrap’: […
en voegen we het verkregen adres als eerste toe aan de array.

We herstarten IPFS.

Nu voegen we een bestand toe op de externe server en proberen we het op de lokale server aan te roepen. Het zou snel moeten binnenkomen.

Maar deze functionaliteit is voorlopig instabiel. Voor zover ik begrijp, zelfs als we het adres van de peer in Bootstrap aangeven, verandert ipfs tijdens het werk de lijst van actieve verbindingen met peers. Hoe dan ook, er wordt gediscussieerd over dit onderwerp en het verzoek om de mogelijkheid te hebben om constante peers op te geven. hier En het lijkt erop dat wordt vermoed er enige functionaliteit aan ipfs@5.0+ toegevoegd kan worden.

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

ipfs swarm peers

En in beide gevallen kunt u handmatig uw peer toevoegen.

ipfs swarm connect "\/ip4\/ip_uw_server\/tcp\/4001\/ipfs\/$PeerID"

Totdat deze functionaliteit verbeterd is, kunt u een tool schrijven die controleert of er een verbinding is met de benodigde peer en, als dat niet zo is, de verbinding toevoegt.

Overpeinzingen

Onder degenen die al bekend zijn met IPFS, zijn er zowel argumenten voor als tegen IPFS. In principe heeft het me aan het denken gezet. discussie en heeft me aangezet om nogmaals naar IPFS te kijken. Wat betreft de genoemde discussie: ik kan niet zeggen dat ik sterk tegen een van de aangevoerde argumenten ben (ik ben het alleen niet eens met de bewering dat anderhalf programmeurs IPFS gebruiken). Over het algemeen hebben zowel de een als de ander hun punt (vooral de opmerking over de cheques doet je nadenken). Maar als we de morele en juridische evaluatie opzijzetten, wat voor technische evaluatie kan deze technologie krijgen? Persoonlijk heb ik een soort intern gevoel dat "dit is absoluut nodig, dit heeft zeker toekomstperspectieven". Maar waarom precies, heb ik geen duidelijke formulering. Als je kijkt naar de al bestaande gecentraliseerde middelen, dan liggen ze op veel parameters ver voor (stabiliteit, snelheid, beheersbaarheid, enzovoort). Desondanks heb ik een idee dat eigenlijk logisch lijkt en dat waarschijnlijk niet gerealiseerd kan worden zonder zulke gedecentraliseerde systemen. Natuurlijk reken ik mijzelf niet te groot op, maar ik zou het zo formuleren: het principe van informatieverspreiding op het internet moet veranderd worden.

Ik leg het uit. Als je er zo over nadenkt, dan verspreidt informatie zich nu op basis van het principe ‘Ik hoop dat degene aan wie ik het heb doorgegeven, het zal beschermen en dat het niet verloren zal gaan of in verkeerde handen zal vallen’. Een gemakkelijk voorbeeld zijn verschillende e-maildiensten, cloudopslag, enzovoort. En wat hebben we uiteindelijk? Op Habré is Informatiebeveiliging de nummer één en bijna elke dag krijgen we nieuws over weer een wereldwijde datalek. In principe is alles wat interessant is opgesomd in een geweldige artikel. De zomer is bijna voorbij. Bijna geen gegevens zijn verloren gegaan.Dat wil zeggen, de grote internetgiganten worden steeds groter, akkumulerend steeds meer informatie bij zichzelf, en dergelijke datalekken zijn een soort informatie-atomische explosies. Dit is nog nooit eerder gebeurd, en hier zijn we weer. Terwijl, hoewel velen begrijpen dat er risico's zijn, ze blijven hun gegevens aan derde partijen toevertrouwen. Ten eerste zijn er nauwelijks alternatieven, en ten tweede beloven zij dat ze alle gaten hebben gedicht en dat dit nooit meer zal gebeuren.

Welke optie zie ik voor me? Ik denk dat gegevens in eerste instantie open 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 verspreiding, maar niet over totale openheid in het lezen. Ik veronderstel dat informatie met open sleutels moet worden verspreid. Het principe van open/gesloten sleutels is immers al oud, zo oud als het internet. Als de informatie niet vertrouwelijk is en bedoeld is voor een breed publiek, wordt deze meteen met een open sleutel gepubliceerd (maar nog steeds in een versleutelde vorm, zodat iedereen deze kan ontsleutelen met de beschikbare sleutel). En als dat niet het geval is, wordt het zonder een open sleutel gepubliceerd en wordt de sleutel gegeven aan degene die toegang tot deze informatie moet hebben. Degene die het moet lezen, moet alleen de sleutel hebben, en hij hoeft zich niet veel zorgen te maken over waar hij deze informatie vandaan haalt — hij haalt het gewoon uit het netwerk (dit is het nieuwe principe van verspreiding op inhoud, en niet op adres).

Dus voor aanvallers zou het nodig zijn om een enorme hoeveelheid gesloten sleutels te verkrijgen om een massale aanval uit te voeren, en het is onwaarschijnlijk dat dit op één plek kan worden gedaan. Deze taak lijkt me moeilijker dan het inbreken in een specifieke service.

En hier sluit nog een probleem zich aan: bevestiging van auteurschap. Op dit moment zijn er op internet veel citaten te vinden die door onze bekenden zijn geschreven. Maar waar is de garantie dat zij deze daadwerkelijk hebben geschreven? Als elke dergelijke opname echter werd vergezeld van een digitale handtekening, zou het veel eenvoudiger zijn. Het maakt niet uit waar deze informatie is opgeslagen, het belangrijkste is de handtekening die per definitie moeilijk te vervalsen is.

En wat hier interessant is: IPFS bevat al encryptiemethoden (want het is gebouwd op blockchain-technologie). In de configuratie is meteen de privé-sleutel opgegeven.

  "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 dit correct te gebruiken, maar het lijkt erop dat deze sleutels worden gebruikt op het niveau van de uitwisseling tussen IPFS-knooppunten. En bovendien js-ipfs en projecten zoals orbit-db, waarop orbit.chaten draait. Dat betekent dat elk apparaat (mobiel of niet) theoretisch gewoon kan worden uitgerust met zijn eigen encryptie- en decryptiemachines. In dat geval moet iedereen gewoon zorgen voor de beveiliging van zijn privésleutels en is iedereen zelf verantwoordelijk voor zijn eigen veiligheid, in plaats van een slachtoffer te zijn van de volgende menselijke factor bij een superpopulaire internetgigant.

Alleen geregistreerde gebruikers kunnen deelnemen aan de enquête. Log in, alstublieft.

Heeft u eerder over IPFS gehoord?

Nooit van IPFS gehoord, maar het lijkt interessant.
Ik heb er niet van gehoord en wil er ook niks van weten.
Ik heb er wel van gehoord, maar het interesseerde me niet.
Ik heb erover gehoord, maar begreep het niet, en nu lijkt het interessant.
Ik gebruik IPFS al een tijd actief.

69 gebruikers hebben gestemd. 13 gebruikers hebben zich onthouden.

Bron: habr.com