고통 없는 IPFS(그러나 이것은 정확하지 않음)

Habré가 이미 존재했다는 사실에도 불구하고 IPFS에 관한 하나 이상의 기사.

제가 이 분야의 전문가는 아니라는 점을 바로 밝히겠습니다. 하지만 저는 이 기술에 여러 번 관심을 보였지만, 이 기술을 가지고 놀려고 하면 종종 약간의 고통을 겪었습니다. 오늘 저는 다시 실험을 시작했고 공유하고 싶은 몇 가지 결과를 얻었습니다. 간단히 말해서 IPFS 설치 프로세스와 일부 기능에 대해 설명합니다(모든 것은 우분투에서 수행되었으며 다른 플랫폼에서는 시도하지 않았습니다).

IPFS가 무엇인지 놓치셨다면 여기에 자세히 설명되어 있습니다. habr.com/en/post/314768

설치

실험의 순수성을 위해 외부 서버에 즉시 설치하는 것이 좋습니다. 로컬 모드와 원격 작업 시 발생할 수 있는 몇 가지 함정을 고려할 것이기 때문입니다. 그러면 원한다면 오랫동안 철거되지 않을 것이며 많지 않습니다.

설치 이동

공식 문서
현재 버전을 확인하세요. golang.org/dl

참고: IPFS를 가장 자주 사용할 사용자를 대신하여 IPFS를 설치하는 것이 좋습니다. 사실 아래에서는 다음을 통해 장착하는 옵션을 고려할 것입니다. 퓨즈 그리고 미묘함이 있습니다.

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 업데이트.

명령으로 설치하세요.

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

그 후에는 다음 명령을 실행할 수 있습니다.

ipfs 업데이트 버전 - 다운로드 가능한 모든 버전을 보려면
ipfs 업데이트 버전 - 현재 설치된 버전을 확인합니다(IPFS가 설치될 때까지는 버전이 없습니다).
ipfs-update 최신 설치 - 최신 버전의 IPFS를 설치합니다. 최신 버전 대신 사용 가능한 버전 목록에서 원하는 버전을 지정할 수 있습니다.

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/). 그러나 외부 서버에 설치하면 기본적으로 게이트웨이는 인터넷에 닫혀 있습니다. 게이트웨이 XNUMX:

1. webui 관리자(github) 포트 5001에서.
2. 포트 8080의 외부 API(읽기 전용)

지금은 실험을 위해 두 포트(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 설정을 직접 변경할 수 있지만 아래에서는 일반적으로 중요하지 않은 구성 파일을 통해 직접 구성 옵션을 고려할 것입니다. 구성이 정확히 어디에 있는지, 어떻게 해야 하는지 기억하는 것이 더 낫습니다. 그렇지 않으면 웹 인터페이스가 작동하지 않으면 더 어려워질 것입니다.

서버에서 작동하도록 웹 인터페이스 설정

여기에 약 XNUMX시간이 걸린 첫 번째 함정이 있습니다.

외부 서버에 IPFS를 설치했지만 IPFS를 로컬로 설치하거나 실행하지 않은 경우 웹 인터페이스에서 /webui로 이동하면 연결 오류가 표시됩니다.

사실 webui는 매우 모호하게 작동한다고 생각합니다. 먼저 인터페이스가 열려 있는 서버의 API에 연결을 시도합니다(물론 브라우저의 주소를 기준으로). 거기서 작동하지 않으면 로컬 게이트웨이에 연결을 시도합니다. IPFS를 로컬로 실행하는 경우 webui는 제대로 작동합니다. 외부 서버에서 webui를 열더라도 외부가 아닌 로컬 IPFS로만 작업할 수 있습니다. 그런 다음 파일을 업로드했지만 어떤 이유로 외부 서버에서 그 파일을 볼 수 없습니다…

로컬로 실행되고 있지 않으면 연결 오류가 발생합니다. 우리의 경우 오류는 webui에서도 표시되는 CORS로 인해 발생했을 가능성이 높으며 구성 추가를 제안합니다.

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

방금 와일드카드를 등록했어요

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

--mount 플래그를 사용하여 ipfs를 다시 시작합니다.

ipfs daemon --mount

다른 위치에 폴더를 생성하고 ipfs 데몬 매개변수 -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 폴더는 현재 사용자만 사용할 수 있습니다(시스템의 다른 사용자는 말할 것도 없고 루트도 해당 폴더에서 읽을 수 없습니다). 이 폴더를 다른 사용자가 사용할 수 있게 하려면 구성에서 "FuseAllowOther": false를 "FuseAllowOther": true로 변경해야 합니다. 하지만 그게 전부는 아닙니다. IPFS를 루트로 실행하면 모든 것이 정상입니다. 그리고 일반 사용자(Sudo도 포함)를 대신하면 오류가 발생합니다.

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

이 경우 #user_allow_other 행의 주석 처리를 제거하여 /etc/fuse.conf를 편집해야 합니다.

그 후 ipfs를 다시 시작하세요.

FUSE의 알려진 문제

마운트를 사용하여 ipfs를 다시 시작한 후(다른 경우에도) /ipfs 및 /ipns 마운트 지점을 사용할 수 없게 되는 문제가 여러 번 발견되었습니다. 이에 대한 액세스가 없으며 ls -la /ipfs는 ????를 표시합니다. 권리 목록에 있습니다.

이 솔루션을 찾았습니다.

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

그런 다음 ipfs를 다시 시작합니다.

서비스 추가

물론 터미널에서 실행하는 것은 초기 테스트에만 적합합니다. 전투 모드에서는 시스템 시작 시 데몬이 자동으로 시작되어야 합니다.

sudo를 대신하여 /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 노드가 설치된 상황을 생각해 보세요. 외부 서버에서 일부 파일을 추가하고 CID를 통해 로컬로 IPFS를 통해 가져오려고 합니다. 무슨 일이 일어날 것? 물론 로컬 서버는 외부 서버에 대해 전혀 알지 못할 가능성이 높으며 사용 가능한 모든 IPFS 피어(이미 "알게 된")에게 "질문"하여 CID로 파일을 찾으려고 시도할 것입니다. 그들은 차례로 다른 사람들에게 물어볼 것입니다. 그리고 파일을 찾을 때까지 계속됩니다. 실제로 공식 게이트웨이를 통해 파일을 얻으려고 할 때도 같은 일이 발생합니다 ipfs.io. 운이 좋으면 몇 초 안에 파일을 찾을 수 있습니다. 그렇지 않으면 몇 분 후에도 발견되지 않아 작업 편의성에 큰 영향을 미칩니다. 하지만 우리는 이 파일이 처음으로 나타날 위치를 알고 있습니다. 그렇다면 로컬 서버에 "먼저 검색하세요"라고 즉시 알려주는 것이 어떨까요? 분명히 이것은 가능합니다.

1. 원격 서버로 이동하여 구성에서 ~/.ipfs/config를 찾습니다.

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

2. sudo service ipfs status를 실행하고 Swarm 항목을 찾습니다. 예를 들면 다음과 같습니다.

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

3. 여기에 "/ip4/ip_your_server/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를 사용한다는 사실에만 동의하지 않습니다). 일반적으로 둘 다 나름대로 옳습니다 (특히 수표에 대한 의견 생각하게 만듭니다). 하지만 도덕적, 법적 평가를 버리면 누가 이 기술에 대한 기술적 평가를 하게 될까요? 개인적으로 저는 "이것은 분명하게 이루어져야 하며 확실한 전망이 있습니다"라는 일종의 내면적인 느낌을 가지고 있습니다. 그런데 왜 정확히 명확한 공식이 없습니다. 예를 들어, 기존 중앙 집중식 도구를 살펴보면 여러 측면(안정성, 속도, 관리 효율성 등)에서 훨씬 앞서 있습니다. 그럼에도 불구하고, 나는 그러한 분산형 시스템 없이는 거의 구현될 수 없고 타당해 보이는 한 가지 생각을 가지고 있습니다. 물론 너무 세게 휘두르고 있지만 이렇게 공식화하겠습니다. 인터넷에서 정보를 전파하는 원칙이 바뀌어야합니다.

설명하겠습니다. 이렇게 생각해보면 지금 우리는 “내가 준 사람이 지켜주기를 바라며, 의도하지 않은 사람이 잃어버리거나 받지 않기를 바란다”는 원칙에 따라 정보를 배포하고 있습니다. 예를 들어 다양한 이메일 서비스, 클라우드 스토리지 등을 고려하기 쉽습니다. 그리고 결국 우리는 무엇을 갖게 됩니까? 허브 온 하브레 정보 보안 는 첫 번째 라인에 있으며 거의 ​​매일 우리는 또 다른 글로벌 유출에 대한 뉴스를 받습니다. 원칙적으로 가장 흥미로운 것들은 모두 <아이러니하게도> 멋진 항목에 나열되어 있습니다. 기사 여름이 거의 끝났습니다. 유출된 데이터가 거의 남아 있지 않습니다.. 즉, 주요 인터넷 거대 기업은 점점 더 커지고 있으며 점점 더 많은 정보를 축적하고 있으며 이러한 유출은 일종의 정보 원자 폭발입니다. 이전에는 이런 일이 없었는데 이번에도 이런 일이 발생했습니다. 동시에 많은 사람들이 위험이 있다는 것을 이해하지만 계속해서 자신의 데이터를 제XNUMX자 회사에 맡길 것입니다. 첫째, 대안이 많지 않고, 둘째, 모든 구멍을 메웠으며 이런 일이 다시는 일어나지 않을 것이라고 약속합니다.

어떤 옵션이 표시되나요? 처음에는 데이터가 공개적으로 배포되어야 한다고 생각합니다. 그러나 이 경우 개방성이 있다고 해서 모든 것이 읽기 쉬워야 한다는 의미는 아닙니다. 나는 저장과 유통의 개방성을 말하는 것이지 독서의 완전한 개방성을 말하는 것은 아닙니다. 나는 정보가 공개 키를 사용하여 배포되어야 한다고 가정합니다. 결국 공개/개인 키의 원칙은 이미 인터넷과 마찬가지로 오래되었습니다. 정보가 기밀이 아니며 폭넓은 범위를 대상으로 하는 경우 공개 키를 사용하여 즉시 배치됩니다(그러나 여전히 암호화된 형식이므로 누구나 사용 가능한 키를 사용하여 해독할 수 있습니다). 그렇지 않은 경우 공개 키 없이 배치되고 키 자체는 이 정보에 액세스할 수 있는 대상으로 전송됩니다. 동시에, 그것을 읽어야 하는 사람은 키만 가지고 있어야 하며, 이 정보를 어디서 얻을 수 있는지는 실제로 급등해서는 안 됩니다. 그는 단지 네트워크에서 정보를 가져오는 것뿐입니다(이것은 콘텐츠별 배포의 새로운 원칙입니다. 주소).

따라서 대규모 공격의 경우 공격자는 엄청난 수의 개인 키를 확보해야 하며, 이는 한 곳에서 완료될 가능성이 거의 없습니다. 제가 보기에 이 작업은 특정 서비스를 해킹하는 것보다 더 어렵습니다.

그리고 여기서 또 다른 문제가 해결됩니다. 저자 확인입니다. 이제 인터넷에서 우리 친구들이 쓴 많은 인용문을 찾을 수 있습니다. 그러나 그것을 쓴 사람이 바로 그들이라는 보장은 어디에 있습니까? 이제 그러한 각 기록에 디지털 서명이 수반된다면 훨씬 쉬울 것입니다. 그리고 이 정보가 어디에 있는지는 중요하지 않습니다. 가장 중요한 것은 서명이며, 물론 위조가 어렵습니다.

여기서 흥미로운 점은 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 그리고 다음과 같은 예시 프로젝트 궤도-db그것이 작동하는 곳 궤도.채팅. 즉, 이론적으로 각 장치(모바일뿐만 아니라)에는 자체 암호화-복호화 시스템을 쉽게 장착할 수 있습니다. 이 경우 개인 키를 저장하는 것은 모든 사람에게만 남아 있으며 모든 사람은 자신의 보안에 대한 책임이 있으며 일부 슈퍼 인기 인터넷 거대 기업에서 다른 인적 요소의 인질이되지 않습니다.

등록된 사용자만 설문 조사에 참여할 수 있습니다. 로그인제발

IPFS에 대해 들어본 적이 있나요?

• IPFS에 대해 들어본 적이 없지만 흥미로운 것 같습니다.

• 들어본 적도 없고 듣고 싶지도 않은

• 들었지만 관심이 없음

• 들었지만 이해하지 못했지만 지금은 흥미로워 보입니다.

• 저는 오랫동안 IPFS를 적극적으로 사용해 왔습니다.

69명의 사용자가 투표했습니다. 13명의 사용자가 기권했습니다.

출처 : habr.com