IPFS sonder pyn (maar dit is nie akkuraat nie)

IPFS sonder pyn (maar dit is nie akkuraat nie)

Ten spyte van die feit dat Habré reeds was meer as een artikel oor IPFS.

Ek sal dadelik verduidelik dat ek nie 'n kenner op hierdie gebied is nie, maar ek het al meer as een keer belangstelling in hierdie tegnologie getoon, maar om daarmee rond te speel, het dikwels pyn veroorsaak. Vandag het ek weer begin eksperimenteer en 'n paar resultate gekry wat ek graag wil deel. Kortliks, die IPFS-installasieproses en sommige kenmerke sal beskryf word (alles is op ubuntu gedoen, ek het dit nie op ander platforms probeer nie).

As jy gemis het wat IPFS is, word dit hier in detail geskryf: habr.com/en/post/314768

installasie

Vir die suiwerheid van die eksperiment stel ek voor dat u dit onmiddellik op 'n eksterne bediener installeer, aangesien ons 'n paar slaggate sal oorweeg om in plaaslike modus en afgeleë te werk. Dan, as jy wil, sal dit nie vir 'n lang tyd gesloop word nie, daar is nie veel nie.

Installeer go

Amptelike dokumentasie
Sien die huidige weergawe by golang.org/dl

Let wel: dit is beter om IPFS te installeer namens die gebruiker wat veronderstel is om dit die meeste te gebruik. Die feit is dat ons hieronder die opsie van montering via sal oorweeg FUSE en daar is subtiliteite.

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

Dan moet jy die omgewing opdateer (meer besonderhede 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

Kontroleer dat go geïnstalleer is

go version

Installeer IPFS

Ek het die meeste van die installasiemetode gehou ipfs-opdatering.

Installeer dit met die opdrag

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

Daarna kan u die volgende opdragte uitvoer:

ipfs-opdatering weergawes - om alle beskikbare weergawes vir aflaai te sien.
ipfs-opdatering weergawe - om die tans geïnstalleerde weergawe te sien (totdat ons IPFS geïnstalleer het, sal dit geen wees nie).
ipfs-update installeer nuutste - installeer die nuutste weergawe van IPFS. In plaas van die nuutste, onderskeidelik, kan jy enige gewenste weergawe uit die lys van beskikbare spesifiseer.

Installeer ipfs

ipfs-update install latest

Nagaan

ipfs --version

Direk met die installasie in algemene terme alles.

Begin IPFS

Inisialisering

Eerstens moet u inisialisering uitvoer.

ipfs init

In reaksie sal jy iets soos hierdie ontvang:

 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 kan die voorgestelde opdrag uitvoer

ipfs cat /ipfs/QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv/readme

Gevolg

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 begin na my mening die interessante. Die ouens in die installasie stadium begin reeds hul eie tegnologie gebruik. Die voorgestelde hash QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv word nie spesifiek vir jou gegenereer nie, maar in die vrystelling vasgewerk. Dit wil sê, voor die vrystelling het hulle 'n welkomsteks voorberei, dit in IPFS gegooi en die adres by die installeerder gevoeg. Ek dink dit is baie cool. En hierdie lêer (meer presies, die hele gids) kan nou nie net plaaslik bekyk word nie, maar ook op die amptelike poort ipfs.io/ipfs/QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv. Terselfdertyd kan jy seker wees dat die inhoud van die gids op geen manier verander het nie, want as dit verander het, dan sou die hash ook verander het.

Terloops, in hierdie geval het IPFS 'n paar ooreenkomste met die weergawebeheerbediener. As jy veranderinge aan die bronlêers van die gids maak en die gids weer in IPFS gooi, sal dit 'n nuwe adres ontvang. Terselfdertyd sal die ou vouer nêrens heen net so gaan nie en sal dit by sy vorige adres beskikbaar wees.

Direkte bekendstelling

ipfs daemon

Jy behoort 'n antwoord soos hierdie te ontvang:

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

Om die deure na die internet oop te maak

Gee aandag aan hierdie twee reëls:

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

Nou, as jy IPFS plaaslik geïnstalleer het, sal jy toegang tot IPFS-koppelvlakke by plaaslike adresse kry en alles sal vir jou beskikbaar wees (Byvoorbeeld, localhost:5001/webui/). Maar wanneer dit op 'n eksterne bediener geïnstalleer is, is die poorte by verstek vir die internet gesluit. Poorte twee:

  1. webui admin (Github) op poort 5001.
  2. Eksterne API op poort 8080 (leesalleen).

Tot dusver kan beide poorte (5001 en 8080) oopgemaak word vir eksperimente, maar op 'n gevegbediener moet poort 5001 natuurlik met 'n firewall gesluit word. Daar is ook poort 4001, wat nodig is sodat ander eweknieë jou kan vind. Dit moet oopgelaat word vir versoeke van buite.

Maak ~/.ipfs/config oop vir redigering en vind hierdie reëls daarin:

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

Verander 127.0.0.1 na die ip van jou bediener en stoor die lêer, dan herbegin ipfs (stop die lopende opdrag met Ctrl+C en begin dit weer).

Moet kry

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

Nou moet die eksterne koppelvlakke beskikbaar wees.

Tjek

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

Die leesmij-lêer hierbo moet oopmaak.

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

Die webkoppelvlak moet oopmaak.

As webui vir jou werk, dan kan die IPFS-instellings direk daarin verander word, insluitend kykstatistieke, maar hieronder sal ek konfigurasie-opsies direk deur die konfigurasielêer oorweeg, wat oor die algemeen nie krities is nie. Dit is net beter om presies te onthou waar die konfigurasie is en wat om daarmee te doen, anders as die webgesig nie werk nie, sal dit moeiliker wees.

Stel 'n webkoppelvlak op om met u bediener te werk

Hier is die eerste slaggat, wat sowat drie uur geneem het.

As jy IPFS op 'n eksterne bediener geïnstalleer het, maar nie IPFS plaaslik geïnstalleer of laat loop het nie, wanneer jy na /webui in die webkoppelvlak gaan, behoort jy 'n verbindingsfout te sien:

IPFS sonder pyn (maar dit is nie akkuraat nie)

Die feit is dat webui, na my mening, baie dubbelsinnig werk. Eerstens probeer dit om te koppel aan die API van die bediener waar die koppelvlak oop is (natuurlik gebaseer op die adres in die blaaier). en as dit nie daar werk nie, probeer dit om aan die plaaslike poort te koppel. En as jy IPFS plaaslik loop, sal webui goed vir jou werk, net jy sal met plaaslike IPFS werk, en nie ekstern nie, alhoewel jy webui op 'n eksterne bediener oopgemaak het. Dan laai jy die lêers op, maar om een ​​of ander rede sien jy dit nie net so op 'n eksterne bediener nie ...

En as dit nie plaaslik loop nie, kry ons 'n verbindingsfout. In ons geval is die fout heel waarskynlik te wyte aan CORS, wat ook deur webui aangedui word, wat daarop dui dat 'n konfigurasie bygevoeg word.

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

Ek het sopas 'n wildcard geregistreer

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

Die bygevoegde opskrifte kan gevind word in dieselfde ~/.ipfs/config. In my geval is dit

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

Ons herbegin ipfs en ons sien dat webui suksesvol gekoppel is (in elk geval moet dit, as jy die poorte vir versoeke van buite oopmaak, soos hierbo beskryf).

Nou kan jy vouers en lêers direk deur die webkoppelvlak oplaai, asook jou eie vouers skep.

Monteer die FUSE-lêerstelsel

Hier is 'n baie interessante kenmerk.

Lêers (sowel as dopgehou), kan ons nie net deur die webkoppelvlak byvoeg nie, maar ook direk in die terminale, byvoorbeeld

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

Die laaste hash is die hash van die wortelgids.

Deur hierdie hash te gebruik, kan ons 'n gids op enige ipfs-nodus oopmaak (wat ons nodus kan vind en die inhoud kan kry), ons kan in die webkoppelvlak op poort 5001 of 8080, of ons kan plaaslik via ipfs.

ipfs ls QmbnzgRVAP4fL814h5mQttyqk1aUxxxxxxxxxxxxx
QmfYuz2gegRZNkDUDVLNa5DXzKmKVxxxxxxxxxxxxxx 10 test.txt

Maar jy kan dit steeds oopmaak soos 'n gewone gids.

Kom ons skep twee dopgehou by die wortel en gee regte daarvoor aan ons gebruiker.

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

en herbegin ipfs met --mount vlag

ipfs daemon --mount

Jy kan dopgehou op ander plekke skep en die pad na hulle spesifiseer deur die ipfs daemon parameters -mount -mount-ipfs /ipfs_path -mount-ipns /ipns_path

Om nou uit hierdie gids te lees, is ietwat ongewoon.

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

Dit wil sê, daar is geen direkte toegang tot die wortel van hierdie gids nie. Maar jy kan die inhoud kry, met kennis van die hash.

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

Terselfdertyd werk selfs outo-voltooiing binne die gids wanneer die pad gespesifiseer is.

Soos ek hierbo gesê het, is daar subtiliteite met sulke montering: by verstek is gemonteerde FUSE-vouers slegs beskikbaar vir die huidige gebruiker (selfs root sal nie uit so 'n gids kan lees nie, om nie te praat van ander gebruikers in die stelsel nie). As jy hierdie vouers aan ander gebruikers beskikbaar wil stel, moet jy in die konfigurasie "FuseAllowOther": false verander na "FuseAllowOther": true. Maar dit is nie al nie. As u IPFS as root gebruik, is alles in orde. En as dit namens 'n gereelde gebruiker (selfs sudo), dan sal jy 'n fout kry

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

In hierdie geval moet jy /etc/fuse.conf wysig deur die #user_allow_other-reël te verwyder.

Daarna, herbegin ipfs.

Bekende probleme met FUSE

Die probleem is meer as een keer opgemerk dat na die herbegin van ipfs met montering (en miskien in ander gevalle), die /ipfs en /ipns monteerpunte nie beskikbaar is nie. Daar is geen toegang tot hulle nie, en ls -la /ipfs wys ???? in die lys van regte.

Het hierdie oplossing gevind:

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

Herbegin dan ipfs.

Voeg 'n diens by

Natuurlik, hardloop in die terminale is slegs geskik vir aanvanklike toetse. In die gevegsmodus moet die daemon outomaties begin wanneer die stelsel begin.

Skep namens sudo die lêer /etc/systemd/system/ipfs.service en skryf daaraan:

[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 natuurlik met jou gebruiker vervang word (en miskien sal die volledige pad na die ipfs-program vir jou anders wees (jy moet die volledige pad spesifiseer)).

Ons aktiveer die diens.

sudo systemctl enable ipfs.service

Ons begin die diens.

sudo service ipfs start

Kontroleer die status van die diens.

sudo service ipfs status

Vir die suiwerheid van die eksperiment sal dit moontlik wees om die bediener in die toekoms te herlaai om seker te maak dat ipfs outomaties suksesvol begin.

Die toevoeging van bekende aan ons feeste

Oorweeg 'n situasie waar ons IPFS-nodusse op beide 'n eksterne bediener en plaaslik geïnstalleer het. Op 'n eksterne bediener voeg ons 'n lêer by en probeer om dit via IPFS plaaslik deur CID te kry. Wat sal gebeur? Natuurlik weet die plaaslike bediener heel waarskynlik niks van ons eksterne bediener nie en sal bloot probeer om die lêer deur CID te vind deur alle IPFS-eweknieë wat daarvoor beskikbaar is (waarmee dit reeds daarin geslaag het om te "vertroud") te "vra". Dié sal op hul beurt ander vra. En so aan, totdat die lêer gevind word. Eintlik gebeur dieselfde as ons probeer om die lêer deur die amptelike poort te kry ipfs.io. As jy gelukkig is, sal die lêer binne 'n paar sekondes gevind word. En indien nie, sal dit nie eers binne 'n paar minute gevind word nie, wat die gemak van werk grootliks beïnvloed. Maar ons weet waar hierdie lêer die eerste keer sal verskyn. So hoekom sê ons nie dadelik vir ons plaaslike bediener "Soek eers daar" nie? Dit kan blykbaar gedoen word.

1. Ons gaan na die afgeleë bediener en kyk in die ~/.ipfs/config config

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

2. Begin sudo-diens ipfs-status en soek Swarm-inskrywings daarin, byvoorbeeld:

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

3. Ons voeg hieruit die algemene adres van die vorm "/ip4/ip_your_server/tcp/4001/ipfs/$PeerID" by.

4. Vir betroubaarheid sal ons probeer om hierdie adres by eweknieë te voeg deur ons plaaslike webui.

IPFS sonder pyn (maar dit is nie akkuraat nie)

5. As alles in orde is, maak die plaaslike config ~ / .ipfs / config oop, vind “Bootstrap” daarin: [...
en voeg die ontvangde adres eerste by die skikking.

Herbegin IPFS.

Laat ons nou die lêer by die eksterne bediener voeg en probeer om dit op die plaaslike een aan te vra. Moet vinnig vlieg.

Maar hierdie funksionaliteit is nog nie stabiel nie. Sover ek verstaan, selfs al spesifiseer ons die adres van 'n eweknie in Bootstrap, verander ipfs die lys van aktiewe verbindings met eweknieë tydens werking. In elk geval is die bespreking hiervan en wense oor die moontlikheid om permanente feeste te spesifiseer, aan die gang hier en dit lyk soos veronderstel voeg 'n bietjie funksionaliteit by [e-pos beskerm]+

Die lys van huidige eweknieë kan beide in die webui en in die terminale bekyk word.

ipfs swarm peers

En hier en daar kan jy jou fees met die hand byvoeg.

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

Totdat hierdie funksionaliteit verbeter is, kan jy 'n instrument skryf om te kyk vir 'n verbinding met die verlangde eweknie en, indien nie, om 'n verbinding by te voeg.

Redenering

Onder diegene wat reeds met IPFS vertroud is, is daar beide argumente vir en teen IPFS. Basies, gister bespreking en het my aangespoor om weer in IPFS te delf. En met betrekking tot die bespreking hierbo genoem: Ek kan nie sê dat ek enige argument van diegene wat gepraat het, sterk teenstaan ​​nie (ek stem net saam met die feit dat anderhalf programmeerders IPFS gebruik). Oor die algemeen is albei reg op hul eie manier (veral kommentaar oor tjeks laat jou dink). Maar as ons die morele en wetlike assessering verwerp, wie sal 'n tegniese beoordeling van hierdie tegnologie gee? Persoonlik het ek 'n soort innerlike gevoel dat "dit moet onomwonde gedoen word, dit het sekere vooruitsigte." Maar hoekom presies, daar is geen duidelike formulering nie. Soos, as jy na die bestaande gesentraliseerde gereedskap kyk, dan is hulle in baie opsigte ver vooruit (stabiliteit, spoed, hanteerbaarheid, ens.). Nietemin het ek een gedagte wat skynbaar sin maak en wat beswaarlik geïmplementeer kan word sonder sulke gedesentraliseerde stelsels. Ek swaai natuurlik te hard, maar ek sou dit so formuleer: die beginsel van die verspreiding van inligting op die internet moet verander word.

Laat ek verduidelik. As jy daaraan dink, het ons nou inligting versprei volgens die beginsel "Ek hoop dat die een aan wie ek dit gegee het dit sal beskerm en dit sal nie verlore gaan of ontvang word deur diegene aan wie dit nie bedoel was nie." As voorbeeld is dit maklik om verskeie posdienste, wolkbergings, ens. En waarmee eindig ons? Op Habré-hub Inligtings sekuriteit is op die eerste lyn en byna elke dag ontvang ons nuus oor nog 'n wêreldwye lekkasie. In beginsel word al die interessantste dinge in <ironie> wonderlik gelys artikel Die somer is amper verby. Daar is amper geen uitgelek data oor nie. Dit wil sê, die belangrikste internetreuse word groter, hulle versamel meer en meer inligting, en sulke lekkasies is 'n soort inligting-atoomontploffings. Dit het nog nooit vantevore gebeur nie, en hier is dit weer. Terselfdertyd, hoewel baie verstaan ​​dat daar risiko's is, sal hulle voortgaan om hul data aan derdeparty-maatskappye te vertrou. Eerstens is daar nie veel alternatief nie, en tweedens belowe hulle dat hulle al die gate gelap het en dit sal nooit weer gebeur nie.

Watter opsie sien ek? Dit lyk vir my dat data aanvanklik openlik versprei moet word. Maar openheid in hierdie geval beteken nie dat alles maklik moet wees om te lees nie. Ek praat van die openheid van berging en verspreiding, maar nie totale openheid in lees nie. Ek neem aan dat inligting met publieke sleutels versprei moet word. Die beginsel van publieke / private sleutels is immers reeds oud, amper soos die internet. As die inligting nie vertroulik is nie en bedoel is vir 'n wye kring, dan word dit onmiddellik met 'n publieke sleutel uitgelê (maar steeds in geënkripteerde vorm, net enigiemand kan dit met die beskikbare sleutel dekripteer). En indien nie, dan word dit uitgelê sonder 'n publieke sleutel, en die sleutel self word oorgedra na wat toegang tot hierdie inligting moet hê. Terselfdertyd moet die een wat dit moet lees net 'n sleutel hê, en waar om hierdie inligting te kry, moet hy nie regtig sweef nie - hy trek dit net uit die netwerk (dit is die nuwe beginsel van verspreiding volgens inhoud, nie deur adres).

Dus, vir 'n massa-aanval, sal aanvallers 'n groot aantal private sleutels moet kry, en dit sal waarskynlik nie op een plek gedoen word nie. Hierdie taak, soos ek dit sien, is moeiliker as om 'n spesifieke diens te hack.

En hier is nog 'n probleem gesluit: bevestiging van outeurskap. Nou op die internet kan jy baie aanhalings vind wat deur ons vriende geskryf is. Maar waar is die waarborg dat dit hulle was wat dit geskryf het? Nou, as elke sodanige rekord vergesel word van 'n digitale handtekening, sou dit baie makliker wees. En dit maak nie saak waar hierdie inligting lê nie, die belangrikste ding is die handtekening, wat natuurlik moeilik is om te vervals.

En hier is wat hier interessant is: IPFS dra reeds enkripsie-instrumente (dit is immers gebou op blockchain-tegnologie). Die private sleutel word onmiddellik in die konfigurasie gespesifiseer.

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

Ek is nie 'n sekuriteitspesialis nie en kan nie presies weet hoe om dit reg te gebruik nie, maar dit lyk vir my of hierdie sleutels op die vlak van uitruiling tussen IPFS-nodusse gebruik word. En ook js-ipfs en voorbeeldprojekte soos wentelbaan-dbwaarop dit werk wentelbaan.klets. Dit wil sê, teoreties kan elke toestel (mobiel en nie net nie) maklik toegerus word met sy eie enkripsie-dekripsiemasjiene. In hierdie geval bly dit net vir almal om te sorg vir die stoor van hul private sleutels, en almal sal verantwoordelik wees vir hul eie sekuriteit, en nie 'n gyselaar wees van 'n ander menslike faktor op een of ander supergewilde internetreus nie.

Slegs geregistreerde gebruikers kan aan die opname deelneem. Meld aan, asseblief.

Het jy al van IPFS gehoor?

  • Ek het nog nooit van IPFS gehoor nie, maar dit lyk interessant

  • Het nie gehoor nie en wil nie hoor nie

  • Gehoor maar stel nie belang nie

  • Gehoor, maar nie verstaan ​​nie, maar nou lyk dit interessant

  • Ek gebruik IPFS vir 'n lang tyd aktief.

69 gebruikers het gestem. 13 gebruikers het buite stemming gebly.

Bron: will.com

Voeg 'n opmerking