Не смотря на то, что на Хабре была уже не одна статья про IPFS.
Сразу уточню, что я не являюсь экспертом в этой области, но не раз проявлял интерес к этой технологии, но попытки поиграться с ней часто вызывало некоторую боль. Сегодня я опять взялся за эксперименты и получил кое-какие результаты, которыми хотел бы поделиться. Если коротко, то будет описан процесс установки IPFS и некоторые фишки (все выполнялось на ubuntu, на других платформах не пробовал).
Если вы пропустили что же такое IPFS, довольно подробно написано здесь: habr.com/ru/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!
--¬------¬ -------¬-------¬
--¦--г==--¬--г====---г====-
--¦------г------¬ -------¬
--¦--г===- --г==- L====--¦
--¦--¦ --¦ -------¦
L=-L=- L=- L======-
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-интерфейсам обращаться по локальным адресам и вам будет все доступно (К примеру, localhost: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/40013. Складываем из этого общий адрес вида "/ip4/ip_вашего_сервера/tcp/4001/ipfs/$PeerID".
4. Для надежности через наш локальный webui попробуем добавить этот адрес в пиры.
5. Если все ОК, открываем локальный конфиг ~/.ipfs/config, находим в нем «Bootstrap»: […
и дописываем первым в массив полученный адрес.
Рестартим IPFS.
Теперь добавим файл на внешний сервер и попробуем его запросить на локальном. Должен залететь быстро.
Но этот функционал пока нестабилен. Насколько я понимаю, даже если мы указываем адрес пира в Bootstrap, в процессе работы ipfs меняет список активных соединений с пирами. Во всяком случае обсуждение этого и пожелания на счет возможности указывать постоянные пиры ведется здесь и вроде как предполагается добавить какой-то функционал в ipfs@5.0+
Список текущих пиров можно посмотреть как в 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. То есть теоритически каждое устройство (мобильное и не только) может быть легко оснащено своими шифровально-дешифровальными машинами. В таком случае останется только каждому позаботиться о сохранении своих приватных ключей и каждый сам будет ответственнен за свою безопасность, а не быть заложником очередного человеческого фактора на каком-нибудь супер-популярном интернет-гиганте.
Комментарии (36)
Umpiro
31.08.2019 14:351. В голосовании не хватает моего варианта: 'Заинтересовался недавно'.)
2.
И здесь же закрывается еще одна проблема: подтверждение авторства.
Я настаиваю на том, что это — не проблема, а фича интернета.
3. Хочу узнать знаком ли автор с проектом swarm. Если я правильно понял, это какой-то аналог ipfs, но c 'активной' раздачей данных.
Fi1osof Автор
31.08.2019 14:38В голосовании не хватает моего варианта: 'Заинтересовался недавно'.)
Пункт «Никогда не слышал про IPFS, но вроде интересно» как раз это подразумевал.
Я настаиваю на том, что это — не проблема, а фича интернета.
Я не говорю, что я истину глаголю. Просто мое видение.
3. Хочу узнать знаком ли автор с проектом swarm. Если я правильно понял, это какой-то аналог ipfs, но c 'активной' раздачей данных.
С ним особо не знаком, но на сколько я понимаю, IPFS как раз на этой технологии и построен. Ведь коннект как раз на swarm строится.Umpiro
31.08.2019 15:15Я не говорю, что я истину глаголю. Просто мое видение.
Я не обвиняю вас в неистинности. Только подчеркиваю, что здесь ipfs, в вашем лице, идет против утверждения 'Искусство принадлежит интернету.'
При этом тот, кто должен ее прочитать, должен иметь только ключ, а где взять эту информацию, его не должно особо парить — он просто ее тянет из сети (это и есть новый принцип распространения по содержимому, а не по адресу).
Таким образом, в ipfs-сети сама информация тут же становится достпна всем, нужно только подобрать ключ. В то время как в классической схеме 'злоумышленнику' нужно еще и суметь перехватить эту информацию.
Также вопрос от падавана. Что такое в ipfs 'gateway' и чем оно отлично от 'node'?
ivan386
01.09.2019 16:52+1Gateway локальный шлюз узла через который по HTTP протоколу предоставляет доступ браузеру или другой программе к файлам в сети IPFS.
То есть можно запустив локально узел IPFS открыть в браузере http://127.0.0.1:8080/ipns/ipfs.io и увидеть ту же страницу что на https://ipfs.io только это уже будет ваша локальная копия.
Fi1osof Автор
01.09.2019 18:45Только подчеркиваю, что здесь ipfs, в вашем лице, идет против утверждения 'Искусство принадлежит интернету.'
Так никто же не заставляет подписывать. Речь о праве подписать и зашифровать, если информация предполагается для какого-то определенного получателя, а не для всех. К слову, это может быть полезно и для бизнеса. На конференции компании ActiveCloud (не реклама) они рассказывали о своем программном продукте индивидуальных подписей для документов. Типа ставишь прогу и когда распечатываешь документ для передаче другой стороне, прога генерит определенные метки на документе (какие-нибудь точки) и добавляет их при печати. В результате, если где-то вскрывается факт утечки документов, можно по этим меткам определить кому именно передавались бумажные копии и предъявы гнать.
Так же и здесь, подписал для определенного получателя, и если где-то утечка вскрылась, то можно понять через кого.
Таким образом, в ipfs-сети сама информация тут же становится достпна всем, нужно только подобрать ключ. В то время как в классической схеме 'злоумышленнику' нужно еще и суметь перехватить эту информацию.
Я не смог найти, но на хабре недавно была статья про принцип шифрования данных, при котором скрывается сам факт шифрования. То есть информация передается в открытом виде и кажется, что она не несет ничего важного в себе, но на самом деле ее надо просто суметь расшифровать.
В данном случае у хакеров другая проблема имеется: определение ценности информации. Представьте, что вам досталось несколько ТБ шифрованной информации, при чем сами по себе файлы по несколько кило весят (то есть их реально много) и все они подписаны разными ключами. Для вас помимо самой задачи взлома возникает еще и задача определения ценности хранимой информации. Вы можете потратить несколько недель работы суперкомпьютера для взлома файла, в котором вы прочитаете «Hello world». Стоит ли овчинка выделки? Если бы все так просто было бы, то тот же Ethereum ломали бы вдоль и поперек, а там понятно где что ценное, еще и на многие миллионы баксов.Umpiro
01.09.2019 13:14Для вас помимо самой задачи взлома возникает еще и задача определения ценности хранимой информации.
Данная задача существует всегда, на стадии перехвата информации. Так что не думаю, что ipfs тут что-то меняет.Fi1osof Автор
01.09.2019 14:29Так речь-то была не в том, что для данной задачи требуется именно IPFS. Это могло бы быть на уровне любых других средств хранения и обработки данных. Но в классической модели как правило шифруют только пароль (конечно же без обратного шифрования). Я же предполагаю, что хорошо бы шифровать любую конфиденциальную информацию. И IPFS для этого, на мой взгляд, просто лучше подходит, потому что сразу есть средства шифрования. И при внесении информации не надо никак персонализироваться (один из вариантов). Персонализация идет на уровне открытых/закрытых ключей.
Umpiro
01.09.2019 15:10И IPFS для этого, на мой взгляд, просто лучше подходит, потому что сразу есть средства шифрования.
О каком средстве шифрования речь? Если вы о CID, то это не шифрование — это обфурскация, как я понимаю.Fi1osof Автор
01.09.2019 17:28На сколько я понимаю, IPFS активно использует libp2p.io
libp2p в свою очередь заявляет:
Encrypted Connections
Ensure that no one can eavesdrop on user traffic by setting a crypto channel by default, protecting both bits and validating peer identities.
Конечно, если пользователь заходит на сторонний шлюз и через него заливает какую-то информацию, без дополнительных средств последнее идентифицированное звено будет пир, которому принадлежит шлюз. Но если мы говорим о том, что есть js-ipfs и каждое устройство можно превратить в шлюз, то тогда можно и конечных пользователей идентифицировать (не говорю про персональные данные, если он их не слил, а просто идентификация личного пира).
Когда мы выполняем ipfs init, если мы не указали приватный ключ, то идентификатор пира создается случайный.
"Identity": {
"PeerID": "QmS57Jv8o7UT.........................",
"PrivKey": "CAASqgkwgg........................"
},
Но, можно инициировать пир с имеющимся приватным ключом, и если с ним все ОК, то и PeerID будет соответствующий. Таким образом, при обмене информацией между пирами можно проверять тот ли это пир, за кого себя выдает.
P.S. уже после того, как я это написал, пошел и нашел вот такой пример у них: github.com/libp2p/js-libp2p/tree/master/examples/encrypted-communications
Кажется, он подтверждает мои предположения.
Umpiro
02.09.2019 14:07Я полагал, речь идет о шифровании данных, а не соединений. Последнее, согласитесь, тоже не новость. Кроме того, если подумать, какой смысл имеет шифрование данных в сети, которая ориентирована на их пресохранение и свободное распространение?
Fi1osof Автор
02.09.2019 14:32На счет шифрования самих данных там наверняка тоже что-то есть (я не настолько хорошо изучил все). Хотя не факт.
А шифрование данных в сети имеет смысл, чтобы гарантировать авторство. Ведь просто получение данных по CID гарантирует, что они не были изменены, но нет подтверждение, что это кем-то конкретным написано (например, чтобы авторство подтвердить).Umpiro
02.09.2019 15:19нет подтверждение, что это кем-то конкретным написано
Мне кажется, в случае p2p это не может быть задачей протокола передачи данных. Подтверждение целостности данных — да, но подтверждение авторства содержимого — это уже совсем другая тема.
ED: Т.е. как я уже замечал, ipfs, конечно, упрощает вторую задачу. Но никак не гарантирует ее решение.
ED2: В любом случае, мы заболтались. Давайте лучше договоримся o CID нашего списка пиратского контента в ipfs. И посвященного ему телеграм-чатика.)Fi1osof Автор
02.09.2019 16:20Телегу не люблю (как и ватсап). Анонимность при регистрации через свой номер телефона — сказочный бред :)
Списков чего-либо пиратского тоже не могу предоставить, нет у меня в наличии :)Umpiro
02.09.2019 16:48Телегу не люблю (как и ватсап).
Как же вы тогда собираетесь передавать CIDы файлов адресатам? Через яндекс-почту?)
Списков чего-либо пиратского тоже не могу предоставить, нет у меня в наличии :)
Потому и предлагаю составить. Пока по ipfs не начнет гулять архив порнхаба, никто им (ipfs) всерьез не заинтересуется.) Кэширование веб-сраничек это, конечно, тоже хорошо. Но, как скажут обычные пользователи, нас и сейчас неплохо кормят.Fi1osof Автор
02.09.2019 17:13Я не планировал развивать пиратскую сеть :) Но если говорить в принципе о канале распространения, то это скорее всего мало чем будет отличаться от того же рутрекера, то есть будут некие сайты, которые будут у себя аккумулировать CIDы с описаниями и поиск по ним.
Пока по ipfs не начнет гулять архив порнхаба
Сорри, а зачем архив порнхаба? Можно же просто на порнхаб зайти (мне друг рассказывал).Umpiro
02.09.2019 17:36это скорее всего мало чем будет отличаться от того же рутрекера
Я просто имел в виду, что это удобный способ популяризации технологии. Все-таки, все ее преимущества и недостатки не получится ощутить кроме как на практике. А 'архив порнхаба' — это, конечно, условность.Fi1osof Автор
02.09.2019 17:41У меня нет четких За и Против, и я не планирую тратить кучу сил на популяризацию (и тем более воевать с ветряными мельницами). Но есть какой-то интерес, поэтому время от времени ковыряю. Но там много подводных камней, поэтому решил заметку оставить как часть из них обойти и не споткнуться. Более никакого сакрального смысла в написании статьи не было. Время рассудит, жить этой технологии или умереть.
ivan386
02.09.2019 17:42+1Как же вы тогда собираетесь передавать CIDы файлов адресатам?
Можно через pubsub.
Например: Создание децентрализованного музыкального плеера на IPFS
Umpiro
02.09.2019 21:48Почти то, что надо.
ED: Только до конца пока непонятно, как оно будет работать. Authorized keys для доступа к печати сообщений… Кто их будет раздавать?ivan386
02.09.2019 22:26Сейчас любой может писать в любой канал.
На сколько я понимаю чтобы создать канал с ограниченными правами надо создать блок в котором будут ID ключей тех кто может писать в этот канал.
Хэш от этого блока будет идентификатором канала.
Но это вроде не реализованно ещё. Да и реализовать можно уже на уровне приложения.
Umpiro
03.09.2019 13:25Сейчас любой может писать в любой канал.
Вы знаете, за что прикрыли 8chan? А данная pubsub система похожа на глобольную p2p имиджборду. Нужно еще посмотреть, пропустят ли ее без цензуры.
Это помимо других, технических вопросов.Fi1osof Автор
03.09.2019 14:04По-моему, пропустят или нет — вопрос не уместный. pubsub запускается на уровне конечных нод. Это контролировать никто особо не может.
Umpiro
03.09.2019 16:39Мне кажется, вы недооцениваете ситуацию. Сейчас на англоязычных ресурсах слово 'ненависть' сродне 'коммунизму', а о том, что она заполонила интернет кричат на каждом углу. И принимают меры, как видите. Как только выяснится, что очередная группа школьников, ученивших стрельбу в каком-то там штате использовала какой-то там ipfs для огранизации своих действий, разрабов тут же возьмут за мягкое. И в следующей версии протокола никаких pubsub'ов уже не будет. В лучшем случае. В худшем — админы гитхаба потрут весь ipfs проект.
Fi1osof Автор
03.09.2019 17:53И потрут форки у пользователей, в том числе слитые на конечные компьютеры?
Umpiro
03.09.2019 17:59И форки потрут. А вы думаете не смогут? Локальные версии, в рамках современных механизмов, конечно останутся. Но много ли от этого будет толку? Хотя, даже сейчас, при правильном использовании социальных технологий, из любого X можно сделать прокаженного, так что от слитых копий будут избавляться самостоятельно.
lowtechomega
31.08.2019 14:58С огромным трудом и многоминутными задержками опубликованные файлы можно скачать как через шлюз в инете так и локальные (даже если он есть и виден у сотни пиров). Для передачи и распространения файлов — пока совсем непригода. Работает как тор, когда он только появился, даже еще хуже. Надеюсь что будет лучше.
Вообще для винды есть десктоп версия, с установкой в один клик — несколько проще (в разы) поставить чтобы поиграть github.com/ipfs-shipyard/ipfs-desktop
И да, автору, ipfs — НЕ на блокчейне совершенно не грама. При чем тут бч вообще? Если вы правильно прочитали, то ipfs хорошее хранилище для blockchains (вследствие дедупликации).Fi1osof Автор
01.09.2019 19:10С огромным трудом и многоминутными задержками опубликованные файлы можно скачать как через шлюз в инете так и локальные (даже если он есть и виден у сотни пиров). Для передачи и распространения файлов — пока совсем непригода.
Не могу согласиться. В статье я показывал, что можно пиры вручную добавлять. В итоге я на локал с удаленного сервера скачал почти 500 метров менее чем за минуту. Когда они доработают функционал установки постоянных связей с известными пирами, проблем вообще не должно возникать.
Вообще для винды есть десктоп версия, с установкой в один клик — несколько проще (в разы) поставить чтобы поиграть github.com/ipfs-shipyard/ipfs-desktop
Да, этой статьи можно было и не писать. Уже полно подобных решений. Но как вы и сами говорите, все работает не так хорошо, как хотелось бы. Вот так да, если поставить готовое в один клик, то вероятнее всего не будет работать так хорошо, как хотелось бы. А если разобраться поглубже и чуть подкрутить, то вроде получается уже неплохо.
И да, автору, ipfs — НЕ на блокчейне совершенно не грама. При чем тут бч вообще? Если вы правильно прочитали, то ipfs хорошее хранилище для blockchains (вследствие дедупликации).
Спорить особо не буду, но как-то очень уж похоже на блокчейн. Сравните даже файлы:
ls -la ~/.ethereum/geth/nodes
total 7008
drwxr-xr-x 2 root root 4096 Aug 31 16:01 .
drwxr-xr-x 5 root root 4096 Aug 31 16:01 ..
-rw-r--r-- 1 root root 41849 Aug 31 16:06 006124.log
-rw-r--r-- 1 root root 2125544 Aug 31 16:01 006126.ldb
-rw-r--r-- 1 root root 2124220 Aug 31 16:01 006127.ldb
-rw-r--r-- 1 root root 1492543 Aug 31 16:01 006128.ldb
-rw-r--r-- 1 root root 16 Aug 31 16:01 CURRENT
-rw-r--r-- 1 root root 16 Aug 31 16:01 CURRENT.bak
-rw-r--r-- 1 root root 0 Jul 4 04:44 LOCK
-rw-r--r-- 1 root root 300742 Aug 31 16:01 LOG
-rw-r--r-- 1 root root 1049695 Aug 24 23:31 LOG.old
-rw-r--r-- 1 root root 1320 Aug 31 16:01 MANIFEST-006125
ls -la ~/.ipfs/datastore
итого 392
drwxr-xr-x 2 fi1osof www-data 4096 авг 31 11:57 .
drwxr-xr-x 8 fi1osof www-data 4096 авг 31 11:49 ..
-rw-r--r-- 1 fi1osof www-data 66312 авг 31 18:49 000727.log
-rw-r--r-- 1 fi1osof www-data 105393 авг 31 11:57 000729.ldb
-rw-r--r-- 1 fi1osof www-data 16 авг 31 11:49 CURRENT
-rw-r--r-- 1 fi1osof www-data 16 авг 31 11:49 CURRENT.bak
-rw-r--r-- 1 fi1osof www-data 0 дек 30 2017 LOCK
-rw-r--r-- 1 fi1osof www-data 193854 авг 31 11:57 LOG
-rw-r--r-- 1 fi1osof www-data 1181 авг 31 11:57 MANIFEST-000728
Сходство видно невооруженным глазом.
И keystore присутствует и там и там. И на сайте у них говорится
Blockchains
IPFS lets you address large amounts of data and place the immutable, permanent links into blockchain transactions. This timestamps and secures content without having to put the data itself on the chain.
И в webui
Кажется мне, все-таки там в какой-то мере блокчейн (как технология) все-таки присутствует.lowtechomega
01.09.2019 19:22Руками добавлять пиры, ну както не очень, DHT всеж, тем более она все их видит (inspect). Не могу понять почему не cloudflare не шлюз не могут сами их добавлять быстро. Да если 20 раз релоад страницы делать, то иногда она отдается, НО эффект неустойчив.
Блок эфира там для примера размещен чтобы можно было посмотреть как он эффективно по пирам разложен.
Вот по точнее немного, БЧ в ipfs это похожая концепция и не более (хотя сравнение не очень уместное, названия однако похожи, ipfs также можно назвать большим распределенным гросбухом, но не блокчейном:
«Blockchain uses decentralization concept and also consider to be the distributed ledger technology, where as the ipfs also utilize the same look alike concept “Distributed Hash Table” on Peer to peer decentralized network.»
Да от БЧ там блоки, которые по пирам разложены — в этом есть сходство, но они не дублируются — в этом принципиальное отличие. Когда шариш файл — он НЕ заливается в сеть, он делится на блоки и вычисляется какие из них уже присутствуют.
vlad9486
01.09.2019 20:10Спорить особо не буду, но как-то очень уж похоже на блокчейн. Сравните даже файлы:
Это база данных. Кажется, RocksDB. Они просто используют ту же самую базу данных. У меня личный проект (нету там блокчейна) тоже с этой базой и файлы такие же самые.Fi1osof Автор
01.09.2019 12:13Информация из вики.
Блокче?йн (англ. blockchain[1], изначально block chain[2]) — выстроенная по определённым правилам непрерывная последовательная цепочка блоков (связный список), содержащих информацию. Чаще всего копии цепочек блоков хранятся на множестве разных компьютеров независимо друг от друга.
Впервые термин появился как название полностью реплицированной распределённой базы данных, реализованной в системе «Биткойн», из-за чего блокчейн часто относят к транзакциям в различных криптовалютах, однако технология цепочек блоков может быть распространена на любые взаимосвязанные информационные блоки[3].
Здесь тоже цепочка блоков, распределенная на разных устройствах. Как мне видится, это все-таки блокчейн. Криптовалюты построены на блокчейне, а не блокчейн на криптовалютах. Я не говорил, что это основано на какой-то криптовалюте. Но вот судя по всему это самый что ни на есть блокчейн.vlad9486
01.09.2019 16:15Я писал о файлах. Такие файлы создает база данных RocksDB. Эти файлы ничего не говорят о том блокчейн там, или нет. Если кроме файлов других аргументов за блокчейн нет, то я очень сомневаюсь что в ipfs есть блокчейн. В их описании ничего такого я не нашел.
Fi1osof Автор
01.09.2019 17:34Порыл еще. Выяснил, что в работе IPFS активно используется ipld.io.
На главной страничке у них сразу картинка, которая вроде как как бы намекает.
Плюс к этому сиды формируются на основе base58btc.
Но в целом, скорее всего все это не принципиально, что на чем основано и что это напоминает. Пусть это будет не блокчейн, работать от этого оно не станет по-другому.
JekaMas
Хорошая штука. Активно пользуем в мессенджере для сохранения данных пользователя, с шифрованием конечно. Отклики положительные — можно восстановить данные где и как угодно при сохранности ключей.