DID, IPFS, dan Arweave: Tiga Teknologi yang Berbeda

DID, IPFS, dan Arweave: Tiga Teknologi Berbeda, Bukan Satu Paket Web3

DID, IPFS, dan Arweave sering dikelompokkan sebagai “Web3 non-finansial”, padahal ketiganya menyelesaikan masalah berbeda. DID membahas identifier dan metode verifikasi; IPFS membahas content-addressed data; Arweave menawarkan jaringan penyimpanan dengan model ekonomi sendiri.

Tidak satu pun otomatis memberi privasi, ketersediaan permanen, atau aplikasi tanpa server.

DID: Identifier dan Dokumen Verifikasi

Decentralized Identifier memiliki bentuk:

did:example:123456789abcdefghi

Bagian setelah did: menentukan DID method. Method menjelaskan cara membuat, membaca, memperbarui, dan menonaktifkan identifier.

DID dapat di-resolve menjadi DID Document:

{
"id": "did:example:123456789abcdefghi",
"verificationMethod": [{
"id": "did:example:123456789abcdefghi#key-1",
"type": "JsonWebKey2020",
"controller": "did:example:123456789abcdefghi",
"publicKeyJwk": {
"kty": "OKP",
"crv": "Ed25519",
"x": "public-key-material"
}
}]
}

Ini contoh struktur, bukan identifier production. DID tidak harus disimpan di blockchain; mekanismenya bergantung pada DID method.

DID juga tidak menghilangkan kebutuhan account recovery, key rotation, authorization, dan privacy. Identifier yang stabil dapat mempermudah korelasi aktivitas. Jangan memasukkan data pribadi langsung ke dokumen publik.

IPFS: Alamat Berdasarkan Isi

HTTP biasanya meminta lokasi:

https://example.com/images/logo.png

IPFS menggunakan Content Identifier atau CID yang diturunkan dari content:

ipfs://bafy...

Jika content berubah, CID berubah. Ini berguna untuk integritas, deduplication, distribusi, dan referensi build atau metadata yang immutable.

Namun CID tidak menjamin content tetap tersedia. Seseorang harus menyimpan atau “pin” data dan menyediakannya ke jaringan. Pilihannya termasuk node sendiri, pinning provider, atau beberapa penyedia.

Gateway HTTPS memudahkan browser mengakses IPFS, tetapi gateway menjadi komponen availability dan privacy. Path-style gateway juga memiliki batas origin isolation; subdomain gateway lebih sesuai untuk sebagian aplikasi web.

Arweave: Penyimpanan dengan Insentif Ekonomi

Arweave dirancang untuk penyimpanan jangka panjang menggunakan jaringan dan mekanisme pembayaran tertentu. Klaim “permanen” adalah target desain dan insentif ekonomi, bukan hukum fisika atau backup tanpa risiko.

Developer tetap perlu mempertimbangkan:

• kesehatan jaringan dan gateway;
• format data yang dapat dibaca di masa depan;
• verifikasi transaction ID dan content;
• biaya upload;
• batas ukuran;
• kebijakan data dan yurisdiksi;
• tidak adanya penghapusan praktis untuk data publik.

Jangan mengunggah password, token, data pribadi, atau content yang mungkin harus dihapus. Enkripsi membantu confidentiality, tetapi ciphertext permanen tetap dapat menjadi risiko jika key bocor di masa depan.

Perbandingan Praktis

| Kebutuhan | Kandidat | Batas utama |
|---|---|---|
| Identifier dan verification key | DID | Recovery, privacy, method governance |
| Content addressing dan distribusi | IPFS | Harus ada pinning/provider |
| Arsip publik jangka panjang | Arweave | Permanence, biaya, dan penghapusan |
| Data privat yang bisa dihapus | Storage biasa terenkripsi | Tetap perlu access control dan backup |

Teknologi ini dapat digabungkan, tetapi tidak harus. DID Document bisa menunjuk service endpoint biasa. CID IPFS dapat dicatat dalam database tradisional. Aplikasi dapat mengarsipkan hanya release manifest tertentu ke Arweave.

Content Addressing Bukan Content Trust

CID membuktikan bahwa byte yang diperoleh cocok dengan identifier. CID tidak membuktikan siapa pembuatnya, apakah informasi benar, atau apakah content aman dibuka.

Untuk software release, kombinasikan CID dengan signature dari key yang dipercaya, provenance build, dan channel distribusi resmi. Untuk dokumen, simpan metadata penulis, waktu, format, dan versi schema. Verifikasi hash tanpa verifikasi identity hanya menjawab pertanyaan “apakah byte berubah?”

Penghapusan dan Kepatuhan

Sebelum menyimpan data ke jaringan publik, klasifikasikan data:

• public dan boleh dipertahankan;
• confidential;
• personal data;
• data dengan kewajiban retensi atau penghapusan;
• content berlisensi pihak lain.

Content publik yang direplikasi dapat tetap tersedia setelah aplikasi menghapus link. Jangan menjanjikan “right to delete” jika arsitektur tidak dapat memenuhinya. Untuk data pengguna, storage terkontrol dengan encryption, access log, backup, dan deletion workflow sering lebih tepat.

Availability Harus Diuji

Tambahkan health check yang mengambil CID penting dari beberapa jalur, memverifikasi content, dan memberi alert ketika provider gagal. Simpan inventaris siapa yang melakukan pinning dan siapa yang membayar layanan. Tanpa ownership operasional, “decentralized backup” mudah berubah menjadi link mati.

Desain yang Lebih Aman

Untuk dokumen publik:

1. buat content manifest dan checksum;
2. simpan salinan pada storage utama;
3. pin ke lebih dari satu lokasi bila memakai IPFS;
4. verifikasi retrieval dari gateway berbeda;
5. monitor availability;
6. dokumentasikan prosedur recovery.

Untuk identity:

1. tentukan threat model dan DID method;
2. pisahkan authentication dari authorization;
3. desain rotation dan recovery sebelum peluncuran;
4. minimalkan data publik;
5. uji kehilangan device dan key compromise.

Jangan memindahkan seluruh aplikasi hanya karena teknologi terlihat terdesentralisasi. Gunakan pada bagian yang memperoleh manfaat nyata dari verifiability, content addressing, atau arsip jangka panjang.

Proof of concept sebaiknya dimulai dengan data publik yang dapat dibuat ulang. Ukur waktu upload, retrieval, biaya, availability, dan proses recovery sebelum menjadikannya dependency production.

Referensi

• W3C: Decentralized Identifiers v1.0
• IPFS Docs: Content addressing
• IPFS Docs: Persistence
• IPFS Docs: Gateway
• Arweave Documentation