지금은 문서에서 찾을 수 없지만 다음 줄에 대한 설명은 기억합니다.
IPFS는 파일 시스템이며 파일 시스템의 경우 URL이 아닌 경로를 사용합니다. URL은 로컬 시스템과 원격 시스템에 대한 액세스 통합 실패를 나타내는 추악함으로 이해할 수 있습니다. IPFS는 로컬 및 원격 파일을 동일하게 취급하여 이러한 추악함을 피하고 있으며 파일 주소 지정 방법은 표준 경로입니다.

/ipfs 아래에 전체 IPFS를 탑재하고 다음과 같이 파일에 액세스하는 것을 상상하는 것이 도움이 될 수 있습니다. 파일 시스템의 파일.

추가 읽을거리:

긴 토론: https://github.com/ipfs/go-ipfs/issues/1678
현재 합의에 대한 간략한 요약: https://github.com/ipfs/go-ipfs/issues/1678#issuecomment -157478515

또한 표준 URL 확인으로 IPFS 절대 주소를 조정 하고 fs: 경로를 사용하거나 사용하지 않고 출처를 식별하는 문제를 해결하기 위한 작업이 진행 중입니다.

그리고 https://github.com/ipfs/in-web-browsers/issues/28 및 초안 사양에 대한 링크가 있습니다. cc @lgierth

:( ipfs/go-ipfs#1678 을 읽은 후 더 이상 IPFS에 관심이 있는지 확신이 서지 않습니다.

나는 정말로 자전거 창고에 들어가기를 원하지 않지만 이것은

It might help to imagine mounting the entire IPFS under /ipfs and then accessing the files like they are just that: Files in your file system.
나를 흥분시키는 아이디어가 아닙니다. 갑자기 다음과 같은 시스템 루트가 있다고 상상해보십시오.
/btrfs/dev/sda1/.. /fat32/dev/sda2/.. /ext3/dev/sda3/boot/..

그것은 나에게 어필하는 개념이 아닙니다. 나는 내가 좋아하는 방식으로 시스템을 구성하고 내가 선택한 대로 파일 시스템을 마운트하는 데 익숙합니다. 그러나 그것이 정말로 나를 화나게 하는 것이 아닙니다. 원하는 곳에 ipfs를 자유롭게 마운트할 수 있습니다. 나는 과대망상증적인 "모든 것을 재창조하자"는 접근 방식에 실망했습니다. 분산 CAS를 원했기 때문에 IPFS에 왔습니다. 그게 내가 관심을 가졌던 전부다. 나는 유닉스를 웹과 병합하는 데 관심이 없다. 그러나 그 토론을 읽은 후 IPFS는 더 이상 분산 CAS를 얻는 데 도움이 되는 제품처럼 보이지 않습니다. 그것은 제가 컴퓨터의 파일 시스템을 사용하고 이름을 지정하는 방법을 지시하는 제품처럼 보이며 일단 작성자가 한 가지를 지시하면 아마도 그들은 내 컴퓨터를 구성하고 구성하는 방법에 대한 몇 가지 다른 새로운 아이디어. 미래를 예측할 수는 없지만 접근 방식이 마음에 들지 않습니다.

IPFS의 분산 CAS 구현이 정말 마음에 듭니다. 나는 오랫동안 분산 CAS를 갖는 것을 꿈꿔 왔습니다 :(. 그래서 연구 모드로 돌아가서 다른 분산 CAS를 살펴봐야 합니다...

@timthelion 저처럼 CAS와 IPFS에 관심이 많으신 것 같습니다.
고객님의 걱정을 덜어드릴 수 있도록 최선을 다하겠습니다.

나는 당신이 IPFS를 시스템의 어느 곳에도 장착하지 않고 CAS로 사용할 수 있다고 확신합니다.
/ipfs/Qm.. 경로에 대해 생각하는 방식은 일반 URL과 마찬가지로 대화와 연결을 단순화하는 정신적 지름길이라는 것입니다.

개인적으로 나는 "프로토콜 핸들러"와 "정규 주소 의미론" 상황이 지금 당장은 방관자에게 엉망으로 보일 수 있다는 데 동의하지만, 좋은 사람들이 실용적인 솔루션을 연구하고 있으므로 지금 당장은 효과가 있을 수 있습니다(예: https://github.com/ ipfs/in-web-browsers/issues/3, https://github.com/ipfs/in-web-browsers/issues/7).

이것은 지속적인 대화이며 이러한 일에는 시간이 걸립니다.

프로젝트의 일반적인 방향(내 개인적인 의견)은 _"무슨 일이 있어도 모든 것을 재창조"하기보다는 _"실용적인 경우 산업 표준을 재사용하는 유용한 도구를 만드는 것"_입니다.

미래에 대해 걱정할 필요는 없다고 생각합니다. IPFS 도구는 _"유닉스 방식"_을 따릅니다. 즉, 한 가지 작업을 수행하는 많은 작은 도구, 라이브러리 및 명령( git 하위 명령과 유사)을 함께 연결하여 더 큰 것을 만들 수 있습니다.

어떤 조각을 사용할지는 당신이 결정합니다. ⚙️ 🔧

아무도 내 마지막 게시물을 잘못된 방식으로 받아들이지 않기를 바랍니다. "너희 모두는 내가 떠나는 개자식아"라는 말을 하려는 것이 아닙니다. 수천 명의 사람들이 IPFS를 살펴보고 마음에 들지 않는 것이 있다고 결정하고 이유를 쓰지 않고 떠났습니다. 저는 종종 그렇게 합니다. 나는 그저 아무렇지 않게 기술을 보고 잘못된 방식으로 나를 문지르는 작은 세부 사항을 기반으로 다른 기술을 선택합니다. 침묵하는 다수의 침묵하는 의원이 되고 싶지 않고, 또 선택의 여지가 많지 않기 때문에 하지 않기로 결정했습니다 :D 하지만 기다려야 할 것 같습니다. 현재 프로젝트에서 ipfs 사용을 시작하기 전에 fs:// 또는 프로젝트 헤드가 선택하는 모든 것을 지원하기 위해 ipfs를 사용하고 일부 실제 일반 URL이 존재할 때까지 진지하게 IPFS 보기를 시작할 수 있을 것입니다.

나는 과대망상증적인 "모든 것을 재창조하자"는 접근 방식에 거부감을 느낍니다.

당신은 도취되고 있었고, 이것에 대한 어떤 것도 '과대망상증'이나 심지어 재발명도 아닙니다. 우리는 항상 그대로 사용되는 파일 경로에 대해 이야기하고 있습니다. /ipfs에 마운트하는 것은 핵심 아이디어가 아니라 사물을 설명하기 위한 예시일 뿐입니다.

나는 내가 좋아하는 방식으로 시스템을 구성하고 내가 선택한 대로 파일 시스템을 마운트하는 데 익숙합니다.

아무도 IPFS를 로컬 파일 시스템 @timthelion 으로 마운트하도록 강요하지 않습니다. 이것은 사용할 수 있는 기능이며 마운트 경로를 결정할 수 있습니다. 기본적으로 비활성화된 기능을 싫어한다는 것은 IPFS를 전체적으로 무시해야 하는 약한 이유처럼 들립니다. 하지만 앞으로는 마음을 바꿔 다시 함께 하시길 바랍니다.

나는 모든 사람이 모든 기능을 좋아하는 단일 제품을 본 적이 없습니다.

이것은 실제로 아무것도 재발명하지 않는다는 점도 언급할 가치가 있습니다. 그것은 "발명하지 않는" 것입니다.

우리의 다양한 의견에도 불구하고 원하는 원활한 지원을 제공할 fs:// 처리기가 우리가 말하는 대로 구현되고 있으며 이미 브라우저 확장 과 함께 사용할 수 있습니다. 우리는 또한 브라우저가 기본적으로 PoC를 사용할 수 있도록 PoC 구현을 위해 노력하고 있습니다. 전자 포장 응용 프로그램에서 지원을 구현할 수도 있습니다. 더 빨리 진행하기 위해 이러한 노력에 기여할 수 있습니다.

"당신은 넋을 잃고 있었고, 이것에 관한 것은 '과대망상'이거나 심지어 재발명도 아닙니다."

나는 https://github.com/multiformats/multiaddr 을 탐욕스럽고 재창조하는 것으로 해석합니다. URL과는 다른 형식이지만 동일한 데이터를 나타냅니다. 그런 중요한 표준을 재발명하려면 정말 그럴듯한 이유가 필요합니다.

조금 더 자세히 말씀드리겠습니다.

"우리는 항상 그대로 사용되는 파일 경로에 대해 이야기하고 있습니다."

이 아이디어로 여러분이 어디로 가고 있는지 알 것 같습니다. 웹 리소스를 일반 파일처럼 취급할 수 없다는 사실을 수정하려는 "실수"입니까? 그런 식으로 나는 cat http://google.com/index.html 할 수 없습니까? 그것이 불가능하다는 것이 슬프다는 데 동의할 수 있습니다. 내가 OS를 작성한다면 파일에 대한 URL을 열 수 있는 open 함수를 만들 것입니다. 아마도 그러한 변화는 리눅스에서도 이루어질 수 있습니다. 접근 방식이 다르며 웹 리소스를 POSIX 파일 계층에 삽입하려고 합니다. URL이 잘못되었다고 생각하는 다른 이유가 있으면 알려주십시오.

웹 리소스를 일반 파일처럼 작동시키려는 당신의 목표에 확실히 공감합니다. 그러나 "실수"를 수정하는 당신의 방법은 나에게 꽤 미끄러운 경사로 보인다. ipfs 파일 시스템을 마운트하도록 선택하면 해당 마운트 지점이 저에게 새로운 동작입니다. 내 시스템에 설치할 수 있는 다른 사용자 모드 프로그램은 생각할 수 없습니다. 이 프로그램은 내 루트 디렉터리에 직접 여러 디렉터리를 생성합니다.

오늘 ls / 를 하면 다음을 얻습니다.

$ ls / bin/ dev/ home/ lib/ media/ opt/ root/ sbin/ sys/ usr/ vmlinuz@ boot/ etc/ initrd.img@ lib64/ mnt/ proc/ run/ srv/ tmp/ var/

multiaddr이 제안한 경로를 사용하면 대신 다음을 볼 수 있습니다.

$ ls / bin/ bitcoin/ boot/ dev/ dns/ dns4/ dns6/ etc/ home/ http/ https/ initrd.img@ ipfs/ lib/ lib64/ libp2p-circuit-relay/ libp2p-webrtc-direct/ libp2p-webrtc-star/ media/ mnt/ onion/ opt/ p2p/ proc/ root/ run/ sbin/ sctp/ srv/ sys/ tmp/ udt/ unix/ usr/ utp/ var/ vmlinuz@
https://github.com/multiformats/multiaddr/blob/master/protocols.csv

그리고 표준을 잘못 해석했다고 비난하기 전에 유닉스 경로가 항상 해석되는 것과 똑같은 방식으로 표준을 해석하고 있음을 상기시켜 드리겠습니다.

분명히, 나는 내 루트 디렉토리를 엉망으로 만들고 싶지 않을 것입니다. 따라서 이러한 경로를 마운트하지 않기로 선택합니다.

제 경우에는 이것이 제 선택이 아닙니다. 저는 IPFS를 사용하는 소프트웨어를 작성하고 싶습니다. 사용자가 해당 경로를 마운트할지 여부는 제 결정이 아닙니다. 그러나 나는 여전히 내 사용자가 로컬 시스템에서 파일을 열 수 있는 것처럼 쉽게 IPFS를 통해 공유된 파일을 열 수 있기를 바랍니다. 그럼 그 코드를 어떻게 작성해야 할까요? ipfs가 표준 URL을 사용하는 경우 ipfs://로 시작하는 모든 것을 ipfs로 전달하면 모든 것이 간단합니다.

그러나 내 프로그램이 / 시작하는 문자열을 볼 때 누군가 컴퓨터, 일반적으로 코드가 실행 중인 컴퓨터의 파일이나 디렉토리에 대한 절대 경로로 해석합니다. / 로 시작하는 경로를 방문하라는 지시를 받으면 로컬 시스템의 파일 또는 디렉토리에 대한 절대 경로로 확실히 해석합니다. 내 컴퓨터에 /ipfs 가 없으면 프로그램에서 파일을 찾을 수 없음 오류를 반환해야 합니다. 프로그램이 방문하도록 지시받은 절대 경로가 로컬 시스템의 파일이나 디렉토리가 아닌 다른 곳으로 이어지는 다른 예는 생각할 수 없습니다. 따라서 오랜 기간 Linux 사용자/개발자로서 이것은 새로운 동작입니다.

내 응용 프로그램이 multiaddr에 대한 지원을 추가하려고 하면 상황이 매우 빨리 복잡해질 것입니다. 사용자가 다음을 실행하면 어떻게 될까요?

$tims-program-that-supports-normal-files-as-well-as-multiaddr /http/index.html
?

그리고 사용자는 html 파일을 /http 에 저장하는 웹 서버를 가지고 있습니다. 전혀 들어본 적이 없습니다. 내 프로그램이 이것을 다중 주소 또는 로컬 파일로 해결해야 합니까?

나는 파이썬에서 URL을 여는 것을 기본적으로 지원하는 일부 코드를 이미 작성했습니다. 그렇게 하는 것은 꽤 쉬웠습니다. 그러나 multiaddr 경로와 로컬 파일 경로를 모두 명확하게 해석하도록 코드를 변경하려면 어떻게 해야 합니까?

if filename.startswith( "http://" ) or filename.startswith( "https://" ): import urllib.request try: with urllib.request.urlopen(filename) as webgraph: self.json = webgraph.read().decode("utf-8") except urllib.error.URLError as e: raise OSError(str(e)) else: try: with open(filename) as fd: self.json = fd.read() except FileNotFoundError: pass

나는 그것이 가능하다고 생각하지 않는다. 따라서 multiaddr 지원을 구현하지 않고 일반 URL만 지원하게 되었습니다. 처음에는 괜찮아 보이지만 ipfs 사용자는 ipfs 개체에 대한 다중 주소 주소에 지속적으로 노출될 것이며 IPFS 지원을 광고하는 내 프로그램은 이러한 경로가 존재하지 않는다고 주장할 것입니다. 따라서 지원을 구현하는 방법에 관계없이 내 프로그램은 중단될 것입니다. ipfs에 대한 지원이 중단되거나 표준 POSIX 파일 시스템에 대한 지원이 중단됩니다.

잠재적으로 이 문제를 해결할 수 있는 방법이 있습니다. 하나는 multiaddr을 완전히 포기하는 것입니다. 또 다른 방법은 multiaddr을 변경하여 최소한 해당 경로를 단일 하위 디렉토리로 제한하도록 하는 것입니다. 따라서 /ipfs/hash/blah 를 쓰는 대신 /webfs/ipfs/hash/blah 를 작성합니다. 그리고 ls / 는 다음을 반환합니다.

$ ls / bin/ dev/ home/ lib/ media/ opt/ root/ sbin/ sys/ usr/ vmlinuz@ boot/ etc/ initrd.img@ lib64/ mnt/ proc/ run/ srv/ tmp/ var/ webfs/

그것은 내가 살 수 있고 어쩌면 뒤처질 수도 있는 것입니다. 그러나 현재 상황은 ipfs 지원을 구현하는 만족스러운 방법이 전혀 없다는 것입니다.

더 많은 CONCRETE 예제를 살펴보겠습니다. 마크다운을 PDF로 변환하는 프로그램을 작성하고 있다고 상상해 보십시오. 그리고 저는 IPFS의 이미지 포함을 지원할 수 있기를 원합니다. 따라서 사용자는 다음과 같이 씁니다.

다락방.md
````

내 다락방에서 찾은 물건

바위의 오래된 상자입니다.

````

그리고 실행

$ tims-md-to-pdf-with-ipfs-support attic.md > attic.pdf

내 프로그램은 이러한 이미지 경로를 어떻게 해결해야 합니까? /ipfs 파일 시스템이 마운트되어 있다고 가정해야 합니까? 우리는 이미 사용자가 /ipfs 를 마운트하지 않아도 된다는 데 동의했습니다. 프로그램에서 /ipfs/ 를 특수 접두사로 취급해야 합니까? 이상하고 고장난 것 같습니다. 프로그램이 fs:// 만 지원하고 해당 경로에서 파일을 찾을 수 없다는 오류를 반환해야 합니까? 그것은 합리적으로 보이지만 multiaddr 표준에 익숙한 사용자를 혼란스럽게 할 것입니다. 가방에서 올바른 방법은 없습니다! :/ :(

설명을 위해 편집됨

@timthelion 사용 사례를 제공해 주셔서 감사합니다. 프로토콜이 실제 사람들에게 제대로 작동하는지 확인할 수 있도록 사람들이 실제 사례를 제공하도록 하는 것이 좋습니다.

"/에 모든 것을 마운트" 예를 명확히 하기

@lidel이 지적했듯이 사람들은 현재 주소 체계를 설계하는 중이므로 아직 문서가 없습니다. @jbenet 의 파일 시스템 마운트 예제가 혼란을 fs: 또는 dweb: 주소 체계 이면의 개념적 모델을 통해 생각하는 데 도움을 주기 위한 예시일 뿐입니다. 그는 모든 사람이 파일 시스템에 있는 모든 디렉토리를 실제로 마운트하도록 강요하지 않습니다. 오히려 그는 콘텐츠가 로컬 파일 시스템에 마운트된 것처럼 작동하는 주소로 콘텐츠를 _식별_할 수 있어야 한다고 제안합니다. 그래야 Unix/posix 도구를 사용하여 web/dweb 콘텐츠와 상호 작용할 수 있기 때문입니다.

문서를 작성할 때 이를 명확히 하기 위해 주의해야 합니다. 신고해 주셔서 감사합니다.

'다락방에 있는 물건' 예에 대한 답변으로, 다음과 같이 링크에 fs:/ 를 사용하는 것이 좋습니다.

Stuff I found in my attic
----------------------------------

![An old box of rocks](fs:/ipfs/QmdyWzsrBvSkPYPU1ScBpwzfCcegzbc6c2hkEBLLJ6VcPV)

An old box of rocks.

![A can of oil for water-proofing leather](fs:/ipfs/QmUPC5xbVtu6NxMwFBtmWVjrVM3XffuPtSMLpmDFGfTaKG)

주소가 단순하고 스키마 통합

참고 사항: 주소를 단순하게 유지하는 문제도 있습니다. 이 의견에서 @nicola 는 fs: / dweb: 주소 체계에서 벗어나지 않고 ipfs:/ 및 ipns:/ 주소를 지원하는 영리한 방법을 제안했습니다. 관련된 프로토콜 설계 체조는 (IMHO) 이상하게 혼동되지만 결국 ipfs:/QmdyWzsrBvSkPYPU1ScBpwzfCcegzbc6c2hkEBLLJ6VcPV 와 같은 마크다운에 링크를 허용하는 동시에 사람들이 fs:/ipfs/QmdyWzsrBvSkPYPU1ScBpwzfCcegzbc6c2hkEBLLJ6VcPV 또는 unix/posix 컨텍스트에서 /ipfs/QmdyWzsrBvSkPYPU1ScBpwzfCcegzbc6c2hkEBLLJ6VcPV 입니다.

절대 경로는 컨텍스트에 따라 다릅니다.

절대 경로와 관련하여 다음과 같이 말했습니다.

/로 시작하는 경로를 방문하라는 지시를 받으면 분명히 로컬 시스템의 파일이나 디렉토리에 대한 절대 경로로 해석합니다.

절대 경로가 파일 시스템의 루트가 아닌 _context_에 상대적인 경우가 많다는 점을 명심하십시오. 가장 일반적인 예는 HTML의 절대 경로로, 서버 파일 시스템의 루트가 아닌 현재 origin 의 루트를 기준으로 합니다. 모든 경로가 fs: 또는 dweb: 라고 가정하는 컨텍스트 내에서 작동하는 코드가 있는 경우 해당 코드가 /ipfs/ 시작하는 주소를 사용하는 것은 완전히 유효합니다. 해당 코드가 파일 시스템의 /ipfs 에 ipfs를 말 그대로 마운트하지 않고 경로를 해결하는 많은 방법.

이것은 내 2 센트입니다.

• 모든 파일은 fs:/ 아래에 있으며 모든 도메인이 http:/ 아래에 있는 것과 같습니다.
• 내 파일 시스템의 / 에 도메인 이름 시스템을 마운트하지 않는 것과 같은 방식으로 / 에 전체 IPFS를 마운트하지 않습니다. 두 시스템에서 참조 지점은 체계에 상대적인 / ( http:/ , fs:/ ).

나는 대부분의 예에서 모든 파일 시스템이 / 에 ipfs를 마운트했다는 개념이 있다고 생각합니다. 따라서 fs:/ 하면 URI 형식이 손상되지 않습니다.

오히려 그는 콘텐츠가 로컬 파일 시스템에 마운트된 것처럼 동작하는 주소로 콘텐츠를 식별할 수 있어야 한다고 제안합니다. 그래야 Unix/posix 도구를 사용하여 web/dweb 콘텐츠와 상호 작용할 수 있기 때문입니다.

"그것은 우리가 유닉스/포식스 도구를 사용하여 웹/디웹 콘텐츠와 상호작용할 수 있게 해줄 것입니다." fs: 접두어가 아닌 구문이 유닉스 도구와 함께 사용되는 경우의 구체적인 예를 말씀해 주시겠습니까? 어쨌든, 나는 아직도 그것을 얻지 못한다.

직접 예제를 만들려고 했지만 multiaddr 호환 /ipfs 접두어 구문이 의미가 있는 예제를 생각할 수 없습니다.

multiaddr 체계를 사용하여 ipfs를 지원하는 bash의 diff 유틸리티에 대한 래퍼 스크립트를 만들려고 했습니다.

````
티모시 @yoga ~/c/ipfs-multiaddr> 고양이 multiaddr-diff

!/bin/bash

get_multiaddr_or_normal_file_getter(){
if [[ $1 == /ipfs/* ]] ;
그 다음에
file_getter="ipfs 고양이 $1"
또 다른
file_getter="고양이 $1"
파이
에코 $file_getter
}

파일1= get_multiaddr_or_normal_file_getter $1
파일2= get_multiaddr_or_normal_file_getter $2

차이 <($file1) <($file2)
````

일반 파일과 ipfs 파일 모두에서 순진한 경우에 작동합니다.

````
티모시 @yoga ~/c/ipfs-multiaddr>
./multiaddr-diff ../subuser/COPYING.LGPL /ipfs/QmSRrBvLXvYQRdQ3kZtJ5oJicKMcNQzC3CwH6bJDbEKWYp
127a128,130

f) 첫째 날에 로라스 신에게 첫 아이를 바치십시오.
다음 짝수 해의 보름달.

````

그러나 내가 만든 /ipfs/ 디렉토리에 있는 실제 기존 파일에서 작동하는 데 사용하려고 하면 오류가 발생합니다.

timothy<strong i="39">@yoga</strong> ~/c/ipfs-multiaddr> su Password: root<strong i="40">@yoga</strong>:/home/timothy/current/ipfs-multiaddr# mkdir /ipfs/ root<strong i="41">@yoga</strong>:/home/timothy/current/ipfs-multiaddr# echo "foo">/ipfs/foo root<strong i="42">@yoga</strong>:/home/timothy/current/ipfs-multiaddr# exit exit timothy<strong i="43">@yoga</strong> ~/c/ipfs-multiaddr> ./multiaddr-diff ../subuser/COPYING.LGPL /ipfs/foo Error: selected encoding not supported ....

다중 주소 주소와 일반 유닉스 파일 모두에서 안정적으로 작동할 수 있도록 해당 유틸리티를 편집하는 방법을 잘 모르겠습니다.

반면에 url 스타일 구문만 지원하는 diff 래퍼를 만드는 것은 어렵지 않습니다.

````
티모시 @yoga ~/c/ipfs-multiaddr> 고양이 url-syntax-diff

!/bin/bash

get_multiaddr_or_normal_file_getter(){
if [[ $1 == fs:* ]] ;
그 다음에
접두사="fs:"
internal_path=${1#$접두사}
file_getter="ipfs 고양이 $internal_path"
또 다른
file_getter="고양이 $1"
파이
에코 $file_getter
}

파일1= get_multiaddr_or_normal_file_getter $1
파일2= get_multiaddr_or_normal_file_getter $2
에코 $file1
에코 $file2
차이 <($file1) <($file2)
````

그것은 잘 작동하며 해시가 이미 수십억 5자 길이일 때 3개의 추가 문자는 확실히 큰 차이를 만들지 않습니다.

````
티모시 @yoga ~/c/ipfs-multiaddr>
./url-syntax-diff ../subuser/COPYING.LGPL fs:/ipfs/QmSRrBvLXvYQRdQ3kZtJ5oJicKMcNQzC3CwH6bJDbEKWYp
고양이 ../subuser/COPYING.LGPL
ipfs 고양이 /ipfs/QmSRrBvLXvYQRdQ3kZtJ5oJicKMcNQzC3CwH6bJDbEKWYp
127a128,130

f) 첫 번째 날에 로라스 신에게 첫 아이를 제물로 바치십시오.
다음 짝수 해의 보름달.

티모시 @yoga ~/c/ipfs-multiaddr>
````

그리고 이상한 경우에는 잘 다듬어진 POSIX 유틸리티에서 기대할 수 있는 것처럼 훌륭하게 수행됩니다.

````
timothy @yoga ~/c/ipfs-multiaddr> echo "바" >바
티모시 @yoga ~/c/ipfs-multiaddr> ./url-syntax-diff bar /ipfs/foo
고양이 바
고양이 /ipfs/foo
1c1

< 바

푸
````

fs: 및 dweb:에 대한 토론이 끝이 없는 것 같기 때문에 이 홍보에 대한 정보가 여전히 필요합니다. https://github.com/ipfs/specs/pull/139

ipfs 사용: 그 동안 적어도 저에게는 많은 문제가 해결되었습니다.

@pawal 한숨, 당신의 댓글을 보고 있었기 때문 입니다.

핑 @jbenet

이전에 내가 알지 못했던 문제에 대한 관점을 강조한 귀하의 이전 게시물에 대한 답변에도 관심이 있습니다.

// 편집: 즉, 여전히 문제를 추적하고 있으며 만족스러운 답변을 제공했다면 응답했을 것입니다.

+1

표준으로 'ipfs://'가 작동하도록 합니다. 제발.

(따라서 우리의 모든 앱은 모든 플랫폼, 모든 곳에서 작동한다고 가정할 수 있습니다.
어디에서나 명함에)

고마워.

줄리안 스미스
블록화물™

ipfs: vs. fs: vs. dweb: 에 대한 토론은 제가 이 프로젝트에 참여하기 전부터 계속되어온 혼란스러운 것입니다. 나는 마침내 웹 브라우저 스프린트의 IPFS 동안 그것에 대해 머리를 숙일 시간을 갖게 되었다. 나는 오늘 나중에 ipfs/specs에 대한 PR로 제출할 다양한 옵션과 인수의 개요와 함께 전체 그림에 대한 설명을 작성하고 있습니다. 내가 알고 있는 토론에 대한 예와 참조를 포함할 것입니다. 바라건대 그것은 약간의 명확성을 제공하고 장기적으로 큰 문제를 일으키는 실수를 저지르지 않고 가장 실용적인 경로를 따라 앞으로 나아갈 수 있게 해 줄 것입니다.

저는 이 토론에 대한 배경을 제공하기 위해 초기에 시도했습니다. https://github.com/ipfs/specs/pull/152 정확하지 않거나 불완전하거나 일반적으로 개선이 필요한 정보로 PR을 업데이트하십시오.

무지해서 죄송합니다만 PR을 업데이트하려면 어떻게 해야 합니까?

@timthelion 당신은 @jbenet처럼을하고 주석을 추가 할 수 있습니다 여기 거나, 커밋, 전송 패치 등의 REPO를 복제 분기를 체크 아웃, 수정할 수 있습니다

@vasa-develop 귀하의 의견은 실제로 소프트웨어가 상황을 개선하는 방법을 설명하지 않으므로 스팸으로 간주합니다.

DID URI는 어떻습니까? did:ipfs:QmSRrBvLXvYQRdQ3kZtJ5oJicKMcNQzC3CwH6bJDbEKWYp 와 같은

분산 식별자(DID)

DID는 사람의 식별자입니다. 그러나 핵심적으로는 실제로 URN(내 생각에는?)이므로 더 나은 질문은 "URN이 아닌 이유"입니다.

실제로 대답은 URL 이 브라우저 호환성을 제공하는 반면 경로 는 파일 시스템 호환성(무엇보다도)을 제공하지만 URN은 일부 표준 기관에 대한 선의 외에는 많은 것을 제공하지 않는다는 것입니다.

참고: 브라우저 호환성을 확보하기 위해 실제로 URL 위치를 무시했습니다. 즉, IPFS 컴패니언(브라우저 애드온)은 ipfs://... 및 ipns://... 합니다. 우리 는 dweb://ipfs/... 등을 사용하고 싶었지만 적절한 보안 출처 지원도 필요했습니다(즉, 첫 번째 구성 요소에 해시가 필요함을 의미합니다).

그러나 우리는 ipfs://... 가 /ipfs/... 와 동등하다고 간주하고 다른 모든 곳에서 경로 구문을 사용합니다.

@Stebalien DID가 사람들을 위한 것이라는 아이디어는 어디서 얻나요? "사람"은 DID 사양에서 한 번도 언급되지 않습니다. URI 식별자는 정의에 따라 모든 리소스를 식별할 수 있습니다.

당신이 무엇을 고려하든 그것은 중요하지 않습니다. 기존 표준을 준수하지 않으면 기존 인프라의 상호 운용성과 지원을 기대할 수 없습니다.

DID가 사람들을 위한 것이라는 아이디어는 어디서 얻나요? "사람"은 DID 사양에서 한 번도 언급되지 않습니다.

DID는 "디지털 신원"을 위한 것입니다.

분산식별자(DID)는 검증 가능한 "자주권" 디지털 신원을 위한 새로운 유형의 식별자입니다.

그래서? 사람, 동물, 건물, 조직, 사물, 아이디어, 문서 등 모든 것이 _identity_를 가질 수 있습니다. 이것이 URI의 아름다움입니다.
실제로 DID 사양을 보셨습니까? 다시 말하지만, 사람에게 특정한 것은 없습니다.

분산 식별자(DID)

분산 원장 기술 또는 기타 형태의 분산 네트워크에 등록되어 있기 때문에 중앙 집중식 등록 기관이 필요하지 않은 전역 고유 식별자입니다. DID의 일반 형식은 이 사양에 정의되어 있습니다. 특정 DID 방식은 DID 방식 사양에 정의되어 있습니다.