🥇IPFS без болю (але гэта не дакладна)

Нягледзячы на тое, што на Хабры была ўжо не адзін артыкул пра IPFS.

Адразу ўдакладню, што я не з'яўляюся экспертам у гэтай галіне, але не раз выяўляў цікавасць да гэтай тэхналогіі, але спробы пагуляцца з ёй часта выклікала некаторы боль. Сёння я зноў узяўся за эксперыменты і атрымаў сякія-такія вынікі, якімі хацеў бы падзяліцца. Калі сцісла, то будзе апісаны працэс усталёўкі IPFS і некаторыя фішкі (усё выконвалася на ubuntu, на іншых платформах не спрабаваў).

Калі вы прапусцілі што ж такое IPFS, даволі падрабязна напісана тут: habr.com/be/post/314768

Ўстаноўка

Для чысціні эксперыменту прапаную адразу ўсталёўваць на якім-небудзь вонкавым серверы, бо мы будзем разглядаць некаторыя падводныя камяні з працай у лакальным рэжыме і выдаленым. Потым пры жаданні не доўга будзе знесці, тамака не шмат.

Усталёўваны go

Афіцыйная дакументацыя
Актуальную версію глядзіце на golang.org/dl

Заўвага: лепш усталёўваць IPFS ад імя карыстача, якім і мяркуецца найболей частае выкарыстанне. Справа ў тым, што ніжэй мы разгледзім варыянт з мантаваннем праз FUSE і там ёсць тонкасці.

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

Затым трэба абнавіць асяроддзе (падрабязней тут: 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

Правяраем, што go усталяваўся

go version

Усталёўваны IPFS

Мне больш за ўсё спадабаўся спосаб усталёўкі праз ipfs-update.

Усталёўваны яго камандай

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

Пасля гэтага можна выконваць такія каманды:

ipfs-update versions - Каб убачыць усе даступныя версіі для запампоўкі.
ipfs-update version - каб убачыць бягучую ўсталяваную версію (пакуль у нас не ўсталяваная IPFS, будзе none).
ipfs-update install latest - Устанавіць апошнюю версію IPFS. Замест latest адпаведна можна пазначыць любую жаданую версію са спісу даступных.

Усталёўваны ipfs

ipfs-update install latest

правяраем

ipfs --version

Непасрэдна з усталёўкай у агульных рысах усё.

Запуск IPFS

ініцыялізацыя

Для пачатку трэба выканаць ініцыялізацыю.

ipfs init

У адказ вы атрымаеце нешта тыпу такога:

 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

Можна выканаць прапанаваную каманду

ipfs cat /ipfs/QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv/readme

Вынік

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

Вось тут, на мой погляд, ужо пачынаецца цікавае. Дзеці яшчэ на этапе ўстаноўкі ўжо пачынаюць выкарыстоўваць свае ж тэхналогіі. Прапанаваны хэш QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv - не згенераваны спецыяльна для вас, а ўшыты ў рэліз. Гэта значыць да рэлізу яны падрыхтавалі прывітальны тэкст, вылілі яго ў IPFS і адрас дадалі ва ўсталёўнік. Па-мойму, гэта вельмі крута. І гэты файл (дакладней, усю тэчку) зараз можна прагледзець не толькі лакальна, але і на афіцыйным шлюзе ipfs.io/ipfs/QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv. Пры гэтым можна быць упэўненым, што змесціва тэчкі ніяк не мянялася, бо калі б памянялася, то хэш бы таксама памяняўся.

Дарэчы, у дадзеным выпадку IPFS мае некаторае падабенства з серверам кантролю версій. Калі ў зыходныя файлы тэчкі занесці змены і ізноў выліць тэчку ў IPFS, то яна атрымае новы адрас. Пры гэтым старая тэчка нікуды не падзенецца проста так і будзе даступная па сваім ранейшым адрасе.

Непасрэдна запуск

ipfs daemon

Павінны ў адказ атрымаць тып такога:

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

Адкрываем дзверы для Інтэрнэту

Звярніце ўвагу на гэтыя два радкі:

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

Вось калі вы ўсталявалі IPFS у сябе лакальна, тыя вы будзеце да IPFS-інтэрфейсаў звяртацца па лакальных адрасах і вам будзе ўсё даступна (Да прыкладу, лакальны:5001/webui/). Але пры ўсталёўцы на вонкавым серверы па-змаўчанні шлюзы зачыненыя для інтэрнэту. Шлюзаў два:

Адмінка webui (GitHub) на порце 5001.
Вонкавае API на порце 8080 (readonly).

Пакуль для эксперыментаў можна адкрыць абодва порта (5001 і 8080), але на баявым серверы вядома ж порт 5001 трэба было б зачыніць фаервалам. Яшчэ ёсць 4001 порт, ён патрэбен, каб іншыя балі маглі вас знайсці. Яго трэба пакінуць адкрытым для запытаў звонку.

Адкрываем для рэдагавання ~/.ipfs/config і знаходзім у ім гэтыя радкі:

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

Мяняем 127.0.0.1 на ip вашага сервера і захоўваем файл, пасля чаго перазапускаем ipfs (запушчаную каманду спыняем Ctrl+C і зноў запускаем).

Павінны атрымаць

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

Вось зараз вонкавыя інтэрфейсы павінны быць даступныя.

праверце

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

Павінен адкрыцца прыведзены вышэй рыдмі-файл.

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

Павінен адкрыцца вэб-інтэрфейс.

Калі ў вас працуе webui, то налады IPFS можна змяняць прамы ў ім, у тым ліку і праглядаць статыстыку, але ніжэй я буду разглядаць варыянты канфігурацыі менавіта напроста праз файл-канфіг, што ў цэлым не крытычна. Проста лепш запомніць дзе менавіта канфіг ляжыць і што з ім рабіць, а то калі вэб-морда працаваць не будзе, тое будзе ўжо складаней.

Наладжваем вэб-інтэрфейс для працы са сваім серверам

Вось тут першы падводны камень, на які было патрачана гадзіны тры.

Калі вы IPFS усталявалі на вонкавым серверы, але не ўсталёўвалі ці не запускалі IPFS лакальна, то пры заходзе на /webui у вэб-інтэрфейсе вы павінны бачыць памылку падлучэння:

Справа ў тым, што webui, на маю думку, працуе вельмі неадназначна. Спачатку ён спрабуе падлучыцца да API таго сервера, дзе адчынены інтэрфейс (вядома ж засноўваючыся на адрасе ў браўзэры). і калі не атрымліваецца тамака, то спрабуе падлучыцца на лакальны шлюз. І калі ў вас лакальна запушчаны IPFS, то ў вас webui будзе працаваць звычайна, толькі вось працаваць вы будзеце з лакальнай IPFS, а не вонкавай, хоць і адкрылі webui на вонкавым серверы. Потым заліваеце файлы, але чамусьці не бачыце іх проста так на вонкавым серверы…

А калі і лакальна не запушчаны, тое атрымліваем памылку злучэння. У нашым выпадку памылка хутчэй за ўсё з-за CORS, пра што і кажа ў тым ліку webui, прапануючы дадаць канфіг.

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

Я ж у сябе проста wildcard прапісаў

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

Дададзеныя загалоўкі можна знайсці ўсё ў тым жа ~/.ipfs/config. У маім выпадку гэта

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

Перазапускаем ipfs і бачым, што webui паспяхова злучыўся (ва ўсякім разе павінен, калі вы адкрылі шлюзы для запытаў звонку, як і апісана вышэй).

Зараз можна прамы праз вэб-інтэрфейс заліваць тэчкі і файлы, а гэтак жа ствараць свае тэчкі.

Мантаванне файлавай сістэмы FUSE

Вось гэта даволі цікавая фішка.

Файлы (як і тэчкі), мы можам дадаваць не толькі праз вэб-інтэрфейс, але і непасрэдна ў тэрмінале, напрыклад

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

Апошні хэш - гэта хэш каранёвай тэчкі.

Па гэтым хэшу мы можам адкрыць тэчку на любой ipfs-нодзе (якая зможа знайсці нашу ноду і атрымаць змесціва), можам у вэб-інтэрфейсе на порце 5001 ці 8080, а можам лакальна праз ipfs.

ipfs ls QmbnzgRVAP4fL814h5mQttyqk1aUxxxxxxxxxxxxx
QmfYuz2gegRZNkDUDVLNa5DXzKmKVxxxxxxxxxxxxxx 10 test.txt

Але яшчэ можна і як звычайную тэчку адчыняць.

Створым у корані дзве тэчкі і правы на іх падамо нашаму карыстачу.

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

і перазапусцім ipfs са сцягам — mount

ipfs daemon --mount

Можна стварыць тэчкі і ў іншых месцах і паказаць шлях да іх праз параметры ipfs daemon -mount -mount-ipfs /ipfs_path -mount-ipns /ipns_path

Цяпер чытанне з гэтай тэчкі некалькі незвычайнае.

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

Гэта значыць прамога доступу да кораня гэтай тэчкі няма. Але затое можна атрымаць змесціва, ведаючы хэш.

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

Пры гэтым унутры тэчкі нават аўтададатак працуе пры ўказанні шляху.

Як я і казаў вышэй, пры такім мантаванні ёсць тонкасці: па-змаўчанні змантаваныя FUSE-тэчкі даступныя толькі бягучаму карыстачу (нават root не зможа чытаць з такой тэчкі, не кажучы ўжо пра іншых карыстачоў у сістэме). Калі вы жадаеце зрабіць гэтыя тэчкі даступнымі іншым карыстачам, то ў канфігу трэба змяніць "FuseAllowOther": false на "FuseAllowOther": true. Але і гэта яшчэ не ўсё. Калі вы IPFS запускаеце ад імя root, тое ўсё ОК. А калі ад імя звычайнага карыстальніка (хай і sudo), то атрымаеце памылку

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

У такім разе трэба падправіць /etc/fuse.conf, разкамэнтаваўшы радок #user_allow_other.

Пасля гэтага перазапускаем ipfs.

Вядомыя праблемы з FUSE

Не раз была заўважана праблема, што пасля рэстарту ipfs з мантаваннем (а можа і ў іншых выпадках), кропкі мантавання /ipfs і /ipns становяцца недаступныя. Доступу да іх няма ніякага, а ls -la /ipfs паказвае???? у спісе правоў.

Знайшоў такое рашэнне:

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

Пасля чаго рэстартуем ipfs.

Дадаем службу

Вядома ж запуск у тэрмінале падыходзіць толькі для першасных тэстаў. У баявым рэжыме дэман павінен запускацца аўтаматычна пры запуску сістэмы.

Ад імя судна ствараем файл /etc/systemd/system/ipfs.service і запісваем у яго:

[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 вядома ж трэба замяніць на свайго карыстальніка (і магчыма поўны шлях да праграмы ipfs будзе ў вас іншы (указваць трэба менавіта поўны шлях)).

Актывуем службу.

sudo systemctl enable ipfs.service

Запускаем службу.

sudo service ipfs start

Правяраем статут службы.

sudo service ipfs status

Для чысціні эксперыменту можна будзе ў далейшым выдаць сервер, каб праверыць, што ipfs паспяхова стартуе аўтаматычна.

Дадаем вядомыя нам балі

Разгледзім сітуацыю, калі ў нас IPFS ноды ўсталяваны і на вонкавым серверы і лакальна. На вонкавым серверы мы дадаем нейкі файл і спрабуем яго атрымаць праз IPFS лакальна па CID. Што будзе адбывацца? Вядома ж лакальны сервер хутчэй за ўсё нічога не ведае аб вонкавым нашым серверы і будзе проста спрабаваць знайсці файл па CID "пытаючы" ва ўсіх даступных яму IPFS-піраў (з якімі яму ўжо атрымалася "пазнаёміцца"). Тыя ў сваю чаргу будуць у іншых пытацца. І так пакуль файл не будзе знойдзены. Уласна, тое ж самае адбываецца і калі мы спрабуем файл атрымаць праз афіцыйны шлюз. ipfs.io. Калі павязе, то файл будзе знойдзены за некалькі секунд. А калі не, то не будзе знойдзены і за некалькі хвілін, што вельмі моцна б'е па камфорце працы. Але мы вось ведаем дзе гэты файл у першую чаргу з'явіцца. Дык чаму нам адразу не сказаць нашаму лакальнаму серверу «Шукай у першую чаргу там»? Судзячы па ўсім, гэта можна зрабіць.

1. Заходзім на выдалены сервер і ў канфігу ~/.ipfs/config шукаем

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

2. Выконваем sudo service ipfs status і шукаем у ім запісы Swarm, напрыклад:

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

3. Складаем з гэтага агульны адрас выгляду "/ip4/ip_вашага_сервера/tcp/4001/ipfs/$PeerID".

4. Для надзейнасці праз наш лакальны webui паспрабуем дадаць гэты адрас у балі.

5. Калі ўсё ОК, адчыняны лакальны канфіг ~/.ipfs/config, знаходзім у ім «Bootstrap»: […
і дапісваем першым у масіў атрыманы адрас.

Рэстартым IPFS.

Зараз дадамо файл на вонкавы сервер і паспрабуем яго запытаць на лакальным. Павінен заляцець хутка.

Але гэты функцыянал пакуль нестабільны. Наколькі я разумею, нават калі мы паказваем адрас балю ў Bootstrap, падчас прац ipfs змяняе спіс актыўных злучэнняў з балямі. Ва ўсякім разе абмеркаванне гэтага і пажаданні на рахунак магчымасці паказваць сталыя балі вядзецца. тут і накшталт як мяркуецца дадаць нейкі функцыянал у [электронная пошта абаронена]+

Спіс бягучых баляў можна паглядзець як у webui, так і ў тэрмінале.

ipfs swarm peers

І там і там можна дадаць уручную свой баль.

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

Пакуль не палепшылі гэты функцыянал, можна напісаць тулзу, каб правярала наяўнасць злучэння з патрэбным балем і калі не, каб дадавала злучэнне.

Развагі

Сярод тых, хто ўжо знаёмы з IPFS, ёсць як аргументы за IPFS, так і супраць. У прынцыпе, пазаўчарашняе абмеркаванне і заахвоціла мяне яшчэ раз пакапаць IPFS. І вось датычна згаданай дыскусіі: я не магу сказаць, што моцна супраць нейкага прыведзенага довада выказаных (не згодзен толькі з тым, што паўтара праграміста выкарыстаюць IPFS). У цэлым па-свойму маюць рацыю і тыя, і іншыя (асабліва каментар пра чэкі дастаўляе задумацца). Але калі адкінуць маральную і юрыдычную адзнаку, хто якую дасць тэхнічную адзнаку дадзенай тэхналогіі? Асабіста ў мяне нейкае ўнутранае адчуванне ёсць што "гэта трэба адназначна, гэта мае пэўныя перспектывы". Але чаму менавіта, няма дакладнай фармулёўкі. Тыпу калі паглядзець ужо наяўныя цэнтралізаваныя сродкі, то па шматлікіх параметрах яны моцна наперадзе (стабільнасць працы, хуткасць працы, кіравальнасці і да т.п.). Тым не менш у мяне ёсць адна думка, якая быццам мае сэнс і якая наўрад ці можа быць рэалізавана без вось такіх дэцэнтралізаваных сістэм. Вядома, моцна ўжо я замахваюся, але я б сфармуляваў яе так: прынцып распаўсюджвання інфармацыі ў Інтэрнеце трэба памяняць.

Растлумачу. Калі так падумаць, то зараз у нас інфармацыя распаўсюджваецца па прынцыпе "Я спадзяюся, што той, каму я яе перадаў, яе абароніць і яна не будзе страчана або атрымана тым, каму яна не прызначалася". Для прыкладу лёгка разгледзець розныя паштовыя сэрвісы, хмарныя сховішчы і да т.п. І што мы маем у выніку? На Хабры хаб Інфармацыйная бяспека стаіць на першым радку і практычна кожны дзень мы атрымліваем навіны пра чарговую глабальную ўцечку. У прынцыпе, усё самае цікавае пералічана ў <іронія>выдатнай артыкуле Лета амаль скончылася. Ці не ўцяклі дадзеных амаль не засталося. Гэта значыць асноўныя інтэрнэт-гіганты становяцца ўсё буйней, акумулююць яны ў сябе ўсё больш інфармацыі, і падобныя ўцечкі - гэта свайго роду інфармацыйныя атамныя выбухі. Ніколі такога не было, і вось зноў. Пры гэтым, хоць многія разумеюць, што рызыкі ёсць, працягнуць давяраць свае дадзеныя іншым кампаніям. Па-першае, альтэрнатывы асабліва няма, а па-другое, тыя абяцаюць, што залаталі ўсе дзіркі і больш такога ніколі не паўторыцца.

Які ж мне бачыцца варыянт? Як мне падаецца, дадзеныя першапачаткова павінны распаўсюджвацца адкрыта. Але адкрытасць у дадзеным выпадку - гэта не значыць, што ўсё павінна лёгка чытацца. Я кажу пра адкрытасць захоўвання і распаўсюджванні, але не татальную адкрытасць у чытанні. Я мяркую, што інфармацыя павінна распаўсюджвацца з адчыненымі ключамі. Бо прынцып адчыненых/зачыненых ключоў ужо стары, практычна як Інтэрнэт. Калі інфармацыя не канфідэнцыйная і разлічана на шырокае кола, то яна выкладваецца адразу з адкрытым ключом (але ўсё роўна ў зашыфраваным выглядзе, проста яе любы можа расшыфраваць наяўным ключом). А калі не, то выкладваецца без адкрытага ключа, а сам ключ перадаецца таму, што павінен мець доступ да гэтай інфармацыі. Пры гэтым той, хто павінен яе прачытаць, павінен мець толькі ключ, а дзе ўзяць гэтую інфармацыю, яго не павінна асоба парыць - ён проста яе цягне з сеткі (гэта і ёсць новы прынцып распаўсюджвання па змесціва, а не па адрасе).

Такім чынам, зламыснікам для масавага нападу трэба будзе атрымаць велізарную колькасць зачыненых ключоў, і ці наўрад гэта атрымаецца зрабіць у адным месцы. Гэтая задача, як мне бачыцца, складаней, чым узламаць нейкі пэўны сэрвіс.

І тут жа закрываецца яшчэ адна праблема: пацвярджэнне аўтарства. Цяпер у інтэрнэце можна знайсці мноства цытат, напісаных нашымі знаёмымі. Але ж дзе гарантыя, што менавіта яны іх пісалі? Вось калі б кожны такі запіс суправаджаўся лічбавым подпісам, то было б значна прасцей. І не важна дзе гэтая інфармацыя ляжыць, галоўнае - подпіс, які, загадзя, складана падрабіць.

І вось што тут цікава: IPFS ужо нясе ў сабе сродкі шыфравання (бо ён пабудаваны на тэхналогіі блокчейн). У канфігу адразу пазначаны прыватны ключ.

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

Я не спецыяліст па бяспецы і не магу дакладна ведаць як гэта правільна выкарыстоўваць, але мне здаецца, што на ўзроўні абмену паміж IPFS-нодамі гэтыя ключы выкарыстоўваюцца. А яшчэ js-ipfs і такія праекты-прыклады як orbit-db, на якой працуе orbit.chat. Гэта значыць тэарытычна кожная прылада (мабільная і не толькі) можа быць лёгка абсталяванае сваімі шыфравальна-дэшыфравальнымі машынамі. У такім выпадку застанецца толькі кожнаму паклапаціцца аб захаванні сваіх прыватных ключоў і кожны сам будзе адказны за сваю бяспеку, а не быць заложнікам чарговага чалавечага фактару на якім-небудзь суперпапулярным інтэрнэт-гіганце.

Толькі зарэгістраваныя карыстачы могуць удзельнічаць у апытанні. Увайдзіце, Калі ласка.

Ці чулі вы раней пра IPFS?

Ніколі не чуў пра IPFS, але быццам цікава
Не чуў і не хачу чуць
Чуў, але так і не зацікавіла
Чуў, але не зразумеў, а зараз быццам цікава
Даўно ўжо актыўна выкарыстоўваю IPFS

Прагаласавалі 69 карыстальнікаў. Устрымаліся 13 карыстальнікаў.

Крыніца: habr.com

IPFS без болю (але гэта не дакладна)