Saya tidak dapat menemukannya di dokumentasi sekarang, tetapi saya ingat penjelasan di sepanjang baris berikut:
IPFS adalah sistem file dan untuk sistem file Anda menggunakan jalur daripada URL. URL dapat dipahami sebagai keburukan yang mewakili kegagalan untuk menyatukan akses pada mesin lokal Anda dan pada mesin jarak jauh. IPFS menghindari keburukan ini dengan memperlakukan file lokal dan jauh sama dan metode untuk menangani file adalah jalur standar.

Mungkin membantu untuk membayangkan memasang seluruh IPFS di bawah /ipfs dan kemudian mengakses file seperti itu: File di sistem file Anda.

Bahan bacaan tambahan:

Diskusi panjang: https://github.com/ipfs/go-ipfs/issues/1678
Ringkasan singkat dari konsensus saat ini: https://github.com/ipfs/go-ipfs/issues/1678#issuecomment -157478515

Juga, ada pekerjaan yang sedang berlangsung untuk merekonsiliasi alamat absolut IPFS dengan resolusi URL standar dan untuk mengatasi mengidentifikasi asal dengan (atau tanpa?) fs: paths .

Dan https://github.com/ipfs/in-web-browsers/issues/28 dengan tautan ke spesifikasi draf. cc @lgierth

:( Setelah membaca ipfs/go-ipfs#1678 Saya bahkan tidak yakin apakah saya tertarik pada IPFS lagi :( . Itu adalah non-diskusi yang buruk.

Saya benar-benar tidak ingin memasuki pelepasan sepeda, tetapi ini

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.
bukanlah ide yang membuat saya bersemangat. Saya membayangkan tiba-tiba memiliki root sistem yang terlihat seperti
/btrfs/dev/sda1/.. /fat32/dev/sda2/.. /ext3/dev/sda3/boot/..

Itu bukan konsep yang menarik bagi saya. Saya terbiasa mengatur sistem saya seperti yang saya suka dan memasang sistem file saya seperti yang saya pilih. Tapi sebenarnya bukan itu yang membuatku putus asa. Anda bebas memasang ipfs di mana pun Anda mau. Saya dimatikan oleh pendekatan megalomaniacal "mari kita ciptakan kembali segalanya". Saya datang ke IPFS karena saya menginginkan CAS terdistribusi. Itu saja yang membuat saya tertarik. Saya tidak peduli tentang penggabungan unix dengan web. Tetapi setelah membaca diskusi itu IPFS tidak lagi tampak seperti produk yang akan membantu saya mendapatkan CAS terdistribusi, sepertinya produk yang akan menentukan bagaimana saya menggunakan dan namespace sistem file komputer saya dan begitu penulis mendiktekan satu hal, mungkin mereka akan memilikinya. beberapa ide baru lainnya tentang bagaimana komputer saya harus dikonfigurasi dan diatur. Saya tidak bisa memprediksi masa depan, tapi saya tidak suka pendekatannya.

Sayang sekali, karena SAYA SANGAT MENYUKAI implementasi CAS terdistribusi IPFS. Saya sudah lama bermimpi memiliki CAS terdistribusi :(. Jadi saya harus kembali ke mode riset dan melihat beberapa CAS terdistribusi lainnya...

@timthelion Saya melihat Anda (seperti saya) sangat peduli dengan CAS dan IPFS.
Saya akan melakukan yang terbaik untuk meredakan kekhawatiran Anda.

Saya cukup yakin bahwa Anda dapat menggunakan IPFS sebagai CAS tanpa memasangnya di mana pun di sistem Anda, selamanya.
Cara saya berpikir tentang jalur /ipfs/Qm.. adalah bahwa jalur tersebut hanyalah jalan pintas mental yang menyederhanakan percakapan dan penautan (seperti halnya URL biasa).

Secara pribadi, saya setuju bahwa situasi "penangan protokol" dan "semantik alamat kanonik" mungkin terlihat berantakan bagi pengamat saat ini, tetapi orang-orang baik yang mengerjakan solusi pragmatis dapat bekerja sekarang (mis. https://github.com/ ipfs/in-web-browsers/issues/3, https://github.com/ipfs/in-web-browsers/issues/7).

Ini adalah percakapan yang sedang berlangsung dan hal-hal ini membutuhkan waktu.

Arahan umum proyek (pendapat pribadi saya) adalah untuk _"membuat alat yang berguna yang menggunakan kembali standar industri yang praktis untuk melakukannya"_ daripada _"menemukan kembali semuanya, apa pun yang terjadi"_.

Saya tidak berpikir Anda harus khawatir tentang masa depan. Alat IPFS mengikuti _"cara unix"_, yang berarti banyak alat kecil, perpustakaan, dan perintah (mirip dengan subperintah git ) yang melakukan satu hal dapat dirantai bersama untuk membangun sesuatu yang lebih besar.

Andalah yang memutuskan potongan mana yang digunakan. ️

Saya harap tidak ada yang mengambil posting terakhir saya dengan cara yang salah. Saya tidak bermaksud mengatakan "Anda semua brengsek, saya akan pergi". Saya berasumsi bahwa ribuan orang telah melihat IPFS, memutuskan bahwa mereka tidak menyukai sesuatu, dan pergi, tanpa pernah menulis mengapa... Saya sering melakukan itu. Saya hanya melihat dengan santai pada suatu teknologi dan memilih yang berbeda berdasarkan beberapa detail kecil yang membuat saya salah jalan. Saya memutuskan untuk tidak melakukan itu karena saya ingin tidak menjadi anggota silent mayoritas, dan juga, karena saya tidak punya banyak pilihan lain :D, tapi sepertinya saya harus menunggu ipfs untuk mendukung fs:// atau apa pun yang dipilih kepala proyek sebelum saya mulai menggunakan ipfs dalam proyek saya saat ini dan saya hanya akan dapat mulai melihat IPFS sampai beberapa URL normal yang nyata ada.

saya dimatikan oleh pendekatan "mari kita temukan kembali segalanya" yang megalomaniak.

Anda terbawa suasana, tidak ada apa pun tentang ini yang 'megalomaniak' atau bahkan penemuan ulang. Kita berbicara tentang jalur file yang digunakan seperti biasanya. Pemasangan di /ipfs hanyalah sebuah contoh untuk mengilustrasikan berbagai hal, bukan ide inti.

Saya terbiasa mengatur sistem saya seperti yang saya suka dan memasang sistem file saya seperti yang saya pilih.

Tidak ada yang memaksa Anda memasang IPFS sebagai sistem file lokal @timthelion . Ini adalah fitur yang dapat Anda gunakan dan Anda dapat memutuskan jalur mana yang akan dipasang. Tidak menyukai fitur yang dinonaktifkan secara default bagi saya terdengar seperti alasan lemah untuk mengabaikan IPFS secara keseluruhan. Tapi yah, saya harap Anda akan berubah pikiran di masa depan dan bergabung dengan kami lagi.

Saya belum pernah melihat satu produk pun di mana semua orang menyukai setiap fiturnya.

Perlu disebutkan juga bahwa ini sebenarnya tidak menciptakan kembali apa pun. Ini "menciptakan" sesuatu.

Terlepas dari perbedaan pendapat kami, pengendali fs:// -- yang akan memberi Anda dukungan tanpa batas yang Anda inginkan -- sedang diterapkan saat kami berbicara, dan Anda sudah dapat menggunakannya dengan ekstensi peramban . Kami juga sedang mengerjakan implementasi PoC untuk memungkinkan browser menggunakannya secara asli. Anda juga dapat menerapkan dukungan untuk itu dalam aplikasi yang dibungkus elektron. Mungkin Anda dapat berkontribusi pada upaya tersebut untuk membuatnya lebih cepat.

"Kamu terbawa suasana, tidak ada apa pun tentang ini 'megalomaniak' atau bahkan penemuan ulang."

Saya menafsirkan https://github.com/multiformats/multiaddr sebagai magalomaniacal dan menciptakan kembali. Ini adalah format yang berbeda dari URL tetapi mewakili data yang sama. Anda membutuhkan alasan yang sangat bagus untuk menemukan kembali standar yang begitu penting.

Saya akan sedikit lebih detail.

"Kita berbicara tentang jalur file yang digunakan seperti biasanya."

Saya pikir saya mendapatkan di mana kalian akan pergi dengan ide ini. Apakah "kesalahan" yang Anda coba perbaiki adalah fakta bahwa Anda tidak dapat memperlakukan sumber daya web seperti file biasa? Seperti itu saya tidak bisa melakukan cat http://google.com/index.html ? Saya dapat setuju dengan Anda bahwa itu menyedihkan bahwa itu tidak mungkin. Jika saya menulis os, saya akan membuat fungsi open mampu membuka URL ke file. Mungkin perubahan seperti itu bahkan dapat dilakukan pada linux. Pendekatan Anda berbeda, Anda mencoba memasukkan sumber daya web ke dalam hierarki file POSIX. Jika ada alasan lain mengapa menurut Anda URL itu salah, beri tahu saya.

Saya pasti dapat bersimpati dengan tujuan Anda membuat sumber daya web bertindak seperti file biasa. Metode Anda untuk memperbaiki "kesalahan", menurut saya, tampaknya cukup licin. Jika saya memilih untuk memasang sistem file ipfs maka titik pemasangannya adalah perilaku baru bagi saya. Saya tidak dapat memikirkan program mode pengguna lain yang dapat saya instal di sistem saya, yang akan membuat banyak direktori langsung di direktori root saya.

Hari ini, ketika saya melakukan ls / saya mendapatkan:

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

Dengan jalur yang diusulkan oleh multiaddr, saya malah akan melihat:

$ 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

Dan sebelum Anda menuduh saya salah menafsirkan standar, saya akan mengingatkan Anda, bahwa saya menafsirkannya dengan cara yang persis seperti yang SELALU ditafsirkan oleh jalur unix.

Jelas, saya tidak ingin membuat direktori root saya berantakan. Jadi karena itu, saya akan memilih untuk tidak memasang jalur ini.

Dalam kasus saya, ini bukan pilihan saya, saya ingin menulis perangkat lunak yang menggunakan IPFS dan bukan keputusan saya apakah pengguna memasang jalur itu atau tidak. Tetapi saya masih ingin pengguna saya dapat membuka file yang dibagikan melalui IPFS semudah mereka dapat membuka file di mesin lokal mereka. Jadi bagaimana saya menulis kode itu? Jika ipfs menggunakan url standar, saya hanya akan meneruskan apa pun yang dimulai dengan ipfs:// ke ipfs dan semuanya akan sederhana.

Tetapi ketika program saya melihat string yang dimulai dengan / itu menafsirkan bahwa sebagai jalur absolut ke file atau direktori pada mesin seseorang, biasanya mesin yang menjalankan kode. Jika diperintahkan untuk mengunjungi jalur yang dimulai dengan / , maka PASTI akan menafsirkannya sebagai jalur absolut ke file atau direktori di mesin lokal. Jika /ipfs tidak ada di mesin saya, maka program akan mengembalikan kesalahan file-not-found. Saya tidak bisa memikirkan contoh lain di mana jalur absolut yang diperintahkan untuk dikunjungi oleh program mengarah ke suatu tempat selain ke file atau direktori di mesin lokal. Jadi bagi saya, sebagai pengguna/pengembang linux lama, ini adalah perilaku baru.

Jika aplikasi saya mencoba untuk menambahkan dukungan untuk multiaddr, maka semuanya akan menjadi cukup cepat. Bagaimana jika pengguna menjalankan:

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

dan pengguna kebetulan memiliki server web yang menyimpan file htmlnya di /http . Sama sekali tidak terdengar. Haruskah program saya menyelesaikan ini ke alamat multiaddr atau file lokal?

Saya sudah menulis beberapa kode dengan dukungan primitif untuk membuka URL dengan python. Melakukannya cukup mudah. Tetapi bagaimana saya akan mengubah kode saya sehingga secara jelas menyelesaikan jalur multiaddr dan jalur file lokal?

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

Saya benar-benar tidak berpikir itu mungkin. Oleh karena itu, saya dibiarkan tidak menerapkan dukungan multiaddr dan hanya mendukung URL normal. Tampaknya baik-baik saja pada awalnya, tetapi pengguna ipfs akan terus-menerus terpapar ke alamat multiaddr ke objek ipfs, dan program saya, yang mengiklankan dukungan IPFS akan mengklaim bahwa jalur itu tidak ada. Jadi tidak peduli bagaimana saya menerapkan dukungan, program saya akan rusak. Dukungannya untuk ipfs akan rusak, atau dukungannya untuk sistem file POSIX standar akan rusak.

Ada cara agar ini bisa diperbaiki, berpotensi. Seseorang akan menyerah pada multiaddr sepenuhnya. Cara lain adalah mengubah multiaddr sehingga setidaknya membatasi jalur tersebut ke satu subdirektori. Jadi daripada menulis /ipfs/hash/blah seseorang akan menulis /webfs/ipfs/hash/blah . Dan ls / akan kembali:

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

Itu akan menjadi sesuatu yang bisa saya jalani, dan bahkan mungkin tertinggal. Tetapi situasi saat ini adalah, saya tahu tidak ada cara yang memuaskan untuk mengimplementasikan dukungan ipfs sama sekali.

Biarkan saya mendapatkan contoh yang lebih BETON. Bayangkan saya sedang menulis sebuah program yang mengubah penurunan harga ke PDF. Dan saya ingin dapat mendukung penyertaan gambar dari IPFS. Jadi pengguna menulis:

loteng.md
````

Barang-barang yang saya temukan di loteng saya

Sebuah kotak batu tua.

````

Dan berlari

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

Bagaimana seharusnya program saya menyelesaikan jalur gambar itu? Apakah seharusnya mengasumsikan bahwa sistem file /ipfs telah di-mount? Kami telah setuju bahwa pengguna tidak dipaksa untuk memasang /ipfs . Haruskah program memperlakukan /ipfs/ sebagai awalan khusus? Itu tampak aneh dan rusak. Haruskah program hanya mendukung fs:// dan mengembalikan kesalahan, file tidak ditemukan dengan jalur tersebut? itu tampaknya masuk akal, tetapi akan membingungkan pengguna yang terbiasa dengan standar multiaddr. Tidak ada jalan keluar yang benar! :/ :(

diedit untuk klarifikasi

Terima kasih telah menyediakan beberapa kasus penggunaan @timthelion. Sangat menyenangkan memiliki orang-orang yang menawarkan contoh dunia nyata sehingga kami dapat memastikan protokol bekerja untuk orang-orang nyata.

Mengklarifikasi contoh "memasang semuanya di /"

Seperti yang ditunjukkan oleh @lidel , orang-orang saat ini sedang merancang skema alamat, jadi belum ada dokumentasi. Sepertinya contoh pemasangan sistem file @jbenet telah membuat kebingungan. Ini hanyalah contoh yang dimaksudkan untuk membantu orang memikirkan model konseptual di balik skema alamat fs: atau dweb: . Dia tidak mengusulkan agar kita memaksa semua orang untuk benar-benar memasang semua direktori itu di sistem file mereka. Sebaliknya, dia mengusulkan bahwa kita harus dapat _mengidentifikasi_ konten dengan alamat yang berperilaku seperti konten dipasang pada sistem file lokal Anda, karena itu akan memungkinkan kita untuk berinteraksi dengan konten web/dweb menggunakan alat unix/posix.

Ketika kita menulis dokumen, kita harus berhati-hati untuk memperjelasnya. Terima kasih telah menandainya.

Sebagai jawaban atas contoh 'barang di loteng' Anda, saya pikir idenya adalah Anda akan menggunakan fs:/ di tautan Anda, seperti ini:

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)

Memiliki Alamat Sederhana DAN Menyatukan Skema

Catatan tambahan: Ada juga masalah menjaga alamat tetap sederhana. Dalam komentar ini @nicola mengusulkan cara cerdas untuk mendukung alamat ipfs:/ dan ipns:/ tanpa melanggar skema alamat fs: / dweb: . Senam desain protokol yang terlibat (IMHO) sangat membingungkan, tetapi pada akhirnya itu akan membuat Anda memiliki tautan di penurunan harga Anda seperti ipfs:/QmdyWzsrBvSkPYPU1ScBpwzfCcegzbc6c2hkEBLLJ6VcPV sementara juga memungkinkan orang untuk membahas konten yang sama seperti fs:/ipfs/QmdyWzsrBvSkPYPU1ScBpwzfCcegzbc6c2hkEBLLJ6VcPV atau hanya /ipfs/QmdyWzsrBvSkPYPU1ScBpwzfCcegzbc6c2hkEBLLJ6VcPV dalam konteks unix/posix.

Jalan Mutlak Bergantung pada Konteks

Mengenai jalur absolut, Anda mengatakan:

Jika diperintahkan untuk mengunjungi jalur yang dimulai dengan /, maka itu PASTI akan menafsirkannya sebagai jalur absolut ke file atau direktori di mesin lokal.

Ingatlah bahwa ada banyak preseden untuk jalur absolut yang relatif terhadap _context_ daripada relatif terhadap akar sistem file. Contoh paling umum dari hal ini adalah jalur absolut dalam HTML, yang relatif terhadap akar origin saat ini, bukan relatif terhadap akar sistem file server. Jika saya memiliki kode yang beroperasi dalam konteks yang mengasumsikan semua jalur adalah fs: atau dweb: , kode itu sepenuhnya valid untuk menggunakan alamat yang dimulai dengan /ipfs/ dan ada banyak cara untuk kode itu untuk menyelesaikan jalur tanpa benar-benar memasang ipfs di /ipfs pada sistem file Anda.

Ini adalah 2 sen saya:

• Setiap file di bawah fs:/ , dengan cara yang sama setiap domain di bawah http:/ .
• Saya tidak memasang sistem nama domain pada / pada sistem file saya, dengan cara yang sama saya tidak memasang keseluruhan IPFS pada / saya. Dalam kedua sistem, titik acuannya adalah / relatif terhadap skema ( http:/ , fs:/ ).

Saya pikir di sebagian besar contoh Anda ada gagasan bahwa setiap sistem file telah memasang ipfs pada / . Jadi memiliki fs:/ tidak merusak format URI.

Sebaliknya, dia mengusulkan bahwa kita harus dapat mengidentifikasi konten dengan alamat yang berperilaku seperti konten dipasang pada sistem file lokal Anda, karena itu akan memungkinkan kita untuk berinteraksi dengan konten web/dweb menggunakan alat unix/posix.

"Itu akan memungkinkan kita untuk berinteraksi dengan konten web/dweb menggunakan alat unix/posix." Bisakah Anda memberi saya contoh konkret dari kasus di mana sintaks awalan non- fs: akan digunakan dengan alat unix? Entah bagaimana, saya masih tidak mengerti.

Saya telah mencoba membuat contoh sendiri, tetapi saya tidak dapat memikirkan contoh apa pun di mana sintaks awalan /ipfs yang sesuai dengan multiaddr masuk akal.

Saya mencoba membuat skrip pembungkus ke utilitas diff di bash yang mendukung ipfs menggunakan skema multiaddr:

````
timothy @yoga ~/c/ipfs-multiaddr> cat multiaddr-diff

!/bin/bash

get_multiaddr_or_normal_file_getter(){
jika [[ $1 == /ipfs/* ]] ;
kemudian
file_getter="ipfs cat $1"
kalau tidak
file_getter="kucing $1"
fi
echo $file_getter
}

file1= get_multiaddr_or_normal_file_getter $1
file2= get_multiaddr_or_normal_file_getter $2

diff <($file1) <($file2)
````

Ini berfungsi dalam kasus naif pada kedua file normal, dan file ipfs:

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

f) Mengorbankan anak sulung Anda kepada ALLAH Laurath pada yang pertama
bulan purnama tahun genap berikutnya.

````

Tetapi ketika saya mencoba menggunakannya untuk beroperasi pada file nyata yang ada di direktori /ipfs/ yang telah saya buat, saya mendapatkan kesalahan:

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

Saya tidak yakin bagaimana saya bisa mengedit utilitas itu, sehingga dapat bekerja dengan andal dengan alamat multiaddr dan file unix normal.

Di sisi lain, membuat pembungkus diff yang hanya mendukung sytax gaya url tidak lebih sulit:

````
timothy @yoga ~/c/ipfs-multiaddr> cat url-syntax-diff

!/bin/bash

get_multiaddr_or_normal_file_getter(){
jika [[ $1 == fs:* ]] ;
kemudian
awalan="fs:"
internal_path=${1#$awalan}
file_getter="ipfs cat $internal_path"
kalau tidak
file_getter="kucing $1"
fi
echo $file_getter
}

file1= get_multiaddr_or_normal_file_getter $1
file2= get_multiaddr_or_normal_file_getter $2
gema $file1
gema $file2
diff <($file1) <($file2)
````

Ini berfungsi dengan baik, dan 3 karakter tambahan pasti tidak membuat banyak perbedaan ketika hash sudah mencapai satu setengah miliar karakter.

````
timothy @yoga ~/c/ipfs-multiaddr>
./url-syntax-diff ../subuser/COPYING.LGPL fs:/ipfs/QmSRrBvLXvYQRdQ3kZtJ5oJicKMcNQzC3CwH6bJDbEKWYp
cat ../subuser/COPYING.LGPL
ipfs cat /ipfs/QmSRrBvLXvYQRdQ3kZtJ5oJicKMcNQzC3CwH6bJDbEKWYp
127a128,130

f) Mengorbankan anak sulung Anda kepada ALLAH Laurath pada yang pertama
bulan purnama tahun genap berikutnya.

timothy @yoga ~/c/ipfs-multiaddr>
````

Dan dalam kasus tepi yang aneh, ia tampil mengagumkan seperti yang diharapkan dari utilitas POSIX yang dipoles dengan baik.

````
timothy @yoga ~/c/ipfs-multiaddr> echo "bar" >bar
timothy @yoga ~/c/ipfs-multiaddr> ./url-syntax-diff bar /ipfs/foo
bar kucing
kucing /ipfs/foo
1c1

< bar

foo
````

Karena diskusi tentang fs: dan dweb: sepertinya tidak ada habisnya, saya masih membutuhkan beberapa masukan untuk ini: https://github.com/ipfs/specs/pull/139

Menggunakan ipfs: sementara itu memecahkan banyak masalah, setidaknya untuk saya.

@pawal Sigh, ketika saya melihat komentar Anda, hati saya tenggelam, karena saya sudah tidak sabar menunggu tanggapan atas kekhawatiran saya.

Ping @jbenet

Saya juga tertarik dengan tanggapan atas posting Anda sebelumnya karena menyoroti perspektif tentang masalah yang sebelumnya tidak saya sadari.

// sunting: Artinya saya masih mengikuti masalah ini dan saya akan menjawab jika saya memiliki jawaban yang memuaskan untuk diberikan.

+1

Jadikan 'ipfs://' berfungsi - sebagai standar. Silahkan.

(Jadi semua aplikasi kami dapat menganggapnya berfungsi di semua platform, di mana saja -
di mana saja, dan di kartu nama)

Terima kasih.

Julian Smith
Blockfreight™

Diskusi seputar ipfs: vs. fs: vs. dweb: adalah diskusi yang membingungkan yang telah berlangsung sejak sebelum saya terlibat dalam proyek ini. Saya akhirnya punya sedikit waktu untuk memahaminya selama IPFS di Web Browser Sprint . Saya sedang menulis penjelasan dari keseluruhan gambar, dengan garis besar opsi dan argumen yang berbeda, yang akan saya kirimkan sebagai PR tentang ipfs/spesifikasi hari ini. Saya akan menyertakan contoh dan referensi untuk diskusi yang saya ketahui. Mudah-mudahan itu akan memberikan kejelasan dan memungkinkan kita untuk bergerak maju di sepanjang jalan yang paling pragmatis tanpa membuat kesalahan yang menyebabkan masalah besar dalam jangka panjang.

Saya telah mencoba memberikan latar belakang untuk diskusi ini di sini: https://github.com/ipfs/specs/pull/152 Harap perbarui PR dengan info yang tidak akurat, tidak lengkap, atau umumnya ingin perbaikan.

Maaf atas ketidaktahuan saya, tetapi bagaimana cara memperbarui PR?

@timthelion Anda bisa melakukannya seperti @jbenet dan menambahkan komentar di sini atau Anda bisa mengkloning repo, checkout cabang, modifikasi, komit, kirim tambalan dll

@vasa-develop karena komentar Anda sebenarnya tidak menjelaskan bagaimana perangkat lunak memperbaiki situasi, saya menganggapnya sebagai spam.

Bagaimana dengan DID URI? Seperti did:ipfs:QmSRrBvLXvYQRdQ3kZtJ5oJicKMcNQzC3CwH6bJDbEKWYp

Pengenal Terdesentralisasi (DID)

DID adalah pengidentifikasi untuk orang . Namun, pada intinya, mereka sebenarnya adalah guci (saya pikir?) Jadi pertanyaan yang lebih baik adalah: "mengapa bukan guci"?

Sungguh, jawabannya adalah bahwa sementara URL memberi kami kompatibilitas browser, jalur memberi kami kompatibilitas sistem file (antara lain), tetapi guci tidak benar-benar memberi kami banyak selain beberapa niat baik dengan beberapa badan standar.

Catatan: Kami sebenarnya telah menyerah pada posisi URL untuk mendapatkan kompatibilitas browser. Artinya, pendamping IPFS (browser addon) mendukung ipfs://... dan ipns://... . Kami ingin menggunakan dweb://ipfs/... dll. tetapi kami juga membutuhkan dukungan asal keamanan yang tepat (yang berarti kami memerlukan hash di komponen pertama ).

Namun, kami menganggap ipfs://... setara dengan /ipfs/... dan menggunakan sintaks jalur di tempat lain.

@Stebalien dari mana Anda mendapatkan gagasan bahwa DID adalah untuk orang-orang? "orang" tidak disebutkan di sana satu kali pun dalam spesifikasi DID. Pengidentifikasi URI dapat mengidentifikasi sumber daya apa pun menurut definisi.

Tidak masalah apa yang Anda pertimbangkan; jika Anda tidak mengikuti standar yang ada, Anda tidak dapat mengharapkan interoperabilitas dan dukungan oleh infrastruktur yang ada.

dari mana Anda mendapatkan gagasan bahwa DID adalah untuk orang-orang? "orang" tidak disebutkan di sana satu kali pun dalam spesifikasi DID.

DID adalah untuk "identitas digital".

Pengenal Terdesentralisasi (DID) adalah jenis pengenal baru untuk identitas digital "berdaulat sendiri" yang dapat diverifikasi.

Jadi? Semuanya dapat memiliki _identitas_: orang, hewan, bangunan, organisasi, benda, ide, dokumen, dll. Itulah keindahan URI.
Sudahkah Anda benar-benar melihat spesifikasi DID? Saya ulangi, tidak ada yang khusus untuk orang.

Pengenal Terdesentralisasi (DID)

Pengidentifikasi unik global yang tidak memerlukan otoritas pendaftaran terpusat karena terdaftar dengan teknologi buku besar terdistribusi atau bentuk jaringan terdesentralisasi lainnya. Format generik DID didefinisikan dalam spesifikasi ini. Skema DID spesifik didefinisikan dalam spesifikasi metode DID.